Анхаарна уу. орчуулга.: Саяхан хэвлэгдсэний дараа GitOps дахь татах, түлхэх аргуудын талаар бид энэ загварыг ерөнхийд нь сонирхож байсан боловч энэ сэдвээр орос хэл дээрх нийтлэлүүд маш цөөхөн байсан (Habré дээр ердөө л байдаггүй). Тиймээс, бараг жилийн өмнөх ч гэсэн өөр нэг нийтлэлийн орчуулгыг танд санал болгож байгаадаа баяртай байна! - "GitOps" гэсэн нэр томъёог бүтээсэн Weaveworks компани. Текст нь аргын мөн чанар, одоо байгаа аргуудаас гол ялгааг тайлбарласан болно.
Жилийн өмнө бид нийтэлсэн . Тэр үед бид Weaveworks баг хэрхэн бүхэлдээ Kubernetes-д суурилсан SaaS-ийг эхлүүлж, үүлэн орчинд ашиглах, удирдах, хянах шилдэг туршлагуудыг боловсруулсан талаар хуваалцсан.
Нийтлэл алдартай болсон. Бусад хүмүүс GitOps-ийн талаар ярьж, шинэ хэрэгслүүдийг нийтэлж эхлэв , , , , гэх мэт. Манай сайт дээр гарсан хэвлэл болон GitOps ашиглах тохиолдлууд. Гэхдээ зарим хүмүүст асуулт байсаар байна. Загвар нь уламжлалт загвараас юугаараа ялгаатай вэ? болон тасралтгүй хүргэх ()? Kubernetes ашиглах шаардлагатай юу?
Бид удалгүй шинэ тайлбар хэрэгтэйг ойлгож, дараахь зүйлийг санал болгож байна.
- Олон тооны жишээ, түүхүүд;
- GitOps-ийн тусгай тодорхойлолт;
- Уламжлалт тасралтгүй хүргэлттэй харьцуулах.
Энэ нийтлэлд бид эдгээр бүх сэдвийг хамрах гэж оролдсон. Энэ нь GitOps-ийн шинэчилсэн танилцуулга, хөгжүүлэгч болон CI/CD-ийн хэтийн төлөвийг өгдөг. Загварыг ерөнхийд нь хэлж болох ч бид юуны түрүүнд Кубернетес дээр анхаарлаа хандуулдаг.
GitOps-той танилц
Алисыг төсөөлөөд үз дээ. Тэрээр Гэр бүлийн даатгалыг ажиллуулдаг бөгөөд энэ нь гэрээнийхээ нарийн ширийнийг өөрсдөө ойлгоход хэтэрхий завгүй хүмүүст эрүүл мэнд, автомашин, гэр, аялалын даатгалд санал болгодог. Алис банкинд өгөгдөл судлаачаар ажиллаж байх үед түүний бизнес нь хажуугийн төсөл болж эхэлсэн. Нэгэн өдөр тэрээр компьютерийн дэвшилтэт алгоритмуудыг ашиглан өгөгдөлд илүү үр дүнтэй дүн шинжилгээ хийж, даатгалын багцыг боловсруулах боломжтой гэдгээ ойлгов. Хөрөнгө оруулагчид уг төслийг санхүүжүүлсэн бөгөөд одоо түүний компани жилд 20 гаруй сая долларын орлого оруулж, хурдацтай хөгжиж байна. Одоогоор 180 хүнийг янз бүрийн албан тушаалд ажиллуулж байна. Үүнд вэб сайт, мэдээллийн сан, хэрэглэгчийн баазыг задлан шинжилдэг технологийн баг багтдаг. 60 хүний бүрэлдэхүүнтэй багийг тус компанийн техникийн захирал Боб ахалж байна.
Бобын баг үйлдвэрлэлийн системийг үүлэн дээр байрлуулдаг. Тэдний үндсэн програмууд нь Google Cloud дээрх Kubernetes-ийн давуу талыг ашиглан GKE дээр ажилладаг. Үүнээс гадна тэд ажилдаа янз бүрийн өгөгдөл, аналитик хэрэгслийг ашигладаг.
Family Insurance нь чингэлэг ашиглах зорилго тавиагүй ч Докерын урам зоригт автсан. Удалгүй компани GKE нь шинэ функцуудыг туршихын тулд кластеруудыг байрлуулахад хялбар болгосныг олж мэдсэн. Контейнерын бүртгэлийг зохион байгуулахын тулд CI болон Quay-д зориулсан Jenkins-ийг нэмж, Женкинст зориулсан скриптүүдийг бичсэн бөгөөд GKE-д шинэ контейнер, тохиргоог түлхсэн.
Хэсэг хугацаа өнгөрчээ. Алис, Боб нар сонгосон арга барилынхаа гүйцэтгэл, бизнест үзүүлэх нөлөөлөлдөө сэтгэл дундуур байв. Савыг ашиглалтад оруулсан нь ажлын бүтээмжийг багийн бодож байсан шиг сайжруулсангүй. Заримдаа байршуулалт эвдэрч, кодын өөрчлөлтөд буруутай эсэх нь тодорхойгүй байв. Мөн тохиргооны өөрчлөлтийг хянахад хэцүү болсон. Ихэнхдээ шинэ кластер үүсгэж, програмуудыг түүн рүү шилжүүлэх шаардлагатай байсан, учир нь энэ нь системд үүссэн эмх замбараагүй байдлыг арилгах хамгийн хялбар арга юм. Аппликейшн хөгжихийн хэрээр нөхцөл байдал улам дордох вий гэж Алис айж байсан (үүнээс гадна машин сургалтанд суурилсан шинэ төсөл боловсруулж байна). Боб ихэнх ажлыг автоматжуулсан бөгөөд дамжуулах хоолой яагаад тогтворгүй хэвээр, сайн масштабтай биш, үе үе гар аргаар хөндлөнгөөс оролцох шаардлагатай байгааг ойлгохгүй байна уу?
Дараа нь тэд GitOps-ийн талаар олж мэдсэн. Энэ шийдвэр нь тэдэнд итгэлтэйгээр урагшлахад яг хэрэгтэй зүйл болж хувирав.
Алис, Боб нар Git, DevOps болон дэд бүтцийн талаар олон жилийн турш кодын ажлын урсгал гэж сонссон. GitOps-ийн онцлог нь эдгээр санааг Kubernetes-ийн хүрээнд хэрэгжүүлэх эцсийн болон нормативын шилдэг туршлагуудыг авчирдаг явдал юм. Энэ сэдэв , түүний дотор .
Гэр бүлийн даатгал нь GitOps-ийг хэрэгжүүлэхээр шийджээ. Тус компани одоо Kubernetes болон комбайнуудтай нийцэх автоматжуулсан үйлдлийн загвартай болсон хурд нь тогтвортой байдаляагаад гэвэл тэд:
- хэн ч галзуурахгүйгээр багийн бүтээмж хоёр дахин нэмэгддэг болохыг олж мэдсэн;
- скриптээр үйлчлэхээ больсон. Үүний оронд тэд одоо шинэ боломжууд дээр анхаарлаа төвлөрүүлж, инженерийн аргуудыг сайжруулах боломжтой - жишээлбэл, канарыг нэвтрүүлэх, туршилтыг сайжруулах;
- бид байршуулах үйл явцыг сайжруулсан бөгөөд энэ нь ховор эвдэрдэг;
- гар оролцоогүйгээр хэсэгчилсэн эвдрэлийн дараа байршуулалтыг сэргээх боломжтой болсон;
- худалдаж авсан ашигласаноХүргэлтийн системд итгэх итгэл. Алис, Боб нар багаа зэрэгцүүлэн ажиллаж буй бичил үйлчилгээний баг болгон хувааж болохыг олж мэдсэн;
- бүлэг бүрийн хүчин чармайлтаар төсөлд өдөр бүр 30-50 өөрчлөлт хийж, шинэ арга техникийг туршиж үзэх боломжтой;
- хэдхэн цагийн дотор татах хүсэлтийг ашиглан үйлдвэрлэлд шинэчлэлт хийх боломжтой шинэ хөгжүүлэгчдийг төсөлд татахад хялбар байдаг;
- SOC2-ийн хүрээнд аудитыг хялбархан давах (үйлчилгээ үзүүлэгчдийн аюулгүй мэдээллийн менежментийн шаардлагыг дагаж мөрдөх; жишээлбэл, дэлгэрэнгүй уншина уу - ойролцоогоор. орчуул.).
Юу болсон бэ?
GitOps нь хоёр зүйл юм:
- Kubernetes болон үүлэнд зориулсан үйлдлийн загвар. Энэ нь чингэлэгжсэн кластер болон програмуудыг байрлуулах, удирдах, хянах шилдэг туршлагуудын багцыг өгдөг. Маягт дахь гоёмсог тодорхойлолт нь :
- Хөгжүүлэгч төвтэй хэрэглээний удирдлагын орчинг бий болгох зам. Бид Git ажлын урсгалыг үйл ажиллагаа болон хөгжүүлэлтэд ашигладаг. Энэ нь зөвхөн Git push-ийн тухай биш, харин CI/CD болон UI/UX хэрэгслийг бүхэлд нь зохион байгуулах тухай гэдгийг анхаарна уу.
Гитийн тухай хэдэн үг
Хэрэв та хувилбарын хяналтын систем болон Git-д суурилсан ажлын урсгалын талаар сайн мэдэхгүй байгаа бол бид тэдгээрийн талаар суралцахыг зөвлөж байна. Салбаруудтай ажиллах, татах хүсэлтүүд нь эхлээд хар ид шид мэт санагдаж болох ч ашиг тус нь хүчин чармайлт гаргахад үнэ цэнэтэй юм. Энд эхлэх.
Кубернетес хэрхэн ажилладаг
Бидний түүхэнд Алис, Боб нар Кубернетестэй хэсэг хугацаанд ажилласны дараа GitOps руу хандсан. Үнэн хэрэгтээ GitOps нь Kubernetes-тэй нягт холбоотой бөгөөд энэ нь Kubernetes дээр суурилсан дэд бүтэц, хэрэглээний загвар юм.
Kubernetes хэрэглэгчдэд юу өгдөг вэ?
Энд зарим үндсэн шинж чанарууд байна:
- Кубернетес загварт бүх зүйлийг тунхаг хэлбэрээр дүрсэлж болно.
- Kubernetes API сервер нь энэ мэдэгдлийг оролт болгон авч дараа нь кластерыг мэдэгдэлд тодорхойлсон төлөвт оруулахыг тасралтгүй оролддог.
- Тунхаглал нь олон төрлийн ажлын ачааллыг тайлбарлах, удирдахад хангалттай байдаг - "програмууд".
- Үүний үр дүнд дараах шалтгааны улмаас програм болон кластерт өөрчлөлт орно.
- савны зураг дээрх өөрчлөлт;
- мэдүүлгийн тодорхойлолтод өөрчлөлт оруулах;
- хүрээлэн буй орчны алдаа - жишээлбэл, чингэлэг осолдох.
Кубернетесийн агуу нэгдэх чадвар
Администратор тохиргоонд өөрчлөлт оруулах үед Кубернетес найруулагч нь төлөв байдал нь хэвээр байгаа бол тэдгээрийг кластерт хэрэглэнэ. шинэ тохиргоонд ойртохгүй. Энэ загвар нь ямар ч Kubernetes нөөцөд ажилладаг бөгөөд Custom Resource Definitions (CRDs) ашиглан өргөтгөх боломжтой. Тиймээс Kubernetes байршуулалт нь дараах гайхалтай шинж чанаруудтай:
- Автоматжуулалт: Kubernetes-ийн шинэчлэлтүүд нь өөрчлөлтүүдийг цаг тухайд нь үр дүнтэй хэрэгжүүлэх үйл явцыг автоматжуулах механизмыг бий болгодог.
- Конвергенц: Kubernetes амжилттай болтол шинэчлэлт хийхийг оролдох болно.
- Чадваргүй байдал: Конвергенцийг давтан хэрэглэх нь ижил үр дүнд хүргэдэг.
- Детерминизм: Нөөц хангалттай байх үед шинэчлэгдсэн кластерийн төлөв нь зөвхөн хүссэн төлөвөөс хамаарна.
GitOps хэрхэн ажилладаг
Бид GitOps хэрхэн ажилладагийг тайлбарлахын тулд Кубернетесийн талаар хангалттай сурсан.
Гэр бүлийн даатгалын бичил үйлчилгээний багууд руу буцаж орцгооё. Тэд ихэвчлэн юу хийх ёстой вэ? Доорх жагсаалтыг харна уу (хэрэв ямар нэг зүйл хачирхалтай эсвэл танил бус мэт санагдаж байвал шүүмжлэхээ зогсоож, бидэнтэй хамт байгаарай). Эдгээр нь Женкинс дээр суурилсан ажлын урсгалын жишээ юм. Бусад хэрэгсэлтэй ажиллахад бусад олон процессууд байдаг.
Хамгийн гол нь шинэчлэлт бүр тохиргооны файлууд болон Git репозиторуудад өөрчлөлт оруулснаар дуусч байгааг бид харж байна. Git-д хийсэн эдгээр өөрчлөлтүүд нь "GitOps оператор"-ыг кластерийг шинэчлэхэд хүргэдэг:
1. Ажлын явц: "Женкинс бүтээх - мастер салбар".
Ажлын жагсаалт:
- Женкинс хаяглагдсан зургуудыг Quay руу түлхдэг;
- Женкинс тохиргоо болон Helm диаграммуудыг үндсэн хадгалах хувин руу түлхдэг;
- Клоуд функц нь тохиргоо болон диаграммуудыг мастер хадгалах хувингаас Git репозитор руу хуулдаг;
- GitOps оператор нь кластерыг шинэчилдэг.
2. Jenkins build - хувилбар буюу засварын салбар:
- Женкинс тэмдэглэгээгүй зургуудыг Quay руу түлхдэг;
- Женкинс тохиргоо болон Хелм диаграммуудыг үе шаттай хадгалах хувин руу түлхэж өгдөг;
- Үүлэн функц нь тохируулга болон диаграммуудыг үе шаттай хадгалах сангаас Git репозитор руу хуулдаг;
- GitOps оператор нь кластерыг шинэчилдэг.
3. Женкинс бүтээх - салбарыг хөгжүүлэх эсвэл онцлог:
- Женкинс тэмдэглэгээгүй зургуудыг Quay руу түлхдэг;
- Женкинс config болон Helm диаграмуудыг хөгжүүлэлтийн хадгалах хувин руу түлхдэг;
- Клоуд функц нь хөгжүүлэлтийн хадгалах сангаас тохиргоо болон графикуудыг Git репозитор руу хуулдаг;
- GitOps оператор нь кластерыг шинэчилдэг.
4. Шинэ үйлчлүүлэгч нэмж байна:
- Менежер эсвэл администратор (LCM/ops) эхлээд сүлжээний ачаалал тэнцвэржүүлэгчийг (NLBs) байрлуулж, тохируулахын тулд Gradle-г дууддаг;
- LCM/ops нь байршуулалтыг шинэчлэлтэд бэлтгэхийн тулд шинэ тохиргоо хийдэг;
- GitOps оператор нь кластерыг шинэчилдэг.
GitOps-ийн товч тайлбар
- Хүрээлэн буй орчин бүрд зориулсан тунхаглалын үзүүлэлтүүдийг ашиглан бүхэл системийн хүссэн төлөвийг дүрсэл (бидний түүхэнд Бобын баг Git дэх системийн бүх тохиргоог тодорхойлдог).
- Git репозитор нь бүхэл системийн хүссэн төлөв байдлын талаархи үнэний цорын ганц эх сурвалж юм.
- Хүссэн төлөвт хийсэн бүх өөрчлөлтийг Git-д гүйцэтгэх үүрэг гүйцэтгэдэг.
- Бүх хүссэн кластер параметрүүд нь кластерт өөрөө ажиглагдаж болно. Ингэснээр бид тэдгээр нь давхцаж байгаа эсэхийг тодорхойлох боломжтой (нийсэх, converges) эсвэл ялгаатай (ялгарах, зөрүүлэх) хүссэн болон ажиглагдсан төлөвүүд.
- Хүссэн болон ажиглагдсан төлөвүүд өөр байвал:
- Зорилтот болон ажиглагдсан төлөвүүдийг эрт орой хэзээ нэгэн цагт автоматаар синхрончлох нэгдлийн механизм байдаг. Кластер дотор Кубернетес үүнийг хийдэг.
- Уг процесс нь "өөрчлөлт хийсэн" гэсэн дохиогоор шууд эхэлдэг.
- Тохируулах боломжтой тодорхой хугацааны дараа мужууд өөр бол "ялгаа" дохиог илгээж болно.
- Ингэснээр Git дээрх бүх үйлдлүүд нь кластерт баталгаажуулах боломжтой, үл мэдэгдэх шинэчлэлтүүдийг үүсгэдэг.
- Буцах нь өмнө нь хүссэн төлөв рүү ойртох явдал юм.
- Нэгтгэл нь эцсийнх юм. Үүний илрэлийг дараахь байдлаар илэрхийлнэ.
- Тодорхой хугацааны туршид ялгаа дохио байхгүй.
- "Нэгдмэл" сэрэмжлүүлэг (жишээ нь webhook, Git writeback үйл явдал).
Зөрчилдөөн гэж юу вэ?
Дахин давтъя: Бүх хүссэн кластер шинж чанарууд нь кластер дотроос ажиглагдах ёстой.
Зөрчилдөөний зарим жишээ:
- Git дахь салбаруудыг нэгтгэсний улмаас тохиргооны файлд өөрчлөлт орсон.
- GUI үйлчлүүлэгчийн хийсэн Git-ийн үйл ажиллагааны улмаас тохиргооны файлд гарсан өөрчлөлт.
- Гит дэх PR-ийн улмаас хүссэн төлөвт хэд хэдэн өөрчлөлт хийж, дараа нь контейнерийн дүрсийг бүтээж, тохиргоог өөрчилсөн.
- Алдаа, нөөцийн зөрчлөөс үүдэн "муу зан" эсвэл анхны төлөвөөс санамсаргүй хазайлтаас үүдэн кластерын төлөвийн өөрчлөлт.
Конвергенцийн механизм юу вэ?
Жишээ нь:
- Контейнер болон кластеруудын хувьд нэгдэх механизмыг Кубернетес хангадаг.
- Үүнтэй ижил механизмыг Kubernetes-д суурилсан програмууд болон дизайныг (Istio, Kubeflow гэх мэт) удирдахад ашиглаж болно.
- Kubernetes, зургийн агуулахууд болон Git хоорондын үйл ажиллагааны харилцан үйлчлэлийг удирдах механизмыг бий болгодог , энэ нь хэсэг юм .
- Үндсэн машинуудын хувьд конвергенцийн механизм нь тунхаглалтай, бие даасан байх ёстой. Бид өөрсдийн туршлагаас үүнийг хэлж чадна Энэ тодорхойлолтод хамгийн ойр боловч хүний хяналтыг шаарддаг. Энэ утгаараа GitOps нь Дэд бүтцийн уламжлалыг код болгон өргөжүүлдэг.
GitOps нь Git-ийг Kubernetes-ийн маш сайн нэгтгэх хөдөлгүүртэй хослуулан ашиглалтын загварыг бий болгодог.
GitOps бидэнд дараахь зүйлийг хэлэх боломжийг олгодог. Зөвхөн дүрсэлж, ажиглаж болох системийг автоматжуулж, хянах боломжтой.
GitOps нь үүлний эх стекийг бүхэлд нь (жишээ нь, Terraform гэх мэт) ашиглахад зориулагдсан.
GitOps бол зөвхөн Кубернетес биш юм. Бид бүхэл бүтэн системийг тунхаглалаар удирдаж, конвергенцийг ашиглахыг хүсч байна. Бүхэл систем гэж бид Kubernetes-тэй ажилладаг орчны цуглуулгыг хэлж байна - жишээлбэл, "dev cluster 1", "production" гэх мэт. Орчлон бүрд машин, кластер, программууд, түүнчлэн өгөгдөл, мониторингоор хангадаг гадаад үйлчилгээний интерфейсүүд орно. гэх мэт.
Энэ тохиолдолд ачаалах асуудалд Terraform ямар чухал болохыг анхаарна уу. Kubernetes-ийг хаа нэг газар байрлуулах шаардлагатай бөгөөд Terraform-ийг ашигласнаар бид Kubernetes болон програмуудыг үндэслэх хяналтын давхаргыг бий болгохын тулд ижил GitOps ажлын урсгалыг ашиглаж болно гэсэн үг юм. Энэ бол ашигтай шилдэг туршлага юм.
GitOps концепцийг Kubernetes-ийн дээд давхаргад ашиглахад ихээхэн анхаарал хандуулж байна. Одоогийн байдлаар Istio, Helm, Ksonnet, OpenFaaS болон Kubeflow-д зориулсан GitOps төрлийн шийдлүүд, мөн жишээлбэл, Пулуми-д зориулсан үүлэн программуудыг хөгжүүлэх давхарга үүсгэдэг.
Kubernetes CI/CD: GitOps-ийг бусад аргуудтай харьцуулах
Дээр дурдсанчлан GitOps нь хоёр зүйл юм:
- Дээр тайлбарласан Kubernetes болон үүлэн үүлдрийн үйлдлийн загвар.
- Хөгжүүлэгч төвтэй хэрэглээний менежментийн орчинд хүрэх зам.
Олон хүмүүсийн хувьд GitOps бол Git түлхэлт дээр суурилсан ажлын урсгал юм. Бид ч бас түүнд дуртай. Гэхдээ энэ нь бүгд биш: одоо CI/CD дамжуулах хоолойнуудыг харцгаая.
GitOps нь Kubernetes-д зориулсан тасралтгүй байршуулалтыг (CD) идэвхжүүлдэг
GitOps нь тусдаа "байршуулах удирдлагын систем"-ийн хэрэгцээг арилгадаг тасралтгүй байршуулах механизмыг санал болгодог. Кубернетес таны төлөө бүх ажлыг хийдэг.
- Програмыг шинэчлэхийн тулд Git програмыг шинэчлэх шаардлагатай. Энэ нь хүссэн төлөв рүү гүйлгээний шинэчлэлт юм. Дараа нь шинэчилсэн тайлбар дээр үндэслэн Кубернетес өөрөө кластер дотор "байрлуулах" ажлыг гүйцэтгэдэг.
- Кубернетес хэрхэн ажилладаг шинж чанараас шалтгаалан эдгээр шинэчлэлтүүд нэгдэж байна. Энэ нь бүх шинэчлэлтүүд атомын шинж чанартай байдаг тасралтгүй байршуулах механизмыг хангадаг.
- Тайлбар: нь Git болон Kubernetes-ийг нэгтгэсэн GitOps операторыг санал болгож, кластерын хүссэн болон одоогийн төлөвийг нэгтгэх замаар CD-г гүйцэтгэх боломжийг олгодог.
kubectl болон скриптгүйгээр
Та кластераа шинэчлэхийн тулд Kubectl ашиглахаас зайлсхийх хэрэгтэй бөгөөд ялангуяа kubectl командуудыг бүлэглэхийн тулд скрипт ашиглахаас зайлсхийх хэрэгтэй. Үүний оронд GitOps шугамын тусламжтайгаар хэрэглэгч Git-ээр дамжуулан Kubernetes кластераа шинэчлэх боломжтой.
Үр ашиг нь:
- Зөв. Хэд хэдэн шинэчлэлтүүдийг хэрэглэж, нэгтгэж, эцэст нь баталгаажуулж, атомын байршуулалтын зорилгод ойртуулж болно. Үүний эсрэгээр, скрипт ашиглах нь нэгдмэл байдлын баталгааг өгдөггүй (энэ талаар доор дэлгэрэнгүй үзэх).
- Аюулгүй байдал. Келси Хайтоуэр: "Таны Кубернетес кластерт хандах хандалтыг автоматжуулалтын хэрэгсэл болон түүнийг засварлах, засварлах үүрэгтэй админуудад хязгаарлаарай." бас үзнэ үү аюулгүй байдал, техникийн үзүүлэлтүүдийг дагаж мөрдөх тухай, түүнчлэн хайхрамжгүй бичсэн Женкинсийн скриптээс итгэмжлэл хулгайлсан.
- Хэрэглэгчийн туршлага. Kubectl нь Kubernetes объектын загварын механикийг илчилсэн бөгөөд энэ нь нэлээд төвөгтэй юм. Хэрэглэгчид системтэй илүү өндөр түвшний хийсвэрээр харилцах нь хамгийн тохиромжтой. Энд би Келсигийн талаар дахин дурдаж, үзэхийг зөвлөж байна .
CI ба CD хоорондын ялгаа
GitOps нь одоо байгаа CI/CD загваруудыг сайжруулдаг.
Орчин үеийн CI сервер нь зохион байгуулах хэрэгсэл юм. Ялангуяа энэ нь CI дамжуулах хоолойг зохион байгуулах хэрэгсэл юм. Үүнд бүтээх, турших, trunk-д нэгтгэх гэх мэт орно. CI серверүүд нь нарийн төвөгтэй олон шатлалт дамжуулах хоолойн удирдлагыг автоматжуулдаг. Түгээмэл уруу таталт бол Kubernetes шинэчлэлтийн багцыг скрипт болгож, кластерт өөрчлөлт оруулахын тулд үүнийг дамжуулах хоолойн нэг хэсэг болгон ажиллуулах явдал юм. Үнэндээ үүнийг олон мэргэжилтнүүд хийдэг. Гэсэн хэдий ч энэ нь оновчтой биш бөгөөд яагаад гэдгийг эндээс харж болно.
CI-г шинэчлэлтүүдийг их бие рүү шилжүүлэхэд ашиглах ёстой бөгөөд Кубернетес кластер нь CD-г дотооддоо удирдахын тулд тэдгээр шинэчлэлт дээр үндэслэн өөрийгөө өөрчлөх ёстой. Бид үүнийг дууддаг , CI түлхэх загвараас ялгаатай. CD нь нэг хэсэг юм ажиллах цагийн зохион байгуулалт.
Яагаад CI серверүүд Кубернетес дэх шууд шинэчлэлтээр CD хийх ёсгүй гэж?
Kubernetes-д шууд шинэчлэлтүүдийг CI ажлын багц болгон зохион байгуулахын тулд CI серверийг бүү ашигла. Энэ бол бидний ярьж буй эсрэг загвар юм таны блог дээр.
Алис, Боб хоёр руу буцъя.
Тэдэнд ямар асуудал тулгарсан бэ? Бобын CI сервер нь өөрчлөлтийг кластерт ашигладаг боловч хэрэв энэ нь процессын явцад гацвал Боб кластер ямар төлөвт байгаа (эсвэл байх ёстой) эсвэл үүнийг хэрхэн засахаа мэдэхгүй байх болно. Амжилтанд хүрсэн тохиолдолд ч мөн адил.
Бобын баг шинэ дүр бүтээж, дараа нь зургийг байрлуулахын тулд байршуулалтаа нөхсөн гэж үзье (бүгд CI дамжуулах шугамаас).
Хэрэв зураг хэвийн бүтээгдсэн ч дамжуулах хоолой бүтэлгүйтвэл баг дараахь зүйлийг хийх шаардлагатай болно.
- Шинэчлэлт гарсан уу?
- Бид шинэ барилгаа эхлүүлж байна уу? Энэ нь шаардлагагүй гаж нөлөөнд хүргэх үү - ижил хувиршгүй дүрсийг хоёр бүтээх боломжтой юу?
- Бүтцийг ажиллуулахын өмнө бид дараагийн шинэчлэлтийг хүлээх ёстой юу?
- Яг юу нь буруу болсон бэ? Аль алхмуудыг давтах шаардлагатай (мөн аль нь давтахад аюулгүй вэ)?
Git-д суурилсан ажлын урсгалыг бий болгох нь Бобын баг эдгээр асуудалтай тулгарахгүй гэсэн баталгаа биш юм. Тэд commit түлхэлт, шошго эсвэл бусад параметрээр алдаа гаргаж болно; Гэсэн хэдий ч энэ хандлага нь "Бүх эсвэл юу ч биш" гэсэн тодорхой хандлагад илүү ойр хэвээр байна.
Дүгнэж хэлэхэд, CI серверүүд яагаад CD-тэй харьцах ёсгүй вэ:
- Шинэчлэх скриптүүд нь үргэлж тодорхойгүй байдаг; Тэдэнд алдаа гаргах нь амархан.
- CI серверүүд нь тунхаглалын кластерийн загварт нэгддэггүй.
- Хөдөлгөөнгүй байдлыг баталгаажуулахад хэцүү байдаг. Хэрэглэгчид системийн гүн утгыг ойлгох ёстой.
- Хэсэгчилсэн бүтэлгүйтлийг сэргээхэд илүү хэцүү байдаг.
Helm-ийн тухай тэмдэглэл: Хэрэв та Helm ашиглахыг хүсвэл GitOps оператортой хослуулахыг зөвлөж байна. . Энэ нь нэгдмэл байдлыг хангахад тусална. Helm өөрөө детерминист ч биш, атом ч биш.
GitOps нь Kubernetes-д зориулсан тасралтгүй хүргэлтийг хэрэгжүүлэх хамгийн сайн арга юм
Алис, Боб нарын баг GitOps-ийг хэрэгжүүлж, програм хангамжийн бүтээгдэхүүнтэй ажиллах, өндөр гүйцэтгэл, тогтвортой байдлыг хадгалахад илүү хялбар болсныг олж мэдэв. Тэдний шинэ арга барил ямар байдгийг харуулсан зураглалаар энэ нийтлэлийг төгсгөе. Бид ихэвчлэн програм, үйлчилгээний талаар ярьж байгаа боловч GitOps нь бүхэл бүтэн платформыг удирдахад ашиглаж болно гэдгийг санаарай.
Kubernetes-д зориулсан үйлдлийн загвар
Дараах диаграмыг харна уу. Энэ нь Git болон контейнер зургийн агуулахыг хоёр зохион байгуулалттай амьдралын мөчлөгийн хуваалцсан нөөц болгон танилцуулдаг:
- Git-д файл уншиж, бичиж, контейнер зургийн агуулахыг шинэчлэх боломжтой тасралтгүй нэгтгэх шугам.
- Байрлуулалт, удирдлага, ажиглалттай хослуулсан Runtime GitOps дамжуулах хоолой. Энэ нь Git-д файл уншиж, бичиж, контейнерийн зургийг татаж авах боломжтой.
Гол дүгнэлтүүд юу вэ?
- Санаа зовоосон асуудлуудыг салгах: Хоёр дамжуулах хоолой нь зөвхөн Git эсвэл зургийн агуулахыг шинэчлэх замаар холбогдох боломжтой гэдгийг анхаарна уу. Өөрөөр хэлбэл, CI болон ажиллах цагийн орчны хооронд галт хана байдаг. Бид үүнийг "хувиршгүй галт хана" гэж нэрлэдэг. (хувиршгүй галт хана), учир нь бүх репозиторын шинэчлэлтүүд шинэ хувилбаруудыг үүсгэдэг. Энэ сэдвийн талаар дэлгэрэнгүй мэдээлэл авахыг хүсвэл слайд 72-87-г үзнэ үү .
- Та ямар ч CI болон Git сервер ашиглаж болно: GitOps ямар ч бүрэлдэхүүн хэсэгтэй ажилладаг. Та өөрийн дуртай CI болон Git серверүүд, зургийн агуулахууд болон тестийн багцуудыг үргэлжлүүлэн ашиглах боломжтой. Зах зээл дээрх бусад бараг бүх тасралтгүй хүргэх хэрэгслүүд нь өөрийн CI/Git сервер эсвэл зургийн агуулахыг шаарддаг. Энэ нь үүлэн программыг хөгжүүлэхэд саад болж магадгүй юм. GitOps-ийн тусламжтайгаар та сайн мэддэг хэрэгслүүдийг ашиглаж болно.
- Үйл явдал нь нэгтгэх хэрэгсэл болгон: Git дэх өгөгдөл шинэчлэгдмэгц Weave Flux (эсвэл Weave Cloud оператор) ажиллах цагийг мэдэгдэнэ. Кубернетес өөрчлөлтийн багцыг хүлээн авах бүрд Git шинэчлэгддэг. Энэ нь доор үзүүлсэн шиг GitOps-ийн ажлын урсгалыг зохион байгуулах энгийн интеграцийн загварыг өгдөг.
дүгнэлт
GitOps нь орчин үеийн ямар ч CI/CD хэрэглүүрт шаардагдах хүчтэй шинэчлэлтийн баталгааг өгдөг.
- автоматжуулалт;
- нэгдэх;
- чадваргүй байдал;
- детерминизм.
Энэ нь үүлэн хөгжүүлэгчдэд зориулсан үйл ажиллагааны загварыг санал болгодог тул чухал юм.
- Системийг удирдах, хянах уламжлалт хэрэгслүүд нь runbook дотор ажилладаг үйл ажиллагааны багуудтай холбоотой байдаг (ердийн журам ба үйлдлүүдийн багц - ойролцоогоор орчуулга), тодорхой байршуулалттай холбоотой.
- Үүлний үндсэн менежментийн хувьд ажиглалтын хэрэгслүүд нь байршуулалтын үр дүнг хэмжих хамгийн сайн арга бөгөөд ингэснээр хөгжүүлэлтийн баг хурдан хариу үйлдэл үзүүлэх боломжтой болно.
Өөр өөр үүлэн дунд тархсан олон кластерууд болон өөрсдийн баг, байршуулах төлөвлөгөөтэй олон үйлчилгээ гэж төсөөлөөд үз дээ. GitOps нь энэ бүх элбэг дэлбэг байдлыг зохицуулах масштабтай өөрчлөгддөггүй загварыг санал болгодог.
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. , гуйя.
Эдгээр хоёр орчуулга Habré дээр гарахаас өмнө та GitOps-ийн талаар мэддэг байсан уу?
-
Тийм ээ, би бүгдийг мэдэж байсан
-
Зөвхөн өнгөцхөн
-
Ямар ч
35 хэрэглэгч санал өгсөн. 10 хэрэглэгч түдгэлзсэн.
Эх сурвалж: www.habr.com