Eslatma. tarjima.: Yaqinda nashr etilganidan keyin GitOps-da tortish va surish usullari haqida biz ushbu modelga umuman qiziqishni ko'rdik, ammo bu mavzu bo'yicha rus tilidagi nashrlar juda kam edi (Habré-da shunchaki yo'q). Shuning uchun, biz sizning e'tiboringizga boshqa maqolaning tarjimasini taklif qilishdan mamnunmiz - deyarli bir yil oldin bo'lsa ham! — Weaveworks kompaniyasidan, uning rahbari “GitOps” atamasini kiritgan. Matn yondashuvning mohiyatini va mavjudlaridan asosiy farqlarini tushuntiradi.
Bir yil oldin biz nashr qildik . O'shanda biz Weaveworks jamoasi qanday qilib butunlay Kubernetes-ga asoslangan SaaS-ni ishga tushirgani va bulutli muhitda joylashtirish, boshqarish va monitoring qilish bo'yicha bir qator eng yaxshi amaliyotlarni ishlab chiqqani bilan o'rtoqlashdik.
Maqola mashhur bo'lib chiqdi. Boshqa odamlar GitOps haqida gapira boshlashdi va yangi vositalarni nashr etishni boshladilar , , , , va h.k. Bizning veb-saytimizda paydo bo'ldi nashrlar va GitOps-dan foydalanish holatlari. Ammo ba'zi odamlar hali ham savollarga ega. Model an'anaviydan qanday farq qiladi? va uzluksiz yetkazib berish ()? Kubernetesdan foydalanish kerakmi?
Tez orada biz yangi tavsif zarurligini angladik, taklif:
- Ko'p sonli misollar va hikoyalar;
- GitOps ning o'ziga xos ta'rifi;
- An'anaviy uzluksiz etkazib berish bilan taqqoslash.
Ushbu maqolada biz ushbu mavzularning barchasini yoritishga harakat qildik. U GitOps-ga yangilangan kirish va ishlab chiquvchi va CI/CD istiqbollarini taqdim etadi. Modelni umumlashtirish mumkin bo'lsa-da, biz birinchi navbatda Kubernetesga e'tibor qaratamiz.
GitOps bilan tanishing
Elisni tasavvur qiling. U “Famila sug‘urtasi” bilan shug‘ullanadi, u shartnomaning nozik tomonlarini o‘zlari tushuna olmay band bo‘lgan odamlarga sog‘liq, avtomashina, uy va sayohat sug‘urtasini taklif qiladi. Uning biznesi, Elis bankda ma'lumot olimi bo'lib ishlaganida, yon loyiha sifatida boshlangan. Bir kuni u ma'lumotlarni yanada samarali tahlil qilish va sug'urta paketlarini shakllantirish uchun ilg'or kompyuter algoritmlaridan foydalanishi mumkinligini tushundi. Investorlar loyihani moliyalashtirdilar va hozir uning kompaniyasi yiliga 20 million dollardan ortiq daromad keltirmoqda va tez rivojlanmoqda. Ayni paytda unda 180 nafar xodim turli lavozimlarda mehnat qilmoqda. Bu veb-saytni, ma'lumotlar bazasini ishlab chiqadigan, saqlaydigan va mijozlar bazasini tahlil qiladigan texnologiya guruhini o'z ichiga oladi. 60 kishidan iborat jamoani kompaniyaning texnik direktori Bob boshqaradi.
Bob jamoasi ishlab chiqarish tizimlarini bulutda joylashtiradi. Ularning asosiy ilovalari Google Cloud-dagi Kubernetes-dan foydalangan holda GKE-da ishlaydi. Bundan tashqari, ular o'z ishlarida turli ma'lumotlar va tahliliy vositalardan foydalanadilar.
Family Insurance konteynerlardan foydalanishni maqsad qilgani yo'q, lekin Docker ishtiyoqiga berilib ketdi. Tez orada kompaniya GKE yangi xususiyatlarni sinab ko'rish uchun klasterlarni joylashtirishni oson va oson qilishini aniqladi. Konteynerlar reestrini tashkil qilish uchun CI va Quay uchun Jenkins qo'shildi, Jenkins uchun yangi konteynerlar va konfiguratsiyalarni GKE ga o'tkazgan skriptlar yozildi.
Biroz vaqt o'tdi. Elis va Bob o'zlari tanlagan yondashuv va uning biznesga ta'siridan hafsalasi pir bo'ldi. Konteynerlarning joriy etilishi jamoa kutganidek unumdorlikni oshirmadi. Ba'zida joylashtirishlar buziladi va kod o'zgarishlari aybdor yoki yo'qmi noma'lum edi. Bundan tashqari, konfiguratsiya o'zgarishlarini kuzatish qiyin bo'lib chiqdi. Ko'pincha yangi klaster yaratish va unga ilovalarni ko'chirish kerak edi, chunki bu tizimdagi tartibsizliklarni bartaraf etishning eng oson yo'li edi. Elis dastur ishlab chiqilishi bilan vaziyat yomonlashishidan qo'rqardi (bundan tashqari, mashinani o'rganishga asoslangan yangi loyiha ishlab chiqilmoqda). Bob ishning ko'p qismini avtomatlashtirgan va nima uchun quvur liniyasi hali ham beqarorligini, yaxshi miqyosda emasligini va vaqti-vaqti bilan qo'lda aralashuvni talab qilayotganini tushunmadi?
Keyin ular GitOps haqida bilib olishdi. Bu qaror ular ishonch bilan oldinga siljishlari kerak bo'lgan narsa bo'lib chiqdi.
Elis va Bob yillar davomida Git, DevOps va infratuzilmani kodning ish oqimi sifatida eshitishgan. GitOps-ning o'ziga xos jihati shundaki, u Kubernetes kontekstida ushbu g'oyalarni amalga oshirish uchun eng yaxshi amaliyotlar to'plamini (ham aniq, ham me'yoriy) keltiradi. Bu mavzu , jumladan .
Family Insurance GitOps-ni joriy etishga qaror qildi. Endi kompaniyada Kubernetes va kombinatlarga mos keladigan avtomatlashtirilgan ish modeli mavjud tezlik bilan barqarorlikchunki ular:
- hech kim aqldan ozgan holda jamoaning mahsuldorligi ikki barobarga oshganini aniqladi;
- skriptlarga xizmat ko'rsatishni to'xtatdi. Buning o'rniga, ular endi yangi funksiyalarga e'tibor qaratishlari va muhandislik usullarini yaxshilashlari mumkin - masalan, kanareykalarni ishlab chiqarishni joriy qilish va testlarni yaxshilash;
- biz joylashtirish jarayonini yaxshiladik, shuning uchun u kamdan-kam hollarda buziladi;
- qo'l aralashuvisiz qisman nosozliklardan keyin joylashtirishni tiklash imkoniyatiga ega bo'ldi;
- sotib olingan ishlatilganоYetkazib berish tizimlariga bo'lgan ishonch. Elis va Bob jamoani parallel ravishda ishlaydigan mikroservis guruhlariga bo'lishlari mumkinligini aniqladilar;
- har bir guruhning sa'y-harakatlari bilan loyihaga har kuni 30-50 ta o'zgartirish kiritishi va yangi texnikani sinab ko'rishi mumkin;
- loyihaga yangi ishlab chiquvchilarni jalb qilish oson, ular bir necha soat ichida tortib olish so'rovlari yordamida ishlab chiqarishga yangilanishlarni tarqatish imkoniyatiga ega;
- SOC2 doirasida auditdan osongina o'tish (xizmat ko'rsatuvchi provayderlarning ma'lumotlarni xavfsiz boshqarish talablariga muvofiqligi uchun; ko'proq o'qing, masalan, - taxminan. tarjima.).
Nima sodir bo `LDI?
GitOps ikkita narsadir:
- Kubernetes va bulutli uchun operatsion model. U konteynerlashtirilgan klasterlar va ilovalarni joylashtirish, boshqarish va monitoring qilish bo'yicha eng yaxshi amaliyotlar to'plamini taqdim etadi. Shaklda oqlangan ta'rif от :
- Dasturchilarga yo'naltirilgan ilovalarni boshqarish muhitini yaratish yo'li. Biz Git ish jarayonini ham operatsiyalar, ham ishlab chiqish uchun qo'llaymiz. Esda tutingki, bu faqat Git push haqida emas, balki CI/CD va UI/UX vositalarining butun majmuasini tashkil qilish haqida.
Git haqida bir necha so'z
Agar siz versiyalarni boshqarish tizimlari va Git-ga asoslangan ish jarayoni bilan tanish bo'lmasangiz, ular haqida o'rganishni tavsiya qilamiz. Filiallar bilan ishlash va tortishish so'rovlari dastlab qora sehr kabi ko'rinishi mumkin, ammo foydalari kuchga arziydi. Bu yerga boshlanishiga.
Kubernetes qanday ishlaydi
Bizning hikoyamizda Elis va Bob Kubernetes bilan bir muddat ishlagandan so'ng GitOps-ga murojaat qilishdi. Darhaqiqat, GitOps Kubernetes bilan chambarchas bog'liq - bu Kubernetesga asoslangan infratuzilma va ilovalar uchun operatsion model.
Kubernetes foydalanuvchilarga nima beradi?
Bu erda bir nechta asosiy xususiyatlar mavjud:
- Kubernetes modelida hamma narsani deklarativ shaklda tasvirlash mumkin.
- Kubernetes API serveri ushbu deklaratsiyani kirish sifatida qabul qiladi va keyin doimiy ravishda klasterni deklaratsiyada tasvirlangan holatga keltirishga harakat qiladi.
- Deklaratsiyalar turli xil ish yuklarini - "ilovalarni" tavsiflash va boshqarish uchun etarli.
- Natijada, ilova va klasterdagi o'zgarishlar quyidagilarga bog'liq:
- konteyner tasviridagi o'zgarishlar;
- deklarativ spetsifikatsiyaga o'zgartirishlar;
- muhitdagi xatolar - masalan, konteyner qulashi.
Kubernetesning katta konvergentsiya qobiliyatlari
Administrator konfiguratsiyaga oʻzgartirishlar kiritganida, Kubernetes orkestri ularni klaster holatiga koʻra qoʻllaydi. yangi konfiguratsiyaga yaqinlashmaydi. Ushbu model har qanday Kubernetes resursi uchun ishlaydi va Custom Resource Definitions (CRDs) bilan kengaytirilishi mumkin. Shunday qilib, Kubernetes o'rnatish quyidagi ajoyib xususiyatlarga ega:
- Avtomatlashtirish: Kubernetes yangilanishlari o'zgarishlarni oqilona va o'z vaqtida qo'llash jarayonini avtomatlashtirish mexanizmini taqdim etadi.
- Konvergentsiya: Kubernetes muvaffaqiyatli bo'lgunga qadar yangilanishlarga urinishda davom etadi.
- Idroksizlik: Konvergentsiyaning takroriy qo'llanilishi bir xil natijaga olib keladi.
- Determinizm: Resurslar etarli bo'lganda, yangilangan klasterning holati faqat kerakli holatga bog'liq.
GitOps qanday ishlaydi
GitOps qanday ishlashini tushuntirish uchun biz Kubernetes haqida yetarlicha ma’lumot oldik.
Keling, Family Insurance mikroservislari guruhlariga qaytaylik. Ular odatda nima qilishlari kerak? Quyidagi ro'yxatga qarang (agar undagi biror narsa g'alati yoki notanish bo'lib tuyulsa, tanqid qilishni to'xtating va biz bilan qoling). Bu faqat Jenkins asosidagi ish oqimlarining misollari. Boshqa vositalar bilan ishlashda boshqa ko'plab jarayonlar mavjud.
Asosiysi, biz har bir yangilanish konfiguratsiya fayllari va Git omborlariga o'zgartirishlar bilan yakunlanishini ko'ramiz. Git-ga kiritilgan ushbu o'zgarishlar "GitOps operatori" klasterni yangilashiga olib keladi:
1.Ish jarayoni: "Jenkins qurish - master filiali".
Vazifalar ro'yxati:
- Jenkins yorliqli tasvirlarni Quayga suradi;
- Jenkins konfiguratsiya va Helm diagrammalarini asosiy saqlash paqiriga suradi;
- Bulutli funksiya konfiguratsiya va diagrammalarni asosiy saqlash paqiridan asosiy Git omboriga nusxalaydi;
- GitOps operatori klasterni yangilaydi.
2. Jenkins qurish - chiqarish yoki tuzatish filiali:
- Jenkins yorliqsiz tasvirlarni Quayga suradi;
- Jenkins konfiguratsiya va Helm diagrammalarini saqlash paqiriga suradi;
- Bulutli funksiya konfiguratsiya va diagrammalarni bosqichma-bosqich saqlash paqiridan Git omboriga ko'chiradi;
- GitOps operatori klasterni yangilaydi.
3. Jenkins qurish - tarmoqni ishlab chiqish yoki xususiyat:
- Jenkins yorliqsiz tasvirlarni Quayga suradi;
- Jenkins konfiguratsiya va Helm diagrammalarini ishlab chiquvchi saqlash paqiriga suradi;
- Bulutli funksiya konfiguratsiya va diagrammalarni ishlab chiquvchi saqlash paqiridan ishlab Git omboriga nusxalaydi;
- GitOps operatori klasterni yangilaydi.
4. Yangi mijoz qo'shish:
- Menejer yoki administrator (LCM/ops) Gradle-ni dastlab tarmoq yuki balanslagichlarini (NLB) o'rnatish va sozlash uchun chaqiradi;
- LCM/ops o'rnatishni yangilanishlarga tayyorlash uchun yangi konfiguratsiyani amalga oshiradi;
- GitOps operatori klasterni yangilaydi.
GitOps-ning qisqacha tavsifi
- Har bir muhit uchun deklarativ spetsifikatsiyalar yordamida butun tizimning istalgan holatini tasvirlab bering (bizning hikoyamizda Bobning jamoasi Git-da butun tizim konfiguratsiyasini belgilaydi).
- Git ombori butun tizimning istalgan holatiga oid yagona haqiqat manbaidir.
- Istalgan holatdagi barcha o'zgarishlar Git-dagi majburiyatlar orqali amalga oshiriladi.
- Klasterning barcha kerakli parametrlari klasterning o'zida ham kuzatilishi mumkin. Shu tarzda biz ularning mos kelishini aniqlashimiz mumkin (birlashma, yaqinlashmoq) yoki farqlanadi (ajralish, ajralish) kerakli va kuzatilgan holatlar.
- Agar istalgan va kuzatilgan holatlar farq qilsa, u holda:
- Ertami-kechmi maqsad va kuzatilgan holatlarni avtomatik ravishda sinxronlashtiradigan konvergentsiya mexanizmi mavjud. Klaster ichida Kubernetes buni amalga oshiradi.
- Jarayon darhol "o'zgarishlar kiritilgan" ogohlantirishi bilan boshlanadi.
- Ba'zi sozlanishi mumkin bo'lgan vaqtdan so'ng, agar davlatlar boshqacha bo'lsa, "farq" ogohlantirishi yuborilishi mumkin.
- Shunday qilib, Git-dagi barcha majburiyatlar klasterda tekshiriladigan va idempotent yangilanishlarni keltirib chiqaradi.
- Orqaga qaytarish - bu oldindan kerakli holatga yaqinlashish.
- Konvergentsiya yakuniy hisoblanadi. Uning paydo bo'lishi quyidagilar bilan ko'rsatiladi:
- Muayyan vaqt uchun farqlar haqida ogohlantirishlar yo'q.
- "Birlashtirilgan" ogohlantirish (masalan, webhook, Git writeback hodisasi).
Divergentsiya nima?
Yana takrorlaymiz: barcha kerakli klaster xususiyatlari klasterning o'zida kuzatilishi kerak.
Divergentsiyaga ba'zi misollar:
- Git-da filiallarni birlashtirish tufayli konfiguratsiya faylidagi o'zgarish.
- GUI mijozi tomonidan amalga oshirilgan Git majburiyati tufayli konfiguratsiya faylidagi o'zgarish.
- Git-da PR tufayli istalgan holatga bir nechta o'zgarishlar, keyin konteyner tasvirini yaratish va konfiguratsiya o'zgarishlari.
- Xato tufayli klaster holatining o'zgarishi, "yomon xatti-harakat" ga olib keladigan resurs ziddiyatlari yoki oddiygina asl holatdan tasodifiy og'ish.
Konvergentsiya mexanizmi qanday?
Bir nechta misol:
- Konteynerlar va klasterlar uchun konvergentsiya mexanizmi Kubernetes tomonidan taqdim etiladi.
- Xuddi shu mexanizm Kubernetes-ga asoslangan ilovalar va dizaynlarni (masalan, Istio va Kubeflow) boshqarish uchun ishlatilishi mumkin.
- Kubernetes, tasvir omborlari va Git o'rtasidagi operativ o'zaro aloqani boshqarish mexanizmi taqdim etadi , qaysi qismi hisoblanadi .
- Asosiy mashinalar uchun konvergentsiya mexanizmi deklarativ va avtonom bo'lishi kerak. O'z tajribamizdan shuni aytishimiz mumkin bu ta'rifga eng yaqin, lekin baribir inson nazoratini talab qiladi. Shu ma'noda, GitOps Infratuzilma an'anasini Code sifatida kengaytiradi.
GitOps Git-ni Kubernetes-ning mukammal konvergentsiya mexanizmi bilan birlashtirib, ekspluatatsiya uchun modelni taqdim etadi.
GitOps bizga aytishga imkon beradi: Faqat tavsiflanishi va kuzatilishi mumkin bo'lgan tizimlarni avtomatlashtirish va boshqarish mumkin.
GitOps butun bulutli mahalliy stek uchun mo'ljallangan (masalan, Terraform va boshqalar).
GitOps shunchaki Kubernetes emas. Biz butun tizim deklarativ tarzda boshqarilishini va konvergentsiyadan foydalanishini istaymiz. Butun tizim deganda biz Kubernetes bilan ishlaydigan muhitlar to'plamini tushunamiz - masalan, "dev klaster 1", "ishlab chiqarish" va boshqalar. Har bir muhit mashinalar, klasterlar, ilovalar, shuningdek, ma'lumotlar, monitoringni ta'minlaydigan tashqi xizmatlar uchun interfeyslarni o'z ichiga oladi. va boshqalar.
Bu holda yuklash muammosi uchun Terraform qanchalik muhimligiga e'tibor bering. Kubernetes biron bir joyda joylashtirilishi kerak va Terraform-dan foydalanish biz Kubernetes va ilovalarni qo'llab-quvvatlaydigan boshqaruv qatlamini yaratish uchun bir xil GitOps ish oqimlarini qo'llashimiz mumkinligini anglatadi. Bu foydali eng yaxshi amaliyotdir.
GitOps tushunchalarini Kubernetes tepasidagi qatlamlarga qoʻllashga katta eʼtibor qaratilgan. Ayni paytda Istio, Helm, Ksonnet, OpenFaaS va Kubeflow uchun, shuningdek, masalan, Pulumi uchun GitOps tipidagi yechimlar mavjud bo'lib, ular bulutli uchun ilovalarni ishlab chiqish uchun qatlam yaratadi.
Kubernetes CI/CD: GitOps-ni boshqa yondashuvlar bilan solishtirish
Aytilganidek, GitOps ikkita narsadir:
- Kubernetes va bulutli uchun operatsion model yuqorida tavsiflangan.
- Dasturchilarga yo'naltirilgan ilovalarni boshqarish muhitiga yo'l.
Ko'pchilik uchun GitOps birinchi navbatda Git pushlariga asoslangan ish oqimidir. Bizga ham u yoqadi. Ammo bu hammasi emas: endi CI/CD quvurlarini ko'rib chiqaylik.
GitOps Kubernetes uchun uzluksiz joylashtirish (CD) imkonini beradi
GitOps uzluksiz joylashtirish mexanizmini taklif qiladi, bu alohida "joylashtirishni boshqarish tizimlari" ga ehtiyojni yo'q qiladi. Kubernetes siz uchun barcha ishlarni qiladi.
- Ilovani yangilash Git-da yangilashni talab qiladi. Bu kerakli holatga tranzaksiya yangilanishi. Keyin yangilangan tavsifga asoslanib, "joylashtirish" Kubernetes tomonidan klaster ichida amalga oshiriladi.
- Kubernetes qanday ishlashiga ko'ra, bu yangilanishlar konvergent hisoblanadi. Bu barcha yangilanishlar atomik bo'lgan uzluksiz joylashtirish mexanizmini ta'minlaydi.
- Eslatma: Git va Kubernetesni birlashtirgan GitOps operatorini taklif qiladi va klasterning istalgan va joriy holatini moslashtirish orqali CDni bajarishga imkon beradi.
Kubectl va skriptlarsiz
Klasteringizni yangilash uchun Kubectl-dan foydalanishdan qochishingiz kerak va ayniqsa kubectl buyruqlarini guruhlash uchun skriptlardan foydalanmaslik kerak. Buning o'rniga, GitOps quvur liniyasi bilan foydalanuvchi Git orqali Kubernetes klasterini yangilashi mumkin.
Imtiyozlarga quyidagilar kiradi:
- To'g'ri. Yangilanishlar guruhi qo'llanilishi, birlashtirilishi va nihoyat tasdiqlanishi mumkin, bu bizni atomni joylashtirish maqsadiga yaqinlashtiradi. Aksincha, skriptlardan foydalanish konvergentsiyani kafolatlamaydi (quyida bu haqda batafsilroq).
- Xavfsizlik. Kelsi Xaytauer: "Kubernetes klasteringizga kirishni avtomatlashtirish vositalari va uni tuzatish yoki saqlash uchun mas'ul bo'lgan ma'murlar bilan cheklang." Shuningdek qarang xavfsizlik va texnik shartlarga muvofiqligi haqida, shuningdek beparvolik bilan yozilgan Jenkins skriptidan hisob ma'lumotlarini o'g'irlash orqali.
- Foydalanuvchi tajribasi. Kubectl juda murakkab bo'lgan Kubernetes ob'ekt modelining mexanikasini ochib beradi. Ideal holda, foydalanuvchilar mavhumlikning yuqori darajasida tizim bilan o'zaro aloqada bo'lishlari kerak. Bu erda men yana Kelsiga murojaat qilaman va tomosha qilishni tavsiya qilaman .
CI va CD o'rtasidagi farq
GitOps mavjud CI/CD modellarini yaxshilaydi.
Zamonaviy CI serveri orkestratsiya vositasidir. Xususan, bu CI quvurlarini tartibga solish uchun vositadir. Bularga qurish, test qilish, magistralga birlashtirish va hokazolar kiradi. CI serverlari murakkab ko'p bosqichli quvurlarni boshqarishni avtomatlashtiradi. Umumiy vasvasa Kubernetes yangilanishlari toʻplamini skript qilish va klasterga oʻzgarishlar kiritish uchun uni quvur liniyasining bir qismi sifatida ishga tushirishdir. Darhaqiqat, ko'plab mutaxassislar buni qilishadi. Biroq, bu optimal emas va buning sababi.
CI yangilanishlarni magistralga yuborish uchun ishlatilishi kerak va Kubernetes klasteri CDni ichki boshqarish uchun ushbu yangilanishlar asosida o'zini o'zgartirishi kerak. Biz chaqiramiz , CI push modelidan farqli o'laroq. CD qismidir ish vaqti orkestratsiyasi.
Nima uchun CI serverlari Kubernetes-dagi to'g'ridan-to'g'ri yangilanishlar orqali kompakt disklarni yaratmasligi kerak
Kubernetesga toʻgʻridan-toʻgʻri yangilanishlarni CI vazifalari toʻplami sifatida oʻrnatish uchun CI serveridan foydalanmang. Bu biz gapiradigan anti-naqsh mening blogimda.
Keling, Elis va Bobga qaytaylik.
Ular qanday muammolarga duch kelishdi? Bobning CI serveri oʻzgarishlarni klasterga qoʻllaydi, biroq u jarayonda ishlamay qolsa, Bob klaster qanday holatda (yoki boʻlishi kerak) yoki uni qanday tuzatish kerakligini bilmaydi. Muvaffaqiyatli taqdirda ham xuddi shunday.
Faraz qilaylik, Bobning jamoasi yangi tasvirni yaratdi va keyin tasvirni joylashtirish uchun o'z joylashuvlarini tuzatdi (barchasi CI quvuridan).
Agar rasm an'anaviy tarzda qurilsa, lekin quvur liniyasi muvaffaqiyatsiz bo'lsa, jamoa quyidagilarni aniqlashi kerak:
- Yangilanish chiqdimi?
- Yangi qurilishni ishga tushiryapmizmi? Bu keraksiz yon ta'sirga olib keladimi - bir xil o'zgarmas tasvirning ikkita tuzilishiga ega bo'lish imkoniyati bilan?
- Qurilishni ishga tushirishdan oldin keyingi yangilanishni kutishimiz kerakmi?
- Aynan nima xato ketdi? Qaysi qadamlarni takrorlash kerak (va qaysilarini takrorlash xavfsiz)?
Git-ga asoslangan ish oqimini o'rnatish Bobning jamoasi bu muammolarga duch kelmasligiga kafolat bermaydi. Ular hali ham commit push, teg yoki boshqa parametr bilan xato qilishlari mumkin; ammo, bu yondashuv hali ham ochiq-oydin hamma yoki hech narsa yondashuviga ancha yaqin.
Xulosa qilib aytganda, nima uchun CI serverlari CD bilan ishlamasligi kerak:
- Yangilanish skriptlari har doim ham deterministik emas; Ularda xato qilish oson.
- CI serverlari deklarativ klaster modeliga yaqinlashmaydi.
- Idepotentlikni kafolatlash qiyin. Foydalanuvchilar tizimning chuqur semantikasini tushunishlari kerak.
- Qisman muvaffaqiyatsizlikdan keyin tiklanish qiyinroq.
Helm haqida eslatma: Agar siz Helm-dan foydalanmoqchi bo'lsangiz, uni GitOps operatori bilan birlashtirishni tavsiya etamiz, masalan. . Bu konvergentsiyani ta'minlashga yordam beradi. Helmning o'zi na deterministik, na atomik.
GitOps Kubernetes uchun uzluksiz yetkazib berishni amalga oshirishning eng yaxshi usuli sifatida
Elis va Bob jamoasi GitOps-ni qo'llaydi va dasturiy mahsulotlar bilan ishlash, yuqori unumdorlik va barqarorlikni saqlash ancha osonlashganini aniqladi. Keling, ushbu maqolani ularning yangi yondashuvi qanday ko'rinishini ko'rsatadigan rasm bilan yakunlaylik. Shuni yodda tutingki, biz asosan ilovalar va xizmatlar haqida gapiramiz, lekin GitOps butun platformani boshqarish uchun ishlatilishi mumkin.
Kubernetes uchun operatsion model
Quyidagi diagrammaga qarang. U Git va konteyner tasvirlari omborini ikkita tashkil etilgan hayot aylanishi uchun umumiy manbalar sifatida taqdim etadi:
- Git-ga fayllarni o'qiydigan va yozadigan va konteyner tasvirlari omborini yangilaydigan uzluksiz integratsiya quvur liniyasi.
- Joylashtirishni boshqaruv va kuzatuvchanlik bilan birlashtirgan Runtime GitOps quvur liniyasi. U Git-ga fayllarni o'qiydi va yozadi va konteyner tasvirlarini yuklab olishi mumkin.
Asosiy topilmalar qanday?
- Xavotirlarni ajratish: E'tibor bering, ikkala quvur liniyasi ham faqat Git yoki tasvirlar omborini yangilash orqali bog'lanishi mumkin. Boshqacha qilib aytganda, CI va ish vaqti muhiti o'rtasida xavfsizlik devori mavjud. Biz uni "o'zgarmas xavfsizlik devori" deb ataymiz. (o'zgarmas xavfsizlik devori), chunki barcha ombor yangilanishlari yangi versiyalarni yaratadi. Ushbu mavzu bo'yicha qo'shimcha ma'lumot olish uchun 72-87-slaydlarga qarang .
- Siz har qanday CI va Git serveridan foydalanishingiz mumkin: GitOps har qanday komponent bilan ishlaydi. Sevimli CI va Git serverlaringiz, tasvirlar ombori va test toʻplamlaridan foydalanishni davom ettirishingiz mumkin. Bozordagi deyarli barcha boshqa Uzluksiz yetkazib berish vositalari o'zlarining CI/Git serveri yoki tasvirlar omborini talab qiladi. Bu mahalliy bulutni rivojlantirishda cheklovchi omilga aylanishi mumkin. GitOps yordamida siz tanish vositalardan foydalanishingiz mumkin.
- Hodisalar integratsiya vositasi sifatida: Git-dagi ma'lumotlar yangilanishi bilan Weave Flux (yoki Weave Cloud operatori) ish vaqti haqida xabar beradi. Kubernetes o'zgarishlar to'plamini qabul qilganda, Git yangilanadi. Bu quyida ko'rsatilganidek, GitOps uchun ish oqimlarini tashkil qilish uchun oddiy integratsiya modelini taqdim etadi.
xulosa
GitOps har qanday zamonaviy CI/CD vositasi tomonidan talab qilinadigan kuchli yangilanish kafolatlarini taqdim etadi:
- avtomatlashtirish;
- konvergentsiya;
- qobiliyatsizlik;
- determinizm.
Bu juda muhim, chunki u bulutli mahalliy ishlab chiquvchilar uchun operatsion modelni taklif qiladi.
- Tizimlarni boshqarish va monitoring qilish uchun an'anaviy vositalar runbook ichida ishlaydigan operatsion guruhlar bilan bog'liq (muntazam protseduralar va operatsiyalar to'plami - taxminan tarjimasi), ma'lum bir joylashtirishga bog'langan.
- Bulutli mahalliy boshqaruvda kuzatuvchanlik vositalari ishlab chiqish guruhi tezda javob berishi uchun joylashtirish natijalarini o'lchashning eng yaxshi usuli hisoblanadi.
Turli xil bulutlar va ko'plab xizmatlar bo'ylab tarqalgan ko'plab klasterlarni o'z jamoalari va joylashtirish rejalari bilan tasavvur qiling. GitOps bu mo'l-ko'llikni boshqarish uchun miqyosda o'zgarmas modelni taklif qiladi.
Tarjimondan PS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «".
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Ushbu ikki tarjima Habré-da paydo bo'lishidan oldin GitOps haqida bilarmidingiz?
-
Ha, men hamma narsani bilardim
-
Faqat yuzaki
-
yo'q
35 foydalanuvchi ovoz berdi. 10 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com