Biz blogimizni texnik direktorimizning so'nggi chiqishlari asosida nashr etilgan nashrlar bilan boshlaymiz (Dmitriy Stolyarov). Ularning barchasi 2016 yilda turli professional tadbirlarda bo'lib o'tdi va DevOps va Docker mavzusiga bag'ishlangan edi. Badoo ofisidagi Docker Moskva uchrashuvidan bitta video, bizda allaqachon mavjud saytda. Yangilari esa ma'ruzalarning mohiyatini aks ettiruvchi maqolalar bilan birga bo'ladi. Shunday qilib…
31-may konferentsiyada , “Rossiya internet texnologiyalari” (RIT++ 2016) festivali doirasida oʻtkazilgan “Uzluksiz joylashtirish va joylashtirish” boʻlimi “Docker bilan uzluksiz yetkazib berishning eng yaxshi amaliyotlari” hisoboti bilan ochildi. Unda Docker va boshqa ochiq kodli mahsulotlardan foydalangan holda uzluksiz yetkazib berish (CD) jarayonini yaratish bo‘yicha eng yaxshi amaliyotlar umumlashtirildi va tizimlashtirildi. Biz ishlab chiqarishda ushbu echimlar bilan ishlaymiz, bu bizga amaliy tajribaga tayanish imkonini beradi.
Agar sizda bir soat sarflash imkoningiz bo'lsa , toʻliq koʻrishni tavsiya qilamiz. Aks holda, quyida matn ko'rinishidagi asosiy xulosa mavjud.
Docker bilan uzluksiz yetkazib berish
ostida Har doim yetkazib berish biz voqealar zanjirini tushunamiz, buning natijasida Git omboridan dastur kodi avval ishlab chiqarishga keladi va keyin arxivda tugaydi. U shunday ko'rinadi: Git → Build → Test → Release → Operate.
Hisobotning ko'p qismi qurilish bosqichiga (ilova yig'ilishiga) bag'ishlangan bo'lib, nashr etilgan va ishlaydigan mavzular qisqacha ko'rib chiqiladi. Biz ularni hal qilishga imkon beruvchi muammolar va naqshlar haqida gapiramiz va bu naqshlarning o'ziga xos ilovalari boshqacha bo'lishi mumkin.
Nima uchun Docker bu erda umuman kerak? Biz ushbu Ochiq manba vositasi kontekstida Uzluksiz yetkazib berish amaliyoti haqida gapirishga qaror qilganimiz bejiz emas. Garchi butun hisobot undan foydalanishga bag'ishlangan bo'lsa-da, dastur kodini ishlab chiqishning asosiy sxemasini ko'rib chiqishda ko'plab sabablar aniqlanadi.
Asosiy tarqatish namunasi
Shunday qilib, biz ilovaning yangi versiyalarini chiqarganimizda, biz, albatta, duch kelamiz ishlamay qolish muammosi, ishlab chiqarish serverini almashtirish paytida yaratilgan. Ilovaning eski versiyasidan yangisiga o'tish bir zumda o'tishi mumkin emas: birinchi navbatda biz yangi versiya nafaqat muvaffaqiyatli yuklab olinganiga, balki "isitilishiga" ishonch hosil qilishimiz kerak (ya'ni, so'rovlarni bajarishga to'liq tayyor).
Shunday qilib, bir muncha vaqt dasturning ikkala versiyasi (eski va yangi) bir vaqtning o'zida ishlaydi. Bu avtomatik ravishda olib keladi umumiy resurslar to'qnashuvi: tarmoq, fayl tizimi, IPC va boshqalar. Docker yordamida bu muammo dasturning turli versiyalarini alohida konteynerlarda ishga tushirish orqali osonlikcha hal qilinadi, buning uchun bir xil xost (server/virtual mashina) ichida resurs izolyatsiyasi kafolatlanadi. Albatta, siz izolyatsiyasiz ba'zi bir hiyla-nayranglar bilan shug'ullanishingiz mumkin, ammo agar tayyor va qulay vosita bo'lsa, unda teskari sabab bor - uni e'tiborsiz qoldirmaslik.
Konteynerizatsiya o'rnatilganda boshqa ko'plab afzalliklarni beradi. Har qanday dasturga bog'liq maxsus versiya (yoki versiya oralig'i) tarjimon, modullar/kengaytmalar va boshqalar mavjudligi, shuningdek ularning versiyalari. Va bu nafaqat bevosita bajariladigan muhitga, balki butun atrof-muhitga, shu jumladan tizim dasturiy ta'minoti va uning versiyasi (ishlatilgan Linux distributiviga qadar). Konteynerlar nafaqat dastur kodini, balki oldindan o'rnatilgan tizim va kerakli versiyalarning amaliy dasturlarini o'z ichiga olganligi sababli, siz bog'liqliklar bilan bog'liq muammolarni unutishingiz mumkin.
Keling, xulosa qilaylik asosiy tarqatish namunasi quyidagi omillarni hisobga olgan holda yangi versiyalar:
- Dastlab, dasturning eski versiyasi birinchi konteynerda ishlaydi.
- Keyin yangi versiya o'raladi va ikkinchi idishda "isitiladi". Shunisi e'tiborga loyiqki, ushbu yangi versiyaning o'zi nafaqat yangilangan dastur kodini, balki uning har qanday bog'liqligini, shuningdek tizim komponentlarini (masalan, OpenSSLning yangi versiyasi yoki butun tarqatish) o'z ichiga olishi mumkin.
- Yangi versiya so'rovlarga xizmat ko'rsatishga to'liq tayyor bo'lganda, trafik birinchi konteynerdan ikkinchisiga o'tadi.
- Eski versiya endi to'xtatilishi mumkin.
Ilovaning turli versiyalarini alohida konteynerlarda joylashtirishning bunday yondashuvi yana bir qulaylikni ta'minlaydi - tez orqaga qaytarish eski versiyaga (axir, trafikni kerakli konteynerga o'tkazish kifoya).
Yakuniy birinchi tavsiya, hatto kapitan ham ayb topa olmaydigan narsaga o'xshaydi: "[Docker bilan uzluksiz yetkazib berishni tashkil qilishda] Docker-dan foydalaning [va nima berishini tushuning]" Esingizda bo'lsin, bu har qanday muammoni hal qiladigan kumush o'q emas, balki ajoyib poydevorni ta'minlaydigan vositadir.
Qayta ishlab chiqarish qobiliyati
"Qayta ishlab chiqarish" deganda biz ilovalarni ishlatishda duch keladigan muammolarning umumlashtirilgan to'plamini nazarda tutamiz. Biz bunday holatlar haqida gapiramiz:
- Sahnalashtirish uchun sifat bo'limi tomonidan tekshirilgan skriptlar ishlab chiqarishda aniq takrorlanishi kerak.
- Ilovalar turli xil ombor oynalaridan paketlarni qabul qila oladigan serverlarda nashr etiladi (vaqt o'tishi bilan ular yangilanadi va ular bilan o'rnatilgan ilovalarning versiyalari).
- "Mahallada hamma narsa men uchun ishlaydi!" (...va ishlab chiquvchilarga ishlab chiqarishga ruxsat berilmaydi.)
- Eski (arxivlangan) versiyada biror narsani tekshirishingiz kerak.
- ...
Ularning umumiy mohiyati ishlatiladigan muhitning to'liq muvofiqligi (shuningdek, inson omilining yo'qligi) zarurligi bilan bog'liq. Qayta ishlab chiqarishga qanday kafolat bera olamiz? Docker tasvirlarini yarating Git kodiga asoslanib, keyin ularni har qanday vazifa uchun ishlating: test maydonchalarida, ishlab chiqarishda, dasturchilarning mahalliy mashinalarida ... Shu bilan birga, bajariladigan harakatlarni minimallashtirish muhimdir. после tasvirni yig'ish: qanchalik sodda bo'lsa, xatolar kamroq bo'ladi.
Infratuzilma - bu kod
Agar infratuzilma talablari (server dasturiy ta'minotining mavjudligi, uning versiyasi va boshqalar) rasmiylashtirilmagan va "dasturlashtirilmagan" bo'lsa, u holda har qanday dastur yangilanishining chiqarilishi halokatli oqibatlarga olib kelishi mumkin. Misol uchun, sahnalashtirishda siz allaqachon PHP 7.0 ga o'tgansiz va shunga mos ravishda kodni qayta yozgansiz - keyin uning eski PHP (5.5) bilan ishlab chiqarishda paydo bo'lishi, albatta, kimnidir hayratda qoldiradi. Tarjimon versiyasidagi katta o'zgarishlarni unutmasligingiz mumkin, ammo "shayton tafsilotlarda": ajablanib, har qanday qaramlikning kichik yangilanishida bo'lishi mumkin.
Ushbu muammoni hal qilish usuli sifatida tanilgan IaC (Infratuzilma kod sifatida, "infratuzilma kod sifatida") va dastur kodi bilan birga infratuzilma talablarini saqlashni o'z ichiga oladi. Undan foydalanib, ishlab chiquvchilar va DevOps mutaxassislari bir xil Git ilovalari ombori bilan ishlashlari mumkin, lekin uning turli qismlarida. Ushbu koddan Git-da Docker tasviri yaratiladi, unda dastur infratuzilmaning barcha xususiyatlarini hisobga olgan holda joylashtiriladi. Oddiy qilib aytganda, tasvirlarni yig'ish uchun skriptlar (qoidalar) manba kodi bilan bir xil omborda bo'lishi va birlashtirilishi kerak.
Ko'p qatlamli dastur arxitekturasida - masalan, Docker konteyneri ichida ishlayotgan dastur oldida turgan nginx mavjud - Docker tasvirlari har bir qatlam uchun Git kodidan yaratilishi kerak. Keyin birinchi rasmda tarjimon va boshqa "yaqin" bog'liqliklar bo'lgan dastur, ikkinchi rasmda esa yuqori oqim nginx bo'ladi.
Docker tasvirlari, Git bilan aloqa
Biz Git-dan to'plangan barcha Docker rasmlarini ikki toifaga ajratamiz: vaqtinchalik va ozod. Vaqtinchalik tasvirlar Git-dagi filial nomi bilan teglangan, keyingi topshiriq tomonidan qayta yozilishi mumkin va faqat oldindan ko'rish uchun chiqariladi (ishlab chiqarish uchun emas). Bu ularning chiqarilganlaridan asosiy farqi: ularda qaysi aniq majburiyat borligini hech qachon bilmaysiz.
Vaqtinchalik tasvirlarga to'plash mantiqan to'g'ri keladi: asosiy filial (magistrning joriy versiyasini doimiy ravishda ko'rish uchun uni avtomatik ravishda alohida saytga o'tkazishingiz mumkin), relizlar bilan filiallar, muayyan innovatsiyalar filiallari.
Vaqtinchalik tasvirlarni oldindan ko'rish ishlab chiqarishga tarjima qilish zarurati tug'ilgandan so'ng, ishlab chiquvchilar ma'lum bir teg qo'yadilar. Teg bo'yicha avtomatik ravishda yig'iladi rasmni chiqarish (uning yorlig'i Git yorlig'iga mos keladi) va sahnalashtirish uchun chiqariladi. Agar u sifat bo'limi tomonidan muvaffaqiyatli tekshirilsa, u ishlab chiqarishga o'tadi.
toza
Ta'riflangan hamma narsa (chiqarish, tasvirni yig'ish, keyingi texnik xizmat ko'rsatish) Bash skriptlari va boshqa "improvizatsiya qilingan" vositalar yordamida mustaqil ravishda amalga oshirilishi mumkin. Ammo agar siz buni qilsangiz, unda bir nuqtada amalga oshirish katta murakkablik va yomon nazoratga olib keladi. Buni tushunib, biz CI/CD yaratish uchun o'zimizning maxsus Workflow yordam dasturini yaratishga keldik - toza.
Uning manba kodi Ruby-da yozilgan, ochiq manba va nashr etilgan . Afsuski, hujjatlar hozirda vositaning eng zaif nuqtasidir, ammo biz buning ustida ishlamoqdamiz. Biz esa dapp haqida bir necha marta yozamiz va gaplashamiz, chunki... Biz uning imkoniyatlarini butun manfaatdor hamjamiyat bilan baham ko'rishni chin dildan kuta olmaymiz, lekin shu vaqt ichida muammolaringizni yuboring va so'rovlaringizni oling va/yoki GitHub-da loyihaning rivojlanishini kuzatib boring.
Yangilangan: 13-yil 2019-avgust: hozirda loyiha toza deb qayta nomlandi , uning kodi Go'da to'liq qayta yozildi va uning hujjatlari sezilarli darajada yaxshilandi.
Kubernetes
Professional muhitda allaqachon e'tirof etilgan yana bir tayyor Open Source vositasi Kubernetes, Docker boshqaruv klasteri. Docker-da qurilgan loyihalarni ishlatishda undan foydalanish mavzusi hisobot doirasidan tashqarida, shuning uchun taqdimot ba'zi qiziqarli xususiyatlarni ko'rib chiqish bilan cheklangan.
Chiqarish uchun Kubernetes quyidagilarni taklif qiladi:
- tayyorlik tekshiruvi - ilovaning yangi versiyasining tayyorligini tekshirish (trafikni unga o'tkazish uchun);
- prokat yangilash - konteynerlar klasteridagi ketma-ket tasvirni yangilash (o'chirish, yangilash, ishga tushirishga tayyorgarlik, trafikni almashtirish);
- sinxron yangilash - klasterdagi tasvirni boshqa yondashuv bilan yangilash: birinchi navbatda konteynerlarning yarmida, keyin qolgan qismida;
- kanareykalar relizlari - anomaliyalarni kuzatish uchun cheklangan (kichik) miqdordagi konteynerlarda yangi tasvirni ishga tushirish.
Uzluksiz yetkazib berish nafaqat yangi versiyani chiqarish bo‘lganligi sababli, Kubernetes infratuzilmani keyingi ta’mirlash uchun qator imkoniyatlarga ega: barcha konteynerlar uchun o‘rnatilgan monitoring va jurnallar, avtomatik masshtablash va h.k. jarayonlaringizda amalga oshirish.
Yakuniy tavsiyalar
- Docker-dan foydalaning.
- Barcha ehtiyojlaringiz uchun ilovalarning Docker tasvirlarini yarating.
- "Infratuzilma - bu kod" tamoyiliga amal qiling.
- Gitni Docker bilan bog'lang.
- Chiqarish tartibini tartibga soling.
- Tayyor platformadan foydalaning (Kubernetes yoki boshqa).
Video va slaydlar
Spektakldan video (taxminan bir soat) (hisobotning o'zi 5-daqiqada boshlanadi - shu daqiqadan boshlab o'ynash uchun havolaga o'ting).
Hisobot taqdimoti:
PS
Bizning blogimizdagi mavzu bo'yicha boshqa hisobotlar:
- «» (Dmitriy Stolyarov; 27 yil 2019-may, DevOpsConf da);
- «» (Dmitriy Stolyarov; 8 yil 2018 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 7 yil 2017 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 6 yil 2017 iyunda RootConf da).
Manba: www.habr.com