Eslatma. tarjima.: Kubernetes hamjamiyatida GitOps deb nomlangan tendentsiya yaqqol mashhurlikka erishmoqda, biz shaxsan ko'rganimizdek, KubeCon Europe 2019. Bu atama nisbatan yaqinda edi Weaveworks rahbari - Aleksis Richardson tomonidan va operatsion muammolarni hal qilish uchun ishlab chiquvchilarga tanish bo'lgan vositalardan (birinchi navbatda Git, shuning uchun nomi) foydalanishni anglatadi. Xususan, biz Kubernetes-ning konfiguratsiyalarini Git-da saqlash va avtomatik ravishda klasterga o'zgartirishlarni kiritish orqali ishlashi haqida gapiramiz. Mattias Jg ushbu maqolada ushbu tarqatishning ikkita yondashuvi haqida gapiradi.
O `tgan yili (aslida, bu rasmiy ravishda 2017 yil avgust oyida sodir bo'lgan - taxminan tarjimasi.) Kubernetes-da ilovalarni joylashtirishga yangi yondashuv mavjud. U GitOps deb ataladi va u tarqatish versiyalarini kuzatish Git omborining xavfsiz muhitida amalga oshiriladi degan asosiy g'oyaga asoslanadi.
Ushbu yondashuvning asosiy afzalliklari quyidagilardan iborat::
- Joylashtirish versiyasi va o'zgarishlar tarixi. Butun klaster holati Git omborida saqlanadi va joylashtirishlar faqat topshiriqlar orqali yangilanadi. Bundan tashqari, barcha o'zgarishlarni topshirish tarixi yordamida kuzatish mumkin.
- Tanish Git buyruqlari yordamida orqaga qaytarish. Oddiy
git resetjoylashtirishlardagi o'zgarishlarni tiklashga imkon beradi; o'tgan davlatlar har doim mavjud. - Tayyor kirishni boshqarish. Odatda, Git tizimi juda ko'p nozik ma'lumotlarni o'z ichiga oladi, shuning uchun ko'pchilik kompaniyalar ularni himoya qilishga alohida e'tibor berishadi. Shunga ko'ra, bu himoya, shuningdek, joylashtirish bilan operatsiyalar uchun ham amal qiladi.
- Joylashtirish siyosati. Aksariyat Git tizimlari tabiiy ravishda turli filiallar uchun siyosatlarni qo'llab-quvvatlaydi - masalan, faqat tortish so'rovlari masterni yangilashi mumkin va o'zgarishlar boshqa jamoa a'zosi tomonidan ko'rib chiqilishi va qabul qilinishi kerak. Kirishni boshqarishda bo'lgani kabi, o'rnatish yangilanishlariga ham xuddi shunday siyosatlar qo'llaniladi.
Ko'rib turganingizdek, GitOps usulining afzalliklari juda ko'p. O'tgan yil davomida ikkita yondashuv alohida mashhurlikka erishdi. Biri surishga asoslangan, ikkinchisi tortishga asoslangan. Ularni ko'rib chiqishdan oldin, keling, Kubernetesning odatiy joylashuvi qanday ko'rinishini ko'rib chiqaylik.
Joylashtirish usullari
So'nggi yillarda Kubernetes joylashtirish uchun turli usullar va vositalarni yaratdi:
- Mahalliy Kubernetes/Kustomize shablonlari asosida. Bu Kubernetes-da ilovalarni joylashtirishning eng oson usuli. Ishlab chiquvchi asosiy YAML fayllarini yaratadi va ularni qo'llaydi. Doimiy ravishda bir xil shablonlarni qayta yozishdan xalos bo'lish uchun Kustomize ishlab chiqilgan (u Kubernetes shablonlarini modullarga aylantiradi). Eslatma. tarjima.: Kustomize kubectl bilan birlashtirilgan .
- Rulda jadvallari. Rulda diagrammalari shablonlarga asoslangan yondashuvdan ko'ra ko'proq moslashuvchan moslashtirish opsiyalari bilan ilovalarni joylashtirish uchun ishlatiladigan shablonlar, init konteynerlari, yonboshlar va boshqalar to'plamini yaratishga imkon beradi. Bu usul shablonli YAML fayllariga asoslangan. Helm ularni turli parametrlar bilan to'ldiradi va keyin ularni klasterga joylashtiradigan va yangilanishlar va orqaga qaytarish imkonini beruvchi klaster komponenti Tillerga yuboradi. Muhimi shundaki, Helm asosan shablonlarga kerakli qiymatlarni kiritadi va keyin ularni an'anaviy yondashuvda bo'lgani kabi qo'llaydi. (bularning barchasi qanday ishlashi va undan qanday foydalanishingiz haqida bizning maqolamizda o'qing - taxminan. tarjima.). Turli xil vazifalarni o'z ichiga olgan tayyor Helm diagrammalarining keng assortimenti mavjud.
- Muqobil vositalar. Ko'plab alternativ vositalar mavjud. Ularning umumiy tomoni shundaki, ular ba'zi shablon fayllarini Kubernetes tomonidan o'qiladigan YAML fayllariga aylantiradi va keyin ulardan foydalanadi.
Ishimizda biz doimo muhim vositalar uchun Helm diagrammalaridan foydalanamiz (chunki ular allaqachon tayyor bo'lgan ko'p narsalarga ega, bu hayotni ancha osonlashtiradi) va o'z ilovalarimizni joylashtirish uchun "sof" Kubernetes YAML fayllaridan.
Tortish va surish
Oxirgi blog postlarimdan birida men ushbu vositani taqdim etdim , bu sizga shablonlarni Git omboriga joylashtirish va konteynerning har bir topshirilishi yoki bosilishidan keyin joylashtirishni yangilash imkonini beradi. Mening tajribam shuni ko'rsatadiki, bu vosita tortishish yondashuvini targ'ib qilishda asosiy vositalardan biridir, shuning uchun men unga tez-tez murojaat qilaman. Agar siz undan qanday foydalanish haqida ko'proq bilmoqchi bo'lsangiz, bu erda .
NB! GitOps-dan foydalanishning barcha afzalliklari ikkala yondashuv uchun ham bir xil bo'lib qoladi.
Pullga asoslangan yondashuv
Pull yondashuvi barcha o'zgarishlar klaster ichidan qo'llanilishiga asoslanadi. Klaster ichida bog'langan Git va Docker Registry repozitariylarini muntazam tekshiradigan operator mavjud. Agar ularda biron bir o'zgarishlar ro'y bersa, klaster holati ichki yangilanadi. Bu jarayon odatda juda xavfsiz deb hisoblanadi, chunki hech qanday tashqi mijoz klaster administratori huquqlaridan foydalana olmaydi.
Taroziga soling:
- Hech qanday tashqi mijoz klasterga o'zgartirish kiritish huquqiga ega emas; barcha yangilanishlar ichkaridan chiqariladi.
- Ba'zi vositalar, shuningdek, Helm diagrammasi yangilanishlarini sinxronlashtirish va ularni klasterga ulash imkonini beradi.
- Docker Registry yangi versiyalar uchun skanerlanishi mumkin. Agar yangi rasm mavjud bo'lsa, Git ombori va tarqatilishi yangi versiyaga yangilanadi.
- Pull vositalari turli xil Git omborlari va ruxsatnomalari bilan turli nomlar bo'ylab taqsimlanishi mumkin. Buning yordamida ko'p ijarachi modelidan foydalanish mumkin. Masalan, A jamoasi A nom maydonidan, B jamoasi B nom maydonidan foydalanishi mumkin va infratuzilma jamoasi global maydondan foydalanishi mumkin.
- Qoida tariqasida, asboblar juda engil.
- Operator kabi vositalar bilan birlashtirilgan , sirlar Git omborida shifrlangan holda saqlanishi va klaster ichida olinishi mumkin.
- CD quvurlariga ulanish yo'q, chunki joylashtirishlar klaster ichida sodir bo'ladi.
Minusy:
- Helm diagrammalaridan o'rnatish sirlarini boshqarish oddiylarga qaraganda qiyinroq, chunki ular avval, masalan, muhrlangan sirlar shaklida yaratilishi kerak, so'ngra ichki operator tomonidan shifrlanishi kerak va shundan keyingina ular tortish vositasida mavjud bo'ladi. Keyin siz Helm-da nashrni allaqachon o'rnatilgan sirlardagi qiymatlar bilan ishga tushirishingiz mumkin. Eng oson yo'li - tarqatish uchun ishlatiladigan barcha Helm qiymatlari bilan sir yaratish, uni parolini ochish va Git-ga topshirish.
- Qachonki siz tortishga yondashsangiz, siz tortish asboblariga bog'lanib qolasiz. Bu klasterda joylashtirish jarayonini sozlash imkoniyatini cheklaydi. Misol uchun, Kustomize yakuniy andozalar Gitga topshirilgunga qadar ishlashi kerakligi bilan murakkablashadi. Men siz mustaqil vositalardan foydalana olmaysiz demayapman, lekin ularni joylashtirish jarayoniga integratsiya qilish qiyinroq.
Pushga asoslangan yondashuv
Push yondashuvda tashqi tizim (asosan CD quvurlari) Git omboriga topshirilgandan so'ng yoki oldingi CI quvur liniyasi muvaffaqiyatli bo'lsa, klasterga joylashtirishni boshlaydi. Ushbu yondashuvda tizim klasterga kirish huquqiga ega.
Plyusy:
- Xavfsizlik Git ombori va qurilish quvur liniyasi tomonidan belgilanadi.
- Helm diagrammalarini joylashtirish osonroq va Helm plaginlarini qo'llab-quvvatlaydi.
- Sirlarni boshqarish osonroq, chunki sirlarni quvurlarda ishlatish va Git-da shifrlangan holda (foydalanuvchining xohishiga qarab) saqlanishi ham mumkin.
- Muayyan vositaga ulanish yo'q, chunki har qanday turdagi foydalanish mumkin.
- Konteyner versiyasini yangilash qurilish quvuri orqali boshlanishi mumkin.
Minusy:
- Klasterga kirish ma'lumotlari qurilish tizimi ichida.
- Joylashtirish konteynerlarini yangilash hali ham tortish jarayoni bilan osonroq.
- CD tizimiga katta bog'liqlik, chunki bizga kerak bo'lgan quvurlar dastlab Gitlab Runners uchun yozilgan bo'lishi mumkin va keyin jamoa Azure DevOps yoki Jenkins-ga o'tishga qaror qiladi ... va ko'p sonli qurilish quvurlarini ko'chirishga to'g'ri keladi.
Natijalar: surish yoki tortish?
Odatdagidek, har bir yondashuv o'zining ijobiy va salbiy tomonlariga ega. Ba'zi vazifalarni birida bajarish osonroq, boshqasi bilan qiyinroq. Avvaliga men joylashtirishni qo'lda qilardim, lekin Weave Flux haqida bir nechta maqolalarni ko'rganimdan so'ng, barcha loyihalar uchun GitOps jarayonlarini amalga oshirishga qaror qildim. Asosiy andozalar uchun bu oson edi, lekin keyin men Helm diagrammalarida qiyinchiliklarga duch keldim. O'sha paytda Weave Flux faqat Helm Chart Operatorning oddiy versiyasini taklif qilgan, ammo hozir ham ba'zi vazifalar sirlarni qo'lda yaratish va ularni qo'llash zarurati tufayli qiyinroq. Siz tortishish yondashuvi ancha xavfsizroq deb bahslashishingiz mumkin, chunki klasterning hisob ma'lumotlariga klasterdan tashqarida kirish imkoni yo'q, bu esa uni shunchalik xavfsizroq qiladiki, bu qo'shimcha kuch sarflashga arziydi.
Biroz o'ylab, men kutilmagan xulosaga keldim, bu unday emas. Agar maksimal himoya talab qiladigan komponentlar haqida gapiradigan bo'lsak, bu ro'yxatga maxfiy saqlash, CI/CD tizimlari va Git omborlari kiradi. Ularning ichidagi ma'lumotlar juda zaif va maksimal himoyaga muhtoj. Bundan tashqari, agar kimdir sizning Git omboringizga kirsa va u yerga kodni surishi mumkin bo'lsa, ular xohlagan narsani (tortish yoki surish) joylashtirishi va klaster tizimlariga kirishi mumkin. Shunday qilib, himoya qilinishi kerak bo'lgan eng muhim komponentlar klaster hisob ma'lumotlari emas, balki Git ombori va CI/CD tizimlaridir. Agar sizda ushbu turdagi tizimlar uchun yaxshi sozlangan siyosatlar va xavfsizlik boshqaruvlari mavjud boʻlsa va klaster hisob maʼlumotlari faqat sir sifatida quvurlarga chiqarilgan boʻlsa, tortib olish yondashuvining qoʻshimcha xavfsizligi dastlab oʻylangandek qimmatli boʻlmasligi mumkin.
Shunday qilib, agar tortish usuli ko'proq mehnat talab qilsa va xavfsizlik uchun foyda keltirmasa, faqat surish usulidan foydalanish mantiqiy emasmi? Ammo kimdir surish usulida siz CD tizimiga juda bog'langansiz va kelajakda migratsiyani amalga oshirish osonroq bo'lishi uchun buni qilmaslik yaxshiroqdir.
Menimcha (har doimgidek), siz ma'lum bir ish yoki kombinat uchun eng mos bo'lgan narsani ishlatishingiz kerak. Shaxsan men ikkala yondashuvdan ham foydalanaman: Weave Flux asosan oʻz xizmatlarimizni oʻz ichiga olgan tortishga asoslangan joylashtirishlar va Helm va plaginlar bilan push yondashuv, bu Helm diagrammalarini klasterga qoʻllashni osonlashtiradi va hech qanday muammosiz sirlarni yaratishga imkon beradi. . O'ylaymanki, barcha holatlar uchun mos keladigan yagona yechim hech qachon bo'lmaydi, chunki har doim juda ko'p nuanslar mavjud va ular muayyan dasturga bog'liq. Aytgancha, men GitOps-ni juda tavsiya qilaman - bu hayotni ancha osonlashtiradi va xavfsizlikni yaxshilaydi.
Umid qilamanki, ushbu mavzu bo'yicha tajribam sizning joylashtirish turiga qaysi usul ko'proq mos kelishini aniqlashga yordam beradi va men sizning fikringizni eshitishdan xursand bo'laman.
P.S. Tarjimondan eslatma
Pull modelining salbiy tomoni shundaki, renderlangan manifestlarni Git-ga qo'yish qiyin, ammo hech qanday salbiy tomoni yo'qki, tortib olish modelidagi CD trubkasi ishlab chiqarishdan alohida yashaydi va mohiyatan toifadagi quvur liniyasiga aylanadi. Doimiy qo'llash. Shuning uchun, barcha joylashtirishlardan ularning holatini yig'ish va qandaydir tarzda CD tizimiga bog'langan jurnallar/statuslarga kirishni ta'minlash uchun ko'proq harakat talab etiladi.
Shu ma'noda, surish modeli bizga hech bo'lmaganda ishlab chiqarishning ba'zi kafolatlarini ta'minlashga imkon beradi, chunki quvur liniyasining ishlash muddati ishlab chiqarish muddatiga tenglashtirilishi mumkin.
Biz ikkala modelni ham sinab ko'rdik va maqola muallifi bilan bir xil xulosaga keldik:
- Pull modeli bizga ko'p sonli klasterlarda tizim komponentlarini yangilashni tashkil qilish uchun mos keladi (qarang. ).
- GitLab CI-ga asoslangan push modeli Helm diagrammalaridan foydalangan holda ilovalarni ishlab chiqarish uchun juda mos keladi. Shu bilan birga, asbob yordamida quvur liniyalari ichida joylashtirishning tarqalishi nazorat qilinadi . Aytgancha, ushbu loyihamiz doirasida biz KubeCon Europe’19 stendimizda DevOps muhandislarining dolzarb muammolarini muhokama qilganimizda doimiy “GitOps”ni eshitdik.
Tarjimondan PPS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «";
- «".
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
GitOps dan foydalanasizmi?
-
Ha, torting
-
Ha, surish
-
Ha, torting + surish
-
Ha, boshqa narsa
-
yo'q
30 foydalanuvchi ovoz berdi. 10 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com