GitOps: Татах, түлхэх аргуудын харьцуулалт

Анхаарна уу. орчуулга.: Кубернетес нийгэмлэгт GitOps хэмээх хандлага илт алдартай болж байгааг бид биечлэн харсан. зочлох KubeCon Europe 2019. Энэ нэр томъёо нь харьцангуй саяхан байсан зохион бүтээсэн Weaveworks-ийн дарга Алексис Ричардсоны бичсэн бөгөөд үйлдлийн асуудлыг шийдвэрлэхийн тулд хөгжүүлэгчдэд танил болсон хэрэгслүүдийг (үндсэндээ Git, иймээс нэр) ашиглахыг хэлнэ. Ялангуяа бид Kubernetes-ийн тохиргоог Git-д хадгалж, кластерт автоматаар өөрчлөлт оруулах замаар үйл ажиллагааны талаар ярьж байна. Matthias Jg энэ нийтлэлд энэ нэвтрүүлгийн хоёр аргын талаар ярьдаг.

Өнгөрсөн жил (үнэндээ албан ёсоор энэ нь 2017 оны XNUMX-р сард болсон - ойролцоогоор орчуулга.) Kubernetes-д програмуудыг байрлуулах шинэ хандлага бий. Үүнийг GitOps гэж нэрлэдэг бөгөөд энэ нь Git репозиторын аюулгүй орчинд байршуулах хувилбаруудыг хянадаг гэсэн үндсэн санаан дээр суурилдаг.

Энэ аргын гол давуу талууд нь дараах байдалтай байна.:

1. Байршуулах хувилбар болон өөрчлөлтийн түүх. Бүхэл бүтэн кластерын төлөвийг Git репозиторид хадгалдаг бөгөөд байршуулалт нь зөвхөн үүрэг даалгавараар шинэчлэгддэг. Нэмж дурдахад, бүх өөрчлөлтийг бүртгэлийн түүхийг ашиглан хянах боломжтой.
2. Танил Git командуудыг ашиглан буцаах. Энгийн git reset байршуулалтын өөрчлөлтийг дахин тохируулах боломжийг танд олгоно; өмнөх мужууд үргэлж бэлэн байдаг.
3. Бэлэн хандалтын хяналт. Ерөнхийдөө Git систем нь маш олон нууц мэдээллийг агуулдаг тул ихэнх компаниуд үүнийг хамгаалахад онцгой анхаарал хандуулдаг. Үүний дагуу энэхүү хамгаалалт нь байршуулах үйл ажиллагаанд мөн хамаарна.
4. Байршуулах бодлого. Ихэнх Git системүүд салбар тус бүрээр нь бодлогуудыг дэмждэг—жишээ нь зөвхөн татах хүсэлтүүд л мастерийг шинэчлэх боломжтой ба өөрчлөлтийг багийн өөр гишүүн хянаж, хүлээн зөвшөөрөх ёстой. Хандалтын хяналтын нэгэн адил байршуулалтын шинэчлэлтүүдэд ижил бодлого үйлчилнэ.

Таны харж байгаагаар GitOps арга нь олон давуу талтай. Сүүлийн нэг жилийн хугацаанд хоёр хандлага онцгой алдартай болсон. Нэг нь түлхэх, нөгөө нь татахад суурилсан. Тэдгээрийг харахаасаа өмнө Kubernetes-ийн ердийн байршуулалт ямар байдгийг харцгаая.

Байршуулах аргууд

Сүүлийн жилүүдэд Kubernetes-д байршуулах янз бүрийн арга, хэрэгслүүд бий болсон:

1. Төрөлхийн Kubernetes/Tostomize загварууд дээр үндэслэсэн. Энэ нь Kubernetes дээр програмуудыг байрлуулах хамгийн хялбар арга юм. Хөгжүүлэгч нь үндсэн YAML файлуудыг үүсгэж, тэдгээрийг ашигладаг. Ижил загваруудыг байнга дахин бичихээс ангижрахын тулд Kustomize-ийг боловсруулсан (энэ нь Kubernetes загваруудыг модуль болгон хувиргадаг). Анхаарна уу. орчуулга.: Kustomize-г kubectl-тэй нэгтгэсэн Kubernetes 1.14 хувилбар.
2. Жолооны диаграм. Загварт суурилсан аргаас илүү уян хатан тохируулгын сонголт бүхий програмуудыг байрлуулахад ашигладаг загвар, эхлэлийн контейнер, хажуугийн тэрэг гэх мэт багцуудыг үүсгэх боломжийг танд олгоно. Энэ арга нь загварчилсан YAML файлууд дээр суурилдаг. Helm нь тэдгээрийг янз бүрийн параметрүүдээр дүүргэж, дараа нь кластерын бүрэлдэхүүн хэсэг болох Tiller руу илгээдэг бөгөөд тэдгээрийг кластерт байрлуулж, шинэчлэлт болон буцаах боломжийг олгодог. Хамгийн чухал зүйл бол Helm нь үндсэндээ хүссэн утгуудыг загварт оруулаад дараа нь уламжлалт арга барилтай ижил аргаар ашигладаг. (Энэ бүхэн хэрхэн ажилладаг, хэрхэн ашиглах талаар манай нийтлэлээс уншина уу Хелмийн нийтлэл - ойролцоогоор. орчуул.). Өргөн хүрээний ажлыг хамарсан олон төрлийн бэлэн Helm графикууд байдаг.
3. Альтернатив хэрэгслүүд. Өөр олон хэрэгсэл байдаг. Тэдгээрийн нийтлэг зүйл бол зарим загвар файлуудыг Kubernetes-н унших боломжтой YAML файл болгон хувиргаж, дараа нь ашиглах явдал юм.

Бид ажилдаа Helm диаграммуудыг чухал хэрэглүүрүүдэд байнга ашигладаг (учир нь тэдгээрт олон зүйл бэлэн байгаа тул амьдралыг илүү хялбар болгодог) болон өөрсдийн хэрэглээний програмуудыг ашиглахад "цэвэр" Kubernetes YAML файлуудыг ашигладаг.

Татах, түлхэх

Саяхан блогтоо бичсэн нийтлэлийнхээ нэгэнд би уг хэрэгслийг танилцуулсан Weave Flux, энэ нь танд загваруудыг Git репозитор руу оруулах, контейнерийг оруулах, түлхэх болгоны дараа байршуулалтыг шинэчлэх боломжийг олгодог. Миний туршлагаас харахад энэ хэрэгсэл нь татах аргыг сурталчлах гол хэрэгслүүдийн нэг тул би үүнийг байнга дурдах болно. Хэрэв та үүнийг хэрхэн ашиглах талаар илүү ихийг мэдэхийг хүсвэл эндээс аваарай нийтлэлийн холбоос.

БИ! GitOps ашиглахын бүх ашиг тус хоёр аргын хувьд ижил хэвээр байна.

Татах суурилсан арга

Татах арга нь бүх өөрчлөлтийг кластер дотроос хийх явдал дээр суурилдаг. Кластер дотор Git болон Docker бүртгэлийн репозиторуудыг тогтмол шалгадаг оператор байдаг. Хэрэв тэдгээрт ямар нэгэн өөрчлөлт гарвал кластерийн төлөвийг дотооддоо шинэчилдэг. Ямар ч гадны үйлчлүүлэгч кластерийн администраторын эрхийг авах эрхгүй тул энэ процессыг ерөнхийдөө маш аюулгүй гэж үздэг.

Нөхцөл:

1. Ямар ч гадны үйлчлүүлэгч кластерт өөрчлөлт оруулах эрхгүй бөгөөд бүх шинэчлэлтүүд дотроосоо гарч ирдэг.
2. Зарим хэрэгслүүд нь танд Helm диаграмын шинэчлэлтүүдийг синхрончлох, тэдгээрийг кластерт холбох боломжийг олгодог.
3. Docker Registry-г шинэ хувилбаруудыг хайж олох боломжтой. Хэрэв шинэ зураг байгаа бол Git репозитор болон байршуулалтыг шинэ хувилбар болгон шинэчилнэ.
4. Татах хэрэгслүүдийг өөр өөр Git репозиторууд болон зөвшөөрөлтэй өөр өөр нэрийн зайд тарааж болно. Үүний ачаар олон түрээслэгчийн загварыг ашиглаж болно. Жишээлбэл, А баг А нэрийн орон зайг, В баг B нэрийн орон зайг, дэд бүтцийн баг глобал зайг ашиглаж болно.
5. Дүрмээр бол багаж хэрэгсэл нь маш хөнгөн жинтэй байдаг.
6. Оператор зэрэг хэрэгслүүдтэй хослуулсан Битнамийн битүүмжилсэн нууцууд, нууцыг Git репозиторид шифрлэгдсэн байдлаар хадгалж, кластер дотроос татаж авах боломжтой.
7. Кластер дотор байршуулалт явагддаг тул CD дамжуулах хоолойд ямар ч холболт байхгүй.

Минусы:

1. Helm диаграмаас байршуулах нууцыг удирдах нь ердийнхөөс илүү хэцүү байдаг, учир нь тэдгээрийг эхлээд битүүмжилсэн нууц хэлбэрээр үүсгэж, дараа нь дотоод оператор шифрийг нь тайлж, дараа нь татах хэрэгсэлд ашиглах боломжтой болно. Дараа нь та аль хэдийн байрлуулсан нууцын утгуудаар Helm дээр хувилбарыг ажиллуулж болно. Хамгийн хялбар арга бол байршуулахад ашигласан бүх Helm утгуудаар нууц үүсгэж, шифрийг нь тайлж, Git-д даатгах явдал юм.
2. Та татах арга барилаар та татах хэрэгсэлд уягддаг. Энэ нь кластерт байршуулах үйл явцыг өөрчлөх боломжийг хязгаарладаг. Жишээлбэл, Kustomize нь Git-д эцсийн загваруудыг оруулахаас өмнө ажиллах ёстой тул төвөгтэй байдаг. Би таныг бие даасан хэрэгслийг ашиглах боломжгүй гэж хэлээгүй ч тэдгээрийг байршуулах процесст нэгтгэхэд илүү хэцүү байдаг.

Түлхэлтэд суурилсан арга

Түлхэх хандлагад гадны систем (ихэвчлэн CD дамжуулах хоолой) нь Git репозиторыг хүлээн авсны дараа эсвэл өмнөх CI дамжуулах хоолой амжилттай болсны дараа кластерт байршуулалтыг эхлүүлдэг. Энэ аргын хувьд систем нь кластерт хандах боломжтой.

Плюсы:

1. Аюулгүй байдлыг Git репозитор болон бүтээх шугамаар тодорхойлдог.
2. Helm диаграмыг байрлуулах нь илүү хялбар бөгөөд Helm залгаасуудыг дэмждэг.
3. Нууцыг удирдахад илүү хялбар байдаг, учир нь нууцыг дамжуулах хоолойд ашиглаж болохоос гадна Git-д шифрлэгдсэн (хэрэглэгчийн сонголтоос хамаарч) хадгалах боломжтой.
4. Ямар ч төрлийг ашиглаж болох тул тодорхой хэрэгсэлд холболт байхгүй.
5. Контейнерын хувилбарын шинэчлэлтийг угсралтын шугамаар эхлүүлж болно.

Минусы:

1. Кластер хандалтын өгөгдөл нь бүтээх систем дотор байна.
2. Татах процессоор байршуулах савыг шинэчлэх нь илүү хялбар хэвээр байна.
3. CD системээс ихээхэн хамааралтай, учир нь бидэнд хэрэгтэй дамжуулах хоолойнуудыг Gitlab Runners-д зориулж бичсэн байж магадгүй бөгөөд дараа нь баг Azure DevOps эсвэл Jenkins руу шилжихээр шийдсэн ... мөн олон тооны угсралтын дамжуулах хоолойнуудыг шилжүүлэх шаардлагатай болно.

Үр дүн: түлхэх үү, татах уу?

Ердийнх шиг, арга бүр өөрийн давуу болон сул талуудтай байдаг. Зарим ажлыг нэгээр нь хийхэд хялбар, нөгөөг нь хийхэд хэцүү байдаг. Эхэндээ би байршуулалтыг гараар хийж байсан боловч Weave Flux-ийн талаар цөөн хэдэн нийтлэл олж уншсаны дараа би бүх төслүүдэд GitOps процессыг хэрэгжүүлэхээр шийдсэн. Үндсэн загваруудын хувьд энэ нь хялбар байсан ч дараа нь би Helm диаграммтай ажиллахад бэрхшээлтэй тулгарч эхэлсэн. Тухайн үед Weave Flux нь зөвхөн Helm Chart Operator-ийн энгийн хувилбарыг санал болгож байсан боловч одоо ч гэсэн нууцыг гараар үүсгэж, тэдгээрийг ашиглах хэрэгцээ шаардлагаас болж зарим ажлууд илүү хэцүү байдаг. Кластерын итгэмжлэлүүд нь кластераас гадуур хандах боломжгүй тул татах арга нь илүү найдвартай гэж та маргаж болно, учир нь энэ нь илүү аюулгүй тул нэмэлт хүчин чармайлт гаргахад үнэ цэнэтэй юм.

Хэсэг хугацаанд бодсоны эцэст энэ нь тийм биш юм байна гэсэн санаанд оромгүй дүгнэлтэд хүрсэн. Хэрэв бид хамгийн их хамгаалалт шаарддаг бүрэлдэхүүн хэсгүүдийн талаар ярих юм бол энэ жагсаалтад нууц хадгалалт, CI/CD систем, Git репозиторууд орно. Тэдгээрийн доторх мэдээлэл нь маш эмзэг бөгөөд хамгийн их хамгаалалт шаарддаг. Нэмж дурдахад, хэрэв хэн нэгэн таны Git репозитор руу орж, тэнд код оруулах боломжтой бол тэд хүссэн бүхнээ (татах эсвэл түлхэх) байрлуулж, кластерын системд нэвтэрч болно. Тиймээс хамгаалах шаардлагатай хамгийн чухал бүрэлдэхүүн хэсгүүд нь кластерийн итгэмжлэл биш Git репозитор болон CI/CD системүүд юм. Хэрэв танд эдгээр төрлийн системд зориулсан сайн тохируулсан бодлого, аюулгүй байдлын хяналт байгаа бөгөөд кластерын итгэмжлэлүүд нь зөвхөн дамжуулах хоолойд нууц байдлаар задлагдсан бол татах хандлагын нэмэлт хамгаалалт нь анх бодож байсан шиг үнэ цэнэтэй биш байж магадгүй юм.

Тэгэхээр татах арга нь илүү их хөдөлмөр зарцуулж, аюулгүй байдлын ашиг тусаа өгөхгүй бол зөвхөн түлхэх аргыг ашиглах нь логик биш гэж үү? Гэхдээ хэн нэгэн түлхэх арга барилд та CD системтэй хэтэрхий холбоотой байдаг тул ирээдүйд шилжих хөдөлгөөн хийхэд хялбар байхын тулд үүнийг хийхгүй байх нь дээр гэж маргаж магадгүй юм.

Миний бодлоор (үргэлжийн адил) та тодорхой тохиолдолд эсвэл хослуулахад хамгийн тохиромжтой зүйлийг ашиглах хэрэгтэй. Би хувьдаа энэ хоёр аргыг ашигладаг: Weave Flux нь ихэвчлэн өөрсдийн үйлчилгээнүүдийг багтаасан татахад суурилсан байршуулалт, мөн Helm болон залгаасуудыг ашиглан түлхэх арга бөгөөд энэ нь Helm диаграмыг кластерт ашиглахад хялбар болгож, нууцыг саадгүй үүсгэх боломжийг олгодог. Бүх тохиолдлуудад тохирох ганц шийдэл хэзээ ч байхгүй гэж би бодож байна, учир нь үргэлж маш олон нюансууд байдаг бөгөөд тэдгээр нь тодорхой хэрэглээнээс хамаардаг. Үүнийг хэлэхэд би GitOps-ийг маш их санал болгож байна - энэ нь амьдралыг илүү хялбар болгож, аюулгүй байдлыг сайжруулдаг.

Энэ сэдвийн талаархи миний туршлага нь таны байршуулалтын төрөлд аль аргыг илүү тохиромжтой болохыг тодорхойлоход тусална гэж найдаж байна, мөн таны бодлыг сонсоход таатай байх болно.

Жич Орчуулагчийн бичсэн тэмдэглэл

Татах загварын сул тал нь Git-д үзүүлсэн манифест оруулахад хэцүү байдаг боловч татах загвар дахь CD дамжуулах хоолой нь өгөгдлөөс тусдаа амьдардаг бөгөөд үндсэндээ категорийн дамжуулах хоолой болдог нь сул тал байхгүй. Тасралтгүй өргөдөл гаргах. Тиймээс, бүх байршуулалтаас тэдний статусыг цуглуулж, ямар нэгэн байдлаар CD системтэй холбоотой бүртгэл/статус руу нэвтрэх боломжийг олгохын тулд илүү их хүчин чармайлт гаргах шаардлагатай болно.

Энэ утгаараа түлхэх загвар нь дамжуулах хоолойн ашиглалтын хугацааг ашиглалтын хугацаатай тэнцүү болгож болох тул хамгийн багадаа нэвтрүүлэх баталгааг хангах боломжийг бидэнд олгодог.

Бид хоёр загварыг туршиж үзээд нийтлэлийн зохиогчтой ижил дүгнэлтэд хүрсэн.

1. Татах загвар нь олон тооны кластерууд дээр системийн бүрэлдэхүүн хэсгүүдийн шинэчлэлтийг зохион байгуулахад тохиромжтой (харна уу. addon-operator-ийн тухай нийтлэл).
2. GitLab CI дээр суурилсан түлхэх загвар нь Helm диаграм ашиглан програмуудыг гаргахад тохиромжтой. Үүний зэрэгцээ уг хэрэгслийг ашиглан дамжуулах хоолойд байршуулах ажлыг хянадаг верф. Дашрамд дурдахад, бидний энэхүү төслийн хүрээнд бид KubeCon Europe'19 үзэсгэлэнгийн индэр дээр DevOps инженерүүдийн тулгамдсан асуудлуудыг хэлэлцэх үед байнгын "GitOps"-ийг сонссон.

Орчуулагчаас авсан PPS

Мөн манай блог дээрээс уншина уу:

• «Kubernetes зөвлөмж ба заль мэх: кластерт ажиллаж байгаа нөөцийг Helm 2 удирдлага руу шилжүүлэх";
• «Kubernetes нөөцийг хянах зориулалттай kubedog номын санг танилцуулж байна";
• «Kubernetes-ийг өргөжүүлж, нөхөж байна (хяналт болон видео тайлан)";
• «GitLab CI дээр захиалгат ажлын урсгалыг бий болгох зөвлөмжүүд".

Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. Нэвтрэх, гуйя.

Та GitOps ашиглаж байна уу?

• Тийм ээ, татах арга

• Тийм ээ, түлхэх

• Тийм, татах + түлхэх

• Тийм ээ, өөр зүйл

• Ямар ч

30 хэрэглэгч санал өгсөн. 10 хэрэглэгч түдгэлзсэн.

Эх сурвалж: www.habr.com