27-may, festival doirasida boʻlib oʻtgan DevOpsConf 2019 konferensiyasining asosiy zalida , "Doimiy yetkazib berish" bo'limining bir qismi sifatida "werf - Kubernetesdagi CI/CD uchun bizning vositamiz" hisoboti berildi. Bular haqida gapiradi Kubernetes-ga joylashtirishda hamma duch keladigan muammolar va qiyinchiliklar, shuningdek, darhol sezilmasligi mumkin bo'lgan nuanslar haqida. Mumkin bo'lgan echimlarni tahlil qilib, biz bu Open Source vositasida qanday amalga oshirilishini ko'rsatamiz .
Taqdimotdan buyon bizning yordamchi dasturimiz (ilgari Dapp nomi bilan tanilgan) tarixiy bosqichga erishdi. GitHub-da 1000 yulduz — umid qilamizki, uning o‘sib borayotgan foydalanuvchilar hamjamiyati ko‘plab DevOps muhandislari hayotini osonlashtiradi.
Shunday qilib, tanishtiramiz (~47 daqiqa, maqoladan ko'ra ko'proq ma'lumotli) va undan matn ko'rinishidagi asosiy parcha. Bor!
Kubernetesga kod yetkazib berish
Gap endi werf haqida emas, balki Kubernetesdagi CI/CD haqida bo'ladi, bu bizning dasturiy ta'minotimiz Docker konteynerlarida o'rnatilganligini anglatadi. (Men bu haqda gaplashdim ), va K8s uni ishlab chiqarishda ishlatish uchun ishlatiladi (bu haqida batafsil ma'lumotda ).
Kubernetesda yetkazib berish nimaga o'xshaydi?
- Kod va uni yaratish bo'yicha ko'rsatmalarga ega Git ombori mavjud. Ilova Docker tasviriga o'rnatilgan va Docker registrida nashr etilgan.
- Xuddi shu omborda dasturni qanday joylashtirish va ishga tushirish bo'yicha ko'rsatmalar ham mavjud. Joylashtirish bosqichida ushbu ko'rsatmalar Kubernetesga yuboriladi, u registrdan kerakli tasvirni oladi va uni ishga tushiradi.
- Bundan tashqari, odatda testlar mavjud. Ulardan ba'zilari rasmni nashr qilishda amalga oshirilishi mumkin. Siz shuningdek (xuddi shu ko'rsatmalarga rioya qilgan holda) ilova nusxasini (alohida K8s nom maydonida yoki alohida klasterda) joylashtirishingiz va u erda testlarni o'tkazishingiz mumkin.
- Va nihoyat, sizga Git-dan voqealarni qabul qiluvchi (yoki tugmani bosish) va barcha belgilangan bosqichlarni chaqiradigan CI tizimi kerak: qurish, nashr etish, joylashtirish, sinovdan o'tkazish.
Bu erda bir nechta muhim eslatmalar mavjud:
- Chunki bizda o‘zgarmas infratuzilma mavjud (o'zgarmas infratuzilma), barcha bosqichlarda qo'llaniladigan dastur tasviri (sahnalashtirish, ishlab chiqarish va boshqalar), bitta bo'lishi kerak. Men bu haqda batafsilroq va misollar bilan gapirdim. .
- Chunki biz infratuzilmani kodli yondashuv sifatida kuzatamiz (IaC), dastur kodi, uni yig'ish va ishga tushirish bo'yicha ko'rsatmalar bo'lishi kerak aynan bitta omborda. Bu haqda ko'proq ma'lumot olish uchun qarang .
- Yetkazib berish zanjiri (etkazib berish) biz buni odatda shunday ko'ramiz: dastur yig'ilgan, sinovdan o'tgan, chiqarilgan (chiqarish bosqichi) va hammasi - etkazib berish amalga oshirildi. Lekin, aslida, foydalanuvchi siz chiqargan narsani oladi, yo'q keyin siz uni ishlab chiqarishga topshirganingizda va u erga borishga muvaffaq bo'lganda va bu ishlab chiqarish ishlagan. Shunday qilib, etkazib berish zanjiri tugashiga ishonaman faqat operatsion bosqichda (yugurish), yoki aniqrog'i, kod ishlab chiqarishdan olib tashlangan paytda ham (uni yangisi bilan almashtirish).
Keling, Kubernetesdagi yuqoridagi etkazib berish sxemasiga qaytaylik: uni nafaqat biz, balki ushbu muammo bilan shug'ullangan har bir kishi ixtiro qilgan. Aslida, bu naqsh endi GitOps deb ataladi (Siz atama va uning orqasidagi g'oyalar haqida ko'proq o'qishingiz mumkin ). Keling, sxemaning bosqichlarini ko'rib chiqaylik.
Qurilish bosqichi
Aftidan, 2019 yilda Docker tasvirlarini yaratish haqida hamma narsa Dockerfiles yozish va ishga tushirishni bilsa, gapirish mumkin. docker build?.. Mana men e'tibor bermoqchi bo'lgan nuanslar:
- Rasm vazni muhim, shuning uchun foydalaning rasmda faqat operatsiya uchun zarur bo'lgan ilovani qoldirish.
- Qatlamlar soni ning zanjirlarini birlashtirish orqali minimallashtirilishi kerak
RUN-ma'nosiga ko'ra buyruqlar. - Biroq, bu muammolarni qo'shadi disk raskadrovka, chunki yig'ilish qulab tushganda, muammoga sabab bo'lgan zanjirdan to'g'ri buyruqni topishingiz kerak.
- Yig'ish tezligi muhim, chunki biz o'zgarishlarni tezda amalga oshirishni va natijalarni ko'rishni xohlaymiz. Misol uchun, har safar dastur yaratganingizda til kutubxonalaridagi bog'liqliklarni qayta tiklashni xohlamaysiz.
- Ko'pincha sizga kerak bo'lgan bitta Git omboridan ko'plab tasvirlar, bu Dockerfiles to'plami (yoki bitta faylda nomlangan bosqichlar) va ularning ketma-ket yig'ilishi bilan Bash skripti tomonidan hal qilinishi mumkin.
Bu hamma duch keladigan aysbergning faqat uchi edi. Ammo boshqa muammolar ham bor, xususan:
- Ko'pincha montaj bosqichida bizga biror narsa kerak bo'ladi o'rnatish (masalan, apt kabi buyruq natijasini uchinchi tomon katalogida keshlash).
- Biz istaymiz E'tirof etiladi qobiqda yozish o'rniga.
- Biz istaymiz Dockersiz qurish (Bizda konteynerlarni ishga tushirishimiz mumkin bo'lgan Kubernetes klasteri mavjud bo'lsa, nima uchun bizga hamma narsani sozlashimiz kerak bo'lgan qo'shimcha virtual mashina kerak?).
- Parallel yig'ish, bu turli yo'llar bilan tushunilishi mumkin: Dockerfile-dan turli xil buyruqlar (agar ko'p bosqichli ishlatilsa), bir xil omborning bir nechta topshiriqlari, bir nechta Dockerfile.
- Tarqalgan yig'ilish: Biz "efemer" bo'lgan narsalarni podlarda to'plashni xohlaymiz, chunki ularning keshi yo'qoladi, ya'ni uni alohida joyda saqlash kerak.
- Nihoyat, men istaklar cho'qqisini nomladim avtomatik sehrli: Qanday qilib va nimani to'g'ri bajarish kerakligini tushungan holda, omborga borish, qandaydir buyruqni kiritish va tayyor tasvirni olish ideal bo'ladi. Biroq, shaxsan men barcha nuanslarni shu tarzda oldindan ko'rish mumkinligiga ishonchim komil emas.
Va bu erda loyihalar:
- — Docker Inc quruvchisi (allaqachon Dockerning joriy versiyalariga integratsiya qilingan), bu barcha muammolarni hal qilishga harakat qilmoqda;
- — Google kompaniyasidan Dockersiz qurish imkonini beruvchi quruvchi;
- - CNCF-ning avtomatik sehrni va, xususan, qatlamlar uchun rebase bilan qiziqarli echimni yaratishga urinishi;
- va boshqa bir qator yordamchi dasturlar, masalan , ...
... va ularning GitHub-da qancha yulduzlari borligini ko'ring. Ya'ni, bir tomondan, docker build mavjud va biror narsa qila oladi, lekin haqiqatda muammo butunlay hal etilmagan - buning isboti muqobil kollektorlarning parallel rivojlanishi bo'lib, ularning har biri muammolarning bir qismini hal qiladi.
Werfda yig'ish
Shunday qilib, biz majburmiz (ilgari dapp kabi) — Flant kompaniyasining ochiq manbali yordam dasturi, biz ko'p yillar davomida ishlab chiqaramiz. Hammasi 5 yil oldin Dockerfiles yig'ilishini optimallashtiradigan Bash skriptlari bilan boshlangan va so'nggi 3 yil davomida to'liq ishlab chiqish o'zining Git omboriga ega bitta loyiha doirasida amalga oshirildi. (avval Rubyda, keyin esa to Go va shu bilan birga nomi o'zgartirildi). Werfda qanday montaj masalalari hal qilinadi?
Ko'k rangda bo'yalgan muammolar allaqachon amalga oshirilgan, parallel qurish bir xil xost ichida amalga oshirilgan va sariq rangda ko'rsatilgan masalalar yoz oxirigacha yakunlanishi rejalashtirilgan.
Reestrda nashr etish bosqichi (nashr qilish)
Biz telefon qildik docker push... - rasmni ro'yxatga olish kitobiga yuklashda nima qiyin bo'lishi mumkin? Va keyin savol tug'iladi: "Rasmga qanday teg qo'yishim kerak?" Bu bizda mavjud bo'lgan sababdan kelib chiqadi Gitflow (yoki boshqa Git strategiyasi) va Kubernetes va sanoat Kubernetesda sodir bo'layotgan voqealar Gitda sodir bo'layotgan voqealarga mos kelishini ta'minlashga harakat qilmoqda. Axir, Git bizning yagona haqiqat manbamizdir.
Buning nimasi qiyin? Qayta ishlab chiqarishni ta'minlash: tabiatan o'zgarmas bo'lgan Gitdagi majburiyatdan (o'zgarmas), bir xil saqlanishi kerak bo'lgan Docker tasviriga.
Bu biz uchun ham muhim kelib chiqishini aniqlash, chunki biz Kubernetes-da ishlaydigan dastur qaysi bajarilganligini tushunishni istaymiz (keyin biz farqlar va shunga o'xshash narsalarni qilishimiz mumkin).
Taglash strategiyalari
Birinchisi oddiy git tegi. Bizda tasvir bilan belgilangan ro'yxatga olish kitobi mavjud 1.0. Kubernetesda ushbu rasm yuklangan sahna va ishlab chiqarish mavjud. Git-da biz majburiyatlarni bajaramiz va bir nuqtada biz belgilaymiz 2.0. Biz uni ombordagi ko'rsatmalarga muvofiq yig'amiz va uni teg bilan ro'yxatga olish kitobiga joylashtiramiz 2.0. Biz uni sahnaga, agar hammasi yaxshi bo'lsa, ishlab chiqarishga chiqaramiz.
Ushbu yondashuv bilan bog'liq muammo shundaki, biz birinchi navbatda teg qo'ydik va shundan keyingina uni sinab ko'rdik va chiqardik. Nega? Birinchidan, bu mantiqqa to'g'ri kelmaydi: biz hali sinab ko'rmagan dasturiy ta'minot versiyasini chiqarmoqdamiz (boshqacha qila olmaymiz, chunki tekshirish uchun biz teg qo'yishimiz kerak). Ikkinchidan, bu yo'l Gitflow bilan mos kelmaydi.
Ikkinchi variant git commit + teg. Asosiy filialda teg mavjud 1.0; buning uchun registrda - ishlab chiqarishga joylashtirilgan rasm. Bundan tashqari, Kubernetes klasterida oldindan ko'rish va sahnalashtirish konturlari mavjud. Keyinchalik biz Gitflow ga amal qilamiz: rivojlanish uchun asosiy filialda (develop) biz yangi funksiyalarni yaratamiz, natijada identifikator bilan majburiyat hosil qilamiz #c1. Biz uni to'playmiz va ushbu identifikator yordamida reestrga joylashtiramiz (#c1). Xuddi shu identifikator bilan biz oldindan ko'rish uchun chiqaramiz. Biz majburiyatlar bilan ham shunday qilamiz #c2 и #c3.
Etarli xususiyatlar mavjudligini tushunganimizda, biz hamma narsani barqarorlashtirishni boshlaymiz. Git-da filial yarating release_1.1 (tayanchda #c3 dan develop). Ushbu nashrni yig'ishning hojati yo'q, chunki ... bu avvalgi bosqichda qilingan. Shuning uchun, biz uni shunchaki sahnalashtirish uchun chiqarishimiz mumkin. Biz xatolarni tuzatamiz #c4 va shunga o'xshash tarzda sahnalashtiring. Shu bilan birga, rivojlanish davom etmoqda develop, vaqti-vaqti bilan o'zgarishlar qaerdan olinadi release_1.1. Bir nuqtada biz yig'ilgan va sahnalashtirish uchun yuklangan majburiyat olamiz, biz bundan mamnunmiz (#c25).
Keyin biz (tezkor oldinga siljish bilan) bo'shatish novdasini birlashtiramiz (release_1.1) ustada. Biz ushbu majburiyatga yangi versiya bilan teg qo'ydik (1.1). Ammo bu rasm allaqachon ro'yxatga olish kitobida to'plangan, shuning uchun uni qayta to'plamaslik uchun biz mavjud rasmga ikkinchi teg qo'shamiz (endi uning registrida teglar mavjud. #c25 и 1.1). Shundan so'ng biz uni ishlab chiqarishga chiqaramiz.
Kamchilik borki, sahnalashtirishga faqat bitta rasm yuklanadi (#c25) va ishlab chiqarishda u boshqacha (1.1), lekin biz bilamizki, "jismoniy" bu ro'yxatga olish kitobidagi bir xil tasvir.
Haqiqiy kamchilik shundaki, birlashish majburiyatlarini qo'llab-quvvatlamaydi, siz tez oldinga siljishingiz kerak.
Biz oldinga borib, nayrang qilishimiz mumkin... Keling, oddiy Dockerfile misolini ko'rib chiqaylik:
FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb
FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/publicUndan quyidagi printsip bo'yicha fayl tuzamiz:
- SHA256 ishlatilgan tasvirlar identifikatorlaridan (
ruby:2.3иnginx:alpine), ular tarkibining nazorat summalari; - barcha jamoalar (
RUN,CMDva h.k.); - Qo'shilgan fayllardan SHA256.
... va bunday fayldan nazorat summasini (yana SHA256) oling. Bu imzo Docker tasvirining mazmunini belgilaydigan hamma narsa.
Keling, diagrammaga qaytaylik va majburiyatlar o'rniga biz bunday imzolardan foydalanamiz, ya'ni. rasmlarni imzo bilan belgilang.
Endi, masalan, relizdan masterga o'zgarishlarni birlashtirish zarur bo'lganda, biz haqiqiy birlashtirish majburiyatini bajarishimiz mumkin: u boshqa identifikatorga ega bo'ladi, lekin bir xil imzo. Xuddi shu identifikator bilan biz tasvirni ishlab chiqarishga chiqaramiz.
Kamchilik shundaki, endi ishlab chiqarishga qanday majburiyat kiritilganligini aniqlab bo'lmaydi - nazorat summalari faqat bitta yo'nalishda ishlaydi. Ushbu muammo metama'lumotlarga ega qo'shimcha qatlam tomonidan hal qilinadi - keyinroq aytib beraman.
werfda teglash
Werf-da biz bundan ham uzoqroqqa bordik va bitta mashinada saqlanmaydigan kesh bilan taqsimlangan qurilishni amalga oshirishga tayyorlanmoqdamiz ... Shunday qilib, biz ikkita turdagi Docker tasvirlarini yaratamiz, biz ularni chaqiramiz. bosqichi и surat.
werf Git ombori qurilishning turli bosqichlarini tavsiflovchi maxsus ko'rsatmalarni saqlaydi (o'rnatishdan oldin, o'rnatish, o'rnatishdan oldin, sozlash). Biz birinchi bosqich tasvirini birinchi qadamlarning nazorat summasi sifatida belgilangan imzo bilan yig'amiz. Keyin biz manba kodini qo'shamiz, yangi sahna tasviri uchun biz uning nazorat summasini hisoblaymiz ... Bu operatsiyalar barcha bosqichlar uchun takrorlanadi, buning natijasida biz sahna tasvirlari to'plamini olamiz. Keyin biz yakuniy rasmni yaratamiz, unda uning kelib chiqishi haqidagi metama'lumotlar ham mavjud. Va biz bu rasmni turli yo'llar bilan belgilaymiz (keyinroq tafsilotlar).
Aytaylik, shundan so'ng faqat dastur kodi o'zgartirilgan yangi majburiyat paydo bo'ldi. Nima bo'ladi? Kodni o'zgartirish uchun yamoq yaratiladi va yangi sahna tasviri tayyorlanadi. Uning imzosi eski sahna tasviri va yangi yamoqning nazorat summasi sifatida aniqlanadi. Ushbu rasmdan yangi yakuniy rasm hosil bo'ladi. Shunga o'xshash xatti-harakatlar boshqa bosqichlardagi o'zgarishlar bilan sodir bo'ladi.
Shunday qilib, sahna tasvirlari tarqatilgan holda saqlanishi mumkin bo'lgan keshdir va undan allaqachon yaratilgan tasvirlar Docker registriga yuklanadi.
Ro'yxatga olish kitobini tozalash
Biz o'chirilgan teglardan keyin osilib qolgan qatlamlarni o'chirish haqida gapirmayapmiz - bu Docker Registry-ning standart xususiyati. Biz juda ko'p Docker teglari to'planib qolgan vaziyat haqida gapiryapmiz va biz ulardan ba'zilariga endi kerak emasligini tushunamiz, lekin ular joy egallaydi (va/yoki biz buning uchun to'laymiz).
Tozalash strategiyalari qanday?
- Siz shunchaki hech narsa qila olmaysiz tozalamang. Ba'zan teglarning katta chigalini ochishdan ko'ra, qo'shimcha joy uchun ozgina pul to'lash haqiqatan ham osonroq. Ammo bu faqat ma'lum bir nuqtaga qadar ishlaydi.
- To'liq tiklash. Agar siz barcha rasmlarni o'chirib tashlasangiz va faqat CI tizimidagi joriylarini qayta tiklasangiz, muammo paydo bo'lishi mumkin. Agar konteyner ishlab chiqarishda qayta ishga tushirilsa, u uchun yangi rasm yuklanadi - hali hech kim tomonidan sinovdan o'tkazilmagan. Bu o'zgarmas infratuzilma g'oyasini o'ldiradi.
- Moviy-yashil. Bir ro'yxatga olish kitobi to'lib keta boshladi - biz rasmlarni boshqasiga yuklaymiz. Oldingi usulda bo'lgani kabi bir xil muammo: to'lib toshgan ro'yxatga olish kitobini qaysi nuqtada tozalash mumkin?
- Vaqt bilan. 1 oydan eski barcha rasmlar oʻchirilsinmi? Lekin bir oydan beri yangilanmagan xizmat albatta bo'ladi...
- qo'lda nima allaqachon o'chirilishi mumkinligini aniqlang.
Ikkita haqiqatan ham hayotiy variant mavjud: tozalamang yoki ko'k-yashil kombinatsiyasi + qo'lda. Ikkinchi holda, biz quyidagilar haqida gapiramiz: ro'yxatga olish kitobini tozalash vaqti kelganini tushunganingizda, siz yangisini yaratasiz va unga, masalan, bir oy davomida barcha yangi rasmlarni qo'shasiz. Va bir oydan so'ng, Kubernetesdagi qaysi podlar hali ham eski registrdan foydalanayotganini ko'ring va ularni yangi registrga o'tkazing.
Nimaga keldik werf? Biz yig'amiz:
- Git boshi: barcha teglar, barcha filiallar - biz Git-da tasvirlarda belgilangan hamma narsaga muhtojmiz deb hisoblaymiz (agar bo'lmasa, uni Git-ning o'zida o'chirishimiz kerak);
- hozirda Kubernetesga pompalanadigan barcha podalar;
- eski ReplicaSets (yaqinda chiqarilgan) va biz Helm relizlarini skanerlashni va u erda eng so'nggi rasmlarni tanlashni rejalashtirmoqdamiz.
... va ushbu to'plamdan oq ro'yxat tuzing - biz o'chirmaydigan rasmlar ro'yxati. Biz hamma narsani tozalaymiz, shundan so'ng biz etim sahna tasvirlarini topamiz va ularni ham o'chirib tashlaymiz.
Joylashtirish bosqichi
Ishonchli deklarativlik
Joylashtirishda men e'tibor qaratmoqchi bo'lgan birinchi nuqta - bu deklarativ ravishda e'lon qilingan yangilangan resurs konfiguratsiyasini ishga tushirish. Kubernetes resurslarini tavsiflovchi asl YAML hujjati har doim klasterda ishlaydigan natijadan juda farq qiladi. Chunki Kubernetes konfiguratsiyaga qo'shadi:
- identifikatorlar;
- xizmat ma'lumotlari;
- ko'p standart qiymatlar;
- joriy holatga ega bo'lim;
- qabul webhook qismi sifatida kiritilgan o'zgarishlar;
- turli kontrollerlar (va rejalashtiruvchi) ishining natijasi.
Shuning uchun, yangi resurs konfiguratsiyasi paydo bo'lganda (yangi), biz u bilan joriy, "jonli" konfiguratsiyani olib, ustiga yoza olmaymiz (jonli). Buning uchun biz taqqoslashimiz kerak yangi oxirgi qo'llaniladigan konfiguratsiya bilan (oxirgi qo'llanilgan) va ustiga aylantiring jonli yamoq oldi.
Ushbu yondashuv deyiladi 2 tomonlama birlashma. U, masalan, Helmda ishlatiladi.
Shuningdek bor 3 tomonlama birlashma, bu bilan farqlanadi:
- solishtirish oxirgi qo'llanilgan и yangi, biz o'chirilgan narsalarni ko'rib chiqamiz;
- solishtirish yangi и jonli, biz nima qo'shilgan yoki o'zgartirilganiga qaraymiz;
- jamlangan yamoq qo'llaniladi jonli.
Biz Helm bilan 1000 dan ortiq ilovalarni joylashtiramiz, shuning uchun biz aslida ikki tomonlama birlashma bilan yashaymiz. Biroq, uning yamoqlarimiz bilan hal qilgan bir qator muammolari bor, ular Helmning normal ishlashiga yordam beradi.
Haqiqiy tarqatish holati
Bizning CI tizimi keyingi voqea asosida Kubernetes uchun yangi konfiguratsiyani yaratgandan so'ng, u foydalanish uchun uzatadi. (qo'llash) klasterga - Helm yoki yordamida kubectl apply. Keyinchalik, allaqachon tasvirlangan N-way birlashmasi sodir bo'ladi, bunga Kubernetes API CI tizimiga va uning foydalanuvchisiga ma'qullash bilan javob beradi.
Biroq, juda katta muammo bor: oxir-oqibat Muvaffaqiyatli dastur muvaffaqiyatli tarqatish degani emas. Agar Kubernetes qanday o'zgarishlarni qo'llash kerakligini tushunsa va uni qo'llasa, natija qanday bo'lishini hali ham bilmaymiz. Misol uchun, old qismdagi podlarni yangilash va qayta ishga tushirish muvaffaqiyatli bo'lishi mumkin, lekin orqa tomonda emas va biz ishlaydigan dastur tasvirlarining turli versiyalarini olamiz.
Har bir narsani to'g'ri bajarish uchun ushbu sxema qo'shimcha havolani talab qiladi - Kubernetes API-dan status ma'lumotlarini oladigan va uni narsalarning haqiqiy holatini keyingi tahlil qilish uchun uzatadigan maxsus kuzatuvchi. Biz Go'da ochiq manba kutubxonasini yaratdik - (uning e'loniga qarang ), bu muammoni hal qiladi va werf ichiga o'rnatilgan.
Ushbu kuzatuvchining werf darajasidagi harakati Deployments yoki StatefulSets-ga joylashtirilgan izohlar yordamida sozlangan. Asosiy izoh - fail-mode - quyidagi ma'nolarni tushunadi:
-
IgnoreAndContinueDeployProcess— biz ushbu komponentni tarqatish muammolariga e'tibor bermaymiz va joylashtirishni davom ettiramiz; -
FailWholeDeployProcessImmediately— ushbu komponentdagi xato joylashtirish jarayonini to‘xtatadi; -
HopeUntilEndOfDeployProcess— umid qilamizki, ushbu komponent joylashtirish oxirigacha ishlaydi.
Masalan, bu manbalar va izoh qiymatlarining kombinatsiyasi fail-mode:
Biz birinchi marta joylashtirganimizda, ma'lumotlar bazasi (MongoDB) hali tayyor bo'lmasligi mumkin - O'rnatish muvaffaqiyatsiz bo'ladi. Ammo siz uning boshlanishini kutishingiz mumkin va joylashtirish hali ham amalga oshiriladi.
Werfda kubedog uchun yana ikkita izoh mavjud:
-
failures-allowed-per-replica— har bir replika uchun ruxsat etilgan tushishlar soni; -
show-logs-until— werf (stdout-da) barcha o'ralgan podlardan jurnallarni ko'rsatgunga qadar vaqtni tartibga soladi. Asl qiymatiPodIsReady(podkaga trafik boshlanganda biz istamaydigan xabarlarni e'tiborsiz qoldirish uchun), lekin qiymatlar ham amal qiladi:ControllerIsReadyиEndOfDeploy.
Joylashtirishdan yana nimani xohlaymiz?
Yuqorida tavsiflangan ikkita fikrga qo'shimcha ravishda, biz xohlaymiz:
- ko'rish uchun jurnallar - va faqat zarur bo'lganlar, va hamma narsa ketma-ket emas;
- trek taraqqiyot, chunki agar ish bir necha daqiqa davomida "jimgina" osilib tursa, u erda nima sodir bo'layotganini tushunish muhimdir;
- bor avtomatik orqaga qaytarish biror narsa noto'g'ri bo'lgan taqdirda (va shuning uchun joylashtirishning haqiqiy holatini bilish juda muhimdir). Chiqarish atomik bo'lishi kerak: yo oxirigacha ketadi yoki hamma narsa avvalgi holatiga qaytadi.
natijalar
Kompaniya sifatida biz uchun barcha tavsiflangan nuanslarni etkazib berishning turli bosqichlarida (qurilish, nashr etish, joylashtirish) amalga oshirish uchun CI tizimi va yordamchi dastur etarli. .
Xulosa o'rniga:
Werf yordamida biz DevOps muhandislari uchun ko'plab muammolarni hal qilishda yaxshi yutuqlarga erishdik va agar kengroq hamjamiyat hech bo'lmaganda ushbu yordam dasturini amalda sinab ko'rsa, xursand bo'lardik. Birgalikda yaxshi natijaga erishish osonroq bo'ladi.
Video va slaydlar
Spektakldan video (~47 daqiqa):
Hisobot taqdimoti:
PS
Bizning blogimizdagi Kubernetes haqidagi boshqa xabarlar:
- «» (Dmitriy Stolyarov; 27 yil 2019 aprel, “Ish tashlash” haqida);
- «» (Andrey Polovov; 8-yil 2019-aprel, Saint HighLoad++ da);
- «» (Dmitriy Stolyarov; 8 yil 2018 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 28 yil 2018-may, RootConf da);
- «» (Dmitriy Stolyarov; 7 yil 2017 noyabr HighLoad++ da);
- «» (Dmitriy Stolyarov; 6 yil 2017 iyunda RootConf da).
Manba: www.habr.com