27-р сарын 2019-нд наадмын хүрээнд зохион байгуулагдсан DevOpsConf XNUMX бага хурлын гол танхимд , "Тасралтгүй хүргэлт" хэсгийн нэг хэсэг болгон "werf - Kubernetes дахь CI/CD-д зориулсан бидний хэрэгсэл" тайланг өгсөн. Тэдгээрийн тухай ярьдаг Kubernetes-д байршуулах үед хүн бүрт тулгардаг асуудал, сорилтууд, түүнчлэн нэн даруй анзаарагдахгүй байж болох нюансын талаар. Боломжит шийдлүүдэд дүн шинжилгээ хийхдээ бид үүнийг Нээлттэй эхийн хэрэглүүрт хэрхэн хэрэгжүүлж байгааг харуулж байна .
Танилцуулснаас хойш манай хэрэгсэл (өмнө нь dapp гэгддэг) түүхэн чухал үе шатанд хүрсэн. GitHub дээр 1000 одтой - өсөн нэмэгдэж буй хэрэглэгчдийн нийгэмлэг нь олон DevOps инженерүүдийн амьдралыг хөнгөвчлөх болно гэж бид найдаж байна.
Ингээд танилцуулъя (~47 минут, нийтлэлээс хамаагүй илүү мэдээлэлтэй) ба түүнээс үндсэн ишлэлийг текст хэлбэрээр. Яв!
Кубернетес рүү код хүргэж байна
Энэ яриа нь werf-ийн тухай биш харин Кубернетес дэх CI/CD-ийн тухай байх бөгөөд энэ нь манай программ хангамжийг Docker контейнерт савласан гэсэн үг юм. (Би энэ талаар ярьсан ), мөн K8-уудыг үйлдвэрлэлд ажиллуулахад ашиглах болно (энэ талаар дэлгэрэнгүй ).
Кубернетес хотод хүргэлт ямар харагддаг вэ?
- Код болон түүнийг бүтээх заавар бүхий Git репозитор байдаг. Програмыг Docker дүрсэнд суулгаж, Docker Registry-д нийтэлсэн.
- Ижил репозитор нь програмыг хэрхэн байрлуулах, ажиллуулах зааварчилгааг агуулдаг. Байршуулах үе шатанд эдгээр зааврыг Kubernetes руу илгээдэг бөгөөд энэ нь бүртгэлээс хүссэн дүрсийг хүлээн авч ажиллуулдаг.
- Дээрээс нь ихэвчлэн шалгалтууд байдаг. Эдгээрийн заримыг зураг нийтлэх үед хийж болно. Та мөн (ижил зааврын дагуу) програмын хуулбарыг (тусдаа K8s нэрийн талбар эсвэл тусдаа кластерт) байрлуулж, тэнд тест ажиллуулж болно.
- Эцэст нь, танд Git-ээс үйл явдлуудыг хүлээн авдаг (эсвэл товчлуур дээр дарах) CI систем хэрэгтэй бөгөөд бүх зориулалтын үе шатуудыг дууддаг: бүтээх, нийтлэх, байрлуулах, турших.
Энд хэд хэдэн чухал тэмдэглэл байна:
- Яагаад гэвэл манайд хувиршгүй дэд бүтэц бий (өөрчлөгддөггүй дэд бүтэц), бүх үе шатанд ашиглагдаж буй програмын дүрс (үе шат, үйлдвэрлэл гэх мэт), нэг байх ёстой. Би энэ талаар илүү дэлгэрэнгүй, жишээн дээр ярьсан. .
- Учир нь бид дэд бүтцээ кодын арга гэж үздэг (IaC), програмын код, угсрах, эхлүүлэх заавар байх ёстой яг нэг репозитор дээр. Энэ талаар дэлгэрэнгүй мэдээллийг үзнэ үү .
- Хүргэлтийн сүлжээ (хүргэх) Бид үүнийг ихэвчлэн ингэж хардаг: програмыг угсарч, туршиж үзсэн, гаргасан (гаргах үе шат) тэгээд л боллоо - хүргэлт хийгдлээ. Гэвч бодит байдал дээр хэрэглэгч таны гаргасан зүйлийг олж авдаг. үгүй тэгээд үйлдвэрлэлд хүргэчихээд тэр чинь тэнд очоод байж байхад энэ продакшн ажилласан. Тиймээс хүргэх гинжин хэлхээ дуусна гэдэгт би итгэдэг зөвхөн үйл ажиллагааны үе шатанд (гүйх), эсвэл илүү нарийвчлалтай, кодыг үйлдвэрлэлээс хассан үед ч гэсэн (шинэ кодоор солих).
Кубернетес дэх дээрх хүргэлтийн схем рүү буцаж орцгооё: үүнийг зөвхөн бид төдийгүй энэ асуудлыг шийдсэн бүх хүмүүс зохион бүтээсэн. Үнэн хэрэгтээ энэ загварыг одоо GitOps гэж нэрлэдэг (Та нэр томьёо болон түүний цаад санааны талаар илүү ихийг уншиж болно ). Схемийн үе шатуудыг авч үзье.
Барилгын үе шат
2019 онд Docker файлуудыг хэрхэн бичих, ажиллуулах талаар хүн бүр мэддэг болсон үед та Docker дүрс бүтээх талаар ярих боломжтой юм шиг санагдаж байна. docker build?.. Энд миний анхаарахыг хүсч буй нюансууд байна:
- Зургийн жин чухал тул ашигла зураг дээр зөвхөн үйл ажиллагаанд шаардлагатай програмыг үлдээх.
- Давхаргын тоо -ийн гинжийг нэгтгэх замаар багасгах ёстой
RUN-утгын дагуу тушаалууд. - Гэсэн хэдий ч энэ нь асуудал нэмж байна дибаг хийх, учир нь угсралт гацах үед та асуудал үүсгэсэн хэлхээнээс зөв командыг олох хэрэгтэй.
- Угсралтын хурд Бид өөрчлөлтүүдийг хурдан гаргаж үр дүнг нь харахыг хүсдэг учраас чухал. Жишээлбэл, та програм бүтээх бүртээ хэлний сангуудын хамаарлыг дахин бүтээхийг хүсэхгүй байна.
- Ихэнхдээ нэг Git репозитороос хэрэгтэй байдаг олон зураг, үүнийг Dockerfiles багц (эсвэл нэг файлд нэрлэгдсэн үе шатууд) болон дараалсан угсралттай Bash скриптээр шийдэж болно.
Энэ бол хүн бүрт тулгардаг мөсөн уулын зөвхөн орой нь байсан юм. Гэхдээ бусад асуудлууд байдаг, ялангуяа:
- Ихэнхдээ угсралтын шатанд бидэнд ямар нэгэн зүйл хэрэгтэй байдаг холбох (жишээ нь, apt гэх мэт тушаалын үр дүнг гуравдагч этгээдийн лавлахад кэш хийх).
- Бид хүсдэг Алгасах бүрхүүлээр бичихийн оронд.
- Бид хүсдэг Докергүйгээр бүтээх (Бидэнд контейнер ажиллуулж болох Kubernetes кластер байгаа бол яагаад бидэнд бүх зүйлийг тохируулах шаардлагатай нэмэлт виртуал машин хэрэгтэй байна вэ?).
- Зэрэгцээ угсралт, үүнийг янз бүрийн аргаар ойлгож болно: Dockerfile-ийн өөр өөр тушаалууд (хэрэв олон үе шаттай бол), нэг репозиторын хэд хэдэн үүрэг, хэд хэдэн Dockerfiles.
- Тархсан угсралт: Бид "түр зуурын" зүйлүүдийг pods-д цуглуулахыг хүсч байна, учир нь Тэдний кэш алга болох бөгөөд энэ нь хаа нэгтээ тусад нь хадгалах шаардлагатай гэсэн үг юм.
- Эцэст нь би хүслийн оргилыг нэрлэсэн автомат ид шид: Хадгалах газар руу орж команд бичээд, яаж, юуг зөв хийх тухай ойлголттой бэлэн зураг авах нь хамгийн тохиромжтой. Гэсэн хэдий ч бүх нарийн ширийн зүйлийг ийм байдлаар урьдчилан харж чадна гэдэгт би хувьдаа итгэлгүй байна.
Мөн энд төслүүд байна:
- — эдгээр бүх асуудлыг шийдэхийг оролдож буй Docker Inc-ийн барилгачин (Докерын одоогийн хувилбаруудад аль хэдийн нэгдсэн);
- — Google-ийн бүтээгч нь танд Docker-гүйгээр бүтээх боломжийг олгодог;
- — CNCF-ийн автомат ид шид хийх оролдлого, тэр дундаа давхаргын суурьтай сонирхолтой шийдэл;
- болон бусад олон хэрэгслүүд, тухайлбал , ...
... мөн тэд GitHub дээр хичнээн одтой байгааг хараарай. Энэ нь нэг талаас, docker build байдаг бөгөөд ямар нэг зүйлийг хийж чадна, гэхдээ бодит байдал дээр асуудал бүрэн шийдэгдээгүй байна - үүний нотолгоо бол альтернатив коллекторуудын зэрэгцээ хөгжиж байгаа бөгөөд тус бүр нь асуудлын зарим хэсгийг шийддэг.
Werf-д угсрах
Тиймээс бид тэгэх ёстой (өмнө нь dapp шиг) — Бидний олон жилийн турш хийж байгаа Flant компанийн нээлттэй эхийн хэрэгсэл. Энэ бүхэн 5 жилийн өмнө Dockerfiles-ийн угсралтыг оновчтой болгосон Bash скриптүүдээр эхэлсэн бөгөөд сүүлийн 3 жилийн хугацаанд өөрийн Git репозитортой нэг төслийн хүрээнд бүрэн хэмжээний хөгжүүлэлт хийгдсэн. (эхлээд Ruby дээр, дараа нь Go, мөн нэгэн зэрэг нэрийг нь өөрчилсөн). Werf-д угсралтын ямар асуудлууд шийдэгддэг вэ?
Цэнхэрээр будсан асуудлууд аль хэдийн хэрэгжсэн, зэрэгцээ угсралтын ажлыг нэг хост дотор хийсэн бөгөөд шараар тодруулсан асуудлуудыг зуны эцэс гэхэд дуусгахаар төлөвлөж байна.
Бүртгэлд хэвлэгдсэн үе шат (нийтлэх)
Бид залгасан docker push... - Бүртгэлд зураг оруулахад юу хэцүү байж болох вэ? Дараа нь асуулт гарч ирнэ: "Би зураг дээр ямар шошго тавих ёстой вэ?" Энэ нь бидэнд байгаа шалтгааны улмаас үүсдэг Gitflow (эсвэл Git-ийн бусад стратеги) болон Kubernetes ба салбар нь Kubernetes-д болж буй үйл явдал Гит-д тохиолдсон зүйлийг дагаж мөрдөхийг хичээж байна. Эцсийн эцэст Гит бол бидний үнэний цорын ганц эх сурвалж юм.
Энэ юу нь тийм хэцүү вэ? Дахин үржих чадварыг баталгаажуулах: шинж чанараараа өөрчлөгддөггүй Гит дэх амлалтаас (өөрчлөгддөггүй), Докерын дүрс рүү, ижил хэвээр байх ёстой.
Энэ нь бидний хувьд бас чухал юм гарал үүслийг тодорхойлох, учир нь бид Kubernetes-д ажиллаж байгаа програмыг аль commit-ээс бүтээсэн болохыг ойлгохыг хүсч байна (дараа нь бид ялгаа болон үүнтэй төстэй зүйлийг хийж болно).
Шошголох стратеги
Эхнийх нь энгийн git өдөр. гэж тэмдэглэгдсэн зураг бүхий бүртгэл бидэнд бий 1.0. Кубернетес нь энэ зургийг байршуулсан тайз болон продакшнтай. Гит дээр бид амлалт хийж, хэзээ нэгэн цагт тэмдэглэгээ хийдэг 2.0. Бид үүнийг агуулахын зааврын дагуу цуглуулж, шошготой бүртгэлд байрлуулна 2.0. Бид үүнийг тайзан дээр гаргаж, хэрэв бүх зүйл сайн байвал үйлдвэрлэлд оруулна.
Энэ аргын асуудал бол бид эхлээд шошгыг тавиад, дараа нь туршиж үзээд гаргасан явдал юм. Яагаад? Нэгдүгээрт, энэ нь зүгээр л логикгүй юм: бид хараахан туршиж үзээгүй програм хангамжийн хувилбарыг гаргаж байна (бид өөрөөр хийж чадахгүй, учир нь шалгахын тулд шошго тавих хэрэгтэй). Хоёрдугаарт, энэ зам нь Gitflow-тай нийцэхгүй байна.
Хоёр дахь сонголт бол git commit + шошго. Мастер салбар нь шошготой 1.0; Үүний тулд бүртгэлд - үйлдвэрлэлд байрлуулсан зураг. Нэмж дурдахад, Кубернетес кластер нь урьдчилан харах, дүрслэх контуртай. Дараа нь бид Gitflow-ийг дагаж мөрддөг: хөгжүүлэлтийн үндсэн салбарт (develop) бид шинэ боломжуудыг бий болгосноор тодорхойлогчтой холбоотой үүрэг гүйцэтгэдэг #c1. Бид үүнийг цуглуулж, энэ танигчийг ашиглан бүртгэлд нийтэлдэг (#c1). Ижил танигчаар бид урьдчилан үзэх боломжтой. Бид амлалтуудтай ижил зүйлийг хийдэг #c2 и #c3.
Хангалттай шинж чанарууд байгааг мэдээд бид бүх зүйлийг тогтворжуулж эхэлдэг. Git дээр салбар үүсгэ release_1.1 (суурь дээр #c3 нь develop). Энэ хувилбарыг цуглуулах шаардлагагүй, учир нь... Энэ нь өмнөх алхам дээр хийгдсэн. Тиймээс бид үүнийг зүгээр л тайз дэлгэцэнд гаргах боломжтой. Бид алдааг засдаг #c4 мөн үүнтэй адилаар тайз дэлгэцэнд гаргах. Үүний зэрэгцээ бүтээн байгуулалт өрнөж байна develop, өөрчлөлтийг үе үе хаанаас авдаг release_1.1. Хэзээ нэгэн цагт бид амлалтаа эмхэтгэж, тайзнаа байршуулахдаа сэтгэл хангалуун байдаг (#c25).
Дараа нь бид суллах салбарыг (хурдан урагшлуулах) нэгтгэдэг.release_1.1) мастер дээр. Бид энэ үүрэгт шинэ хувилбар бүхий шошго тавьсан (1.1). Гэхдээ энэ зургийг бүртгэлд аль хэдийн цуглуулсан тул дахин цуглуулахгүйн тулд бид одоо байгаа зурган дээр хоёр дахь шошго нэмнэ (одоо бүртгэлд шошготой байна) #c25 и 1.1). Үүний дараа бид үүнийг үйлдвэрлэлд нэвтрүүлдэг.
Тайзан дээр зөвхөн нэг зураг байршуулдаг сул тал бий (#c25), мөн үйлдвэрлэлд энэ нь арай өөр (1.1), гэхдээ "бие махбодийн хувьд" эдгээр нь бүртгэлээс ижил зураг гэдгийг бид мэднэ.
Жинхэнэ сул тал бол нэгтгэх үйлдлийг дэмждэггүй, та хурдан урагшлах хэрэгтэй.
Бид цаашаа явж, заль мэх хийж чадна... Энгийн Dockerfile-ийн жишээг харцгаая:
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/publicҮүнээс дараах зарчмын дагуу файл бүтээцгээе.
- Ашигласан зургийн танигчаас SHA256 (
ruby:2.3иnginx:alpine), тэдгээрийн агуулгын хяналтын нийлбэр; - бүх багууд (
RUN,CMDгэх мэт.); - Нэмэгдсэн файлуудаас SHA256.
... мөн ийм файлаас шалгах нийлбэрийг (дахин SHA256) авна. Энэ гарын үсэг Docker зургийн агуулгыг тодорхойлсон бүх зүйл.
Диаграм руу буцаж орцгооё амлалтын оронд бид ийм гарын үсгийг ашиглах болно, өөрөөр хэлбэл Зургийг гарын үсгээр тэмдэглэнэ үү.
Одоо, жишээ нь, хувилбараас мастер руу өөрчлөлтүүдийг нэгтгэх шаардлагатай үед бид жинхэнэ нэгтгэх үүрэг гүйцэтгэж болно: энэ нь өөр танигчтай, гэхдээ ижил гарын үсэгтэй байх болно. Ижил танигчаар бид зургийг үйлдвэрлэлд гаргах болно.
Сул тал нь одоо ямар төрлийн үүрэг даалгаврыг үйлдвэрлэлд түлхсэнийг тодорхойлох боломжгүй болно - хяналтын дүн нь зөвхөн нэг чиглэлд ажилладаг. Энэ асуудлыг мета өгөгдөл бүхий нэмэлт давхаргаар шийддэг - би дараа нь танд хэлэх болно.
werf дээр тэмдэглэж байна
werf-д бид бүр цааш явж, нэг машин дээр хадгалагдаагүй кэштэй тараагдсан бүтэц хийхээр бэлтгэж байна ... Тиймээс бид хоёр төрлийн Docker дүрсийг бүтээж байна, бид тэдгээрийг гэж нэрлэдэг. шат и зураг.
werf Git репозитор нь угсралтын янз бүрийн үе шатуудыг дүрсэлсэн барилгын тусгай заавруудыг хадгалдаг (Суулгахаас өмнө, Суулгах, Тохиргооны өмнө, тохируулах). Бид эхний алхамуудын хяналтын нийлбэр гэж тодорхойлсон гарын үсэг бүхий эхний шатны зургийг цуглуулдаг. Дараа нь бид эх кодыг нэмж, шинэ тайзны зургийн хувьд бид түүний хяналтын дүнг тооцдог ... Эдгээр үйлдлүүд нь бүх үе шатанд давтагддаг бөгөөд үүний үр дүнд бид тайзны зургийн багцыг авдаг. Дараа нь бид түүний гарал үүслийн талаархи мета өгөгдлийг агуулсан эцсийн зургийг хийдэг. Мөн бид энэ зургийг янз бүрийн аргаар тэмдэглэнэ (дэлгэрэнгүйг дараа нь).
Үүний дараа зөвхөн програмын кодыг өөрчилсөн шинэ үүрэг гарлаа гэж бодъё. Юу тохиолдох вэ? Кодын өөрчлөлтийн хувьд нөхөөсийг үүсгэж, шинэ тайзны зураг бэлтгэнэ. Түүний гарын үсэг нь хуучин тайзны зураг болон шинэ нөхөөсийн хяналтын нийлбэрээр тодорхойлогдоно. Энэ зургаас шинэ эцсийн зураг үүснэ. Үүнтэй төстэй зан үйл нь бусад үе шатуудад өөрчлөлт ороход тохиолддог.
Тиймээс тайзны зургууд нь түгээх хэлбэрээр хадгалагдах кэш бөгөөд үүнээс аль хэдийн үүсгэсэн зургуудыг Docker Registry-д байршуулдаг.
Бүртгэлийг цэвэрлэж байна
Устгасан шошгоны дараа өлгөөтэй үлдсэн давхаргыг устгах тухай бид яриагүй байна - энэ бол Docker Registry-ийн стандарт функц юм. Бид маш олон Docker хаягууд хуримтлагдаж, зарим нь бидэнд хэрэггүй болсон ч тэд зай эзэлдэг (мөн/эсвэл бид үүнийг төлдөг) гэдгийг ойлгож байгаа нөхцөл байдлын тухай ярьж байна.
Цэвэрлэгээний стратеги юу вэ?
- Та зүгээр л юу ч хийж чадахгүй битгий цэвэрлэ. Заримдаа асар том орооцолдсон хаягуудыг задлахаас илүү зай авахын тулд бага зэрэг мөнгө төлөх нь үнэхээр хялбар байдаг. Гэхдээ энэ нь зөвхөн тодорхой цэг хүртэл ажилладаг.
- Бүрэн дахин тохируулах. Хэрэв та бүх зургийг устгаж, зөвхөн CI систем дэх одоо байгаа зургуудыг дахин бүтээвэл асуудал гарч болзошгүй. Хэрэв савыг үйлдвэрлэлд дахин эхлүүлбэл түүнд зориулж хэн ч туршиж үзээгүй шинэ зураг ачаалагдах болно. Энэ нь өөрчлөгдөшгүй дэд бүтцийн санааг устгадаг.
- Цэнхэр ногоон. Нэг бүртгэл дүүрч эхлэв - бид зургийг нөгөө рүү байршуулдаг. Өмнөх аргын адил асуудал: хальж эхэлсэн бүртгэлийг ямар үед цэвэрлэж чадах вэ?
- Цаг хугацааны дараа. 1 сараас дээш настай бүх зургийг устгах уу? Гэхдээ нэг сар шинэчлэгдээгүй үйлчилгээ байх нь гарцаагүй...
- Гараар аль хэдийн устгаж болох зүйлийг тодорхойлох.
Хоёр үнэхээр ашигтай сонголт байдаг: цэвэрлэж болохгүй эсвэл хөх-ногоон хослол + гараар. Сүүлчийн тохиолдолд бид дараахь зүйлийг ярьж байна: бүртгэлийг цэвэрлэх цаг болсныг ойлгоход та шинээр үүсгэж, жишээлбэл, нэг сарын хугацаанд бүх шинэ зургийг нэмнэ үү. Сарын дараа Kubernetes-ийн аль pods хуучин бүртгэлийг ашигласаар байгааг харж, шинэ бүртгэл рүү шилжүүлээрэй.
Бид юунд хүрэв верф? Бид цуглуулдаг:
- Git толгой: бүх хаягууд, бүх салбарууд - зураг дээр Git дээр тэмдэглэсэн бүх зүйл хэрэгтэй гэж үзвэл (хэрэв үгүй бол Git дотроос үүнийг устгах хэрэгтэй);
- одоогоор Кубернетес рүү шахагдаж байгаа бүх хонхорцог;
- хуучин ReplicaSets (саяхан гарсан) бөгөөд бид мөн Helm хувилбаруудыг сканнердаж, тэндээс хамгийн сүүлийн үеийн зургуудыг сонгохоор төлөвлөж байна.
... мөн энэ багцаас цагаан жагсаалт гарга - бидний устгахгүй зургуудын жагсаалт. Бид бусад бүх зүйлийг цэвэрлэсний дараа өнчин тайзны зургуудыг олж устгадаг.
Үе шатыг байрлуулах
Найдвартай тунхаглал
Байршуулахдаа миний анхаарал хандуулахыг хүсч буй хамгийн эхний зүйл бол тунхаглалаар зарласан шинэчилсэн нөөцийн тохиргоог нэвтрүүлэх явдал юм. Kubernetes нөөцийг тодорхойлсон анхны YAML баримт бичиг нь кластерт ажиллаж байгаа үр дүнгээс үргэлж тэс өөр байдаг. Учир нь Кубернетес тохиргоонд нэмдэг:
- танигч;
- үйлчилгээний мэдээлэл;
- олон үндсэн утгууд;
- одоогийн статустай хэсэг;
- элсэлтийн webhook-ийн нэг хэсэг болгон хийсэн өөрчлөлтүүд;
- янз бүрийн хянагч (болон төлөвлөгч) -ийн ажлын үр дүн.
Тиймээс шинэ нөөцийн тохиргоо гарч ирэхэд (шинэ), бид үүнтэй одоогийн "амьд" тохиргоог авч, дарж бичих боломжгүй (Амьд байна). Үүнийг хийхийн тулд бид харьцуулах хэрэгтэй болно шинэ хамгийн сүүлд ашигласан тохиргоотой (хамгийн сүүлд ашигласан) ба өнхрүүлээрэй Амьд байна хүлээн авсан нөхөөс.
Энэ аргыг нэрлэдэг 2 талын нэгдэл. Үүнийг жишээ нь Helm-д ашигладаг.
Бас байдаг 3 талын нэгдэл, энэ нь дараах байдлаар ялгаатай:
- харьцуулах хамгийн сүүлд ашигласан и шинэ, бид устгасан зүйлийг хардаг;
- харьцуулах шинэ и Амьд байна, бид юу нэмсэн эсвэл өөрчлөгдсөнийг хардаг;
- нийлбэр нөхөөсийг хэрэглэнэ Амьд байна.
Бид Helm-тэй 1000+ программыг байршуулдаг тул бид үнэндээ хоёр талын нэгдлээр амьдардаг. Гэсэн хэдий ч энэ нь бидний засваруудаар шийдсэн хэд хэдэн асуудалтай бөгөөд энэ нь Хелмийг хэвийн ажиллахад тусалдаг.
Бодит нэвтрүүлэх төлөв
Манай CI систем дараагийн үйл явдал дээр үндэслэн Kubernetes-ийн шинэ тохиргоог үүсгэсний дараа үүнийг ашиглахаар дамжуулдаг. (хэрэглэх) кластер руу - Helm эсвэл ашиглан kubectl apply. Дараа нь аль хэдийн тайлбарласан N хэлбэрийн нэгдэл хийгдэж, Kubernetes API нь CI систем болон түүний хэрэглэгчдэд зөвшөөрч хариу өгдөг.
Гэсэн хэдий ч маш том асуудал байна: эцсийн эцэст амжилттай хэрэглүүр гэдэг нь амжилттай нэвтрүүлсэн гэсэн үг биш юм. Хэрэв Кубернетес ямар өөрчлөлт оруулах ёстойг ойлгож, хэрэгжүүлбэл үр дүн нь юу болохыг бид мэдэхгүй хэвээр байна. Жишээлбэл, урд талдаа pod-уудыг шинэчлэх, дахин эхлүүлэх нь амжилттай байж болох ч арын хэсэгт биш бөгөөд бид ажиллаж байгаа програмын зургийн өөр өөр хувилбаруудыг авах болно.
Бүх зүйлийг зөв хийхийн тулд энэ схемд нэмэлт холбоос шаардлагатай - Kubernetes API-аас статусын мэдээллийг хүлээн авч, бодит байдлын цаашдын дүн шинжилгээнд дамжуулах тусгай трекер. Бид Go дээр Нээлттэй эхийн номын сан үүсгэсэн - (түүний мэдэгдлийг үзнэ үү ), энэ асуудлыг шийдэж, werf-д суурилуулсан.
Энэ трекерийн werf түвшний зан төлөвийг Deployments эсвэл StatefulSets дээр байрлуулсан тэмдэглэгээг ашиглан тохируулсан. Үндсэн тайлбар - fail-mode - дараах утгыг ойлгодог.
-
IgnoreAndContinueDeployProcess- бид энэ бүрэлдэхүүн хэсгийг нэвтрүүлэхтэй холбоотой асуудлуудыг үл тоомсорлож, байршуулалтыг үргэлжлүүлэх; -
FailWholeDeployProcessImmediately- энэ бүрэлдэхүүн хэсгийн алдаа нь байршуулах процессыг зогсооно; -
HopeUntilEndOfDeployProcess- Энэ бүрэлдэхүүн хэсэг нь ашиглалтын төгсгөлд ажиллана гэж найдаж байна.
Жишээлбэл, нөөц ба тэмдэглэгээний утгын хослол fail-mode:
Биднийг анх удаа байршуулах үед мэдээллийн сан (MongoDB) хараахан бэлэн болоогүй байж магадгүй - Байрлуулалт амжилтгүй болно. Гэхдээ та үүнийг эхлүүлэх мөчийг хүлээх боломжтой бөгөөд байршуулалт үргэлжлэх болно.
Werf-д kubedog-д зориулсан өөр хоёр тайлбар бий:
-
failures-allowed-per-replica- хуулбар бүрийн зөвшөөрөгдөх уналтын тоо; -
show-logs-until— бүх өнхрүүлсэн хонхорцогоос верф (stdout-д) лог харуулах хүртэл мөчийг зохицуулдаг. Анхдагч ньPodIsReady(Под руу ачаалал ирэх үед бидний хүсээгүй мессежийг үл тоомсорлох), гэхдээ утга нь бас хүчинтэй байна:ControllerIsReadyиEndOfDeploy.
Бид байршуулахаас өөр юу хүсч байна вэ?
Өмнө дурьдсан хоёр зүйлээс гадна бид дараахь зүйлийг хүсч байна.
- үзэх гэж бүртгэлүүд - зөвхөн шаардлагатай, гэхдээ дараалсан бүх зүйл биш;
- мөр ахиц дэвшил, учир нь ажил хэдэн минутын турш "чимээгүй" унжсан бол тэнд юу болж байгааг ойлгох нь чухал юм;
- иметь автомат буцаах ямар нэг зүйл буруу болсон тохиолдолд (тиймээс байршуулалтын бодит байдлыг мэдэх нь маш чухал). Нэвтрүүлэлт нь атомын шинж чанартай байх ёстой: эсвэл энэ нь эцсээ хүртэл дамждаг, эсвэл бүх зүйл өмнөх төлөвтөө буцаж ирдэг.
Үр дүн
Компанийн хувьд бидний хувьд тайлбарласан бүх нюансуудыг хүргэх янз бүрийн үе шатуудад (барих, нийтлэх, байршуулах) хэрэгжүүлэхэд CI систем, хэрэгсэл хангалттай. .
Дүгнэлтийн оронд:
Werf-ийн тусламжтайгаар бид DevOps-ийн инженерүүдийн олон тооны асуудлыг шийдвэрлэхэд сайн ахиц дэвшил гаргасан бөгөөд өргөн хүрээний хүмүүс ядаж энэ хэрэгслийг ашиглахыг оролдвол баяртай байх болно. Хамтдаа сайн үр дүнд хүрэх нь илүү хялбар байх болно.
Видео болон слайд
Гүйцэтгэлийн видео (~47 минут):
Илтгэлийн танилцуулга:
PS
Манай блог дээрх Кубернетесийн талаархи бусад мэдээллүүд:
- «» (Дмитрий Столяров; 27 оны 2019-р сарын XNUMX-нд "Ажил хаялт" дээр);
- «» (Андрей Половов; 8 оны 2019-р сарын XNUMX, Saint HighLoad++ дээр);
- «» (Дмитрий Столяров; 8 оны 2018-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 28 оны 2018-р сарын XNUMX-нд RootConf дээр);
- «» (Дмитрий Столяров; 7 оны 2017-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 6 оны 2017-р сарын XNUMX-нд RootConf дээр).
Эх сурвалж: www.habr.com