Бид True Engineering-ийн хувьд хэрэглэгчийн серверт шинэчлэлтийг тасралтгүй хүргэх процессыг бий болгосон бөгөөд энэ туршлагаа хуваалцахыг хүсч байна.
Эхлээд бид үйлчлүүлэгчдэд зориулсан онлайн системийг боловсруулж, өөрийн Кубернетес кластерт байршуулсан. Одоо бидний өндөр ачаалалтай шийдэл нь хэрэглэгчийн платформ руу шилжсэн бөгөөд үүний тулд бид бүрэн автомат тасралтгүй байршуулах процессыг тохируулсан. Үүний ачаар бид зах зээлд гарах хугацааг хурдасгасан - бүтээгдэхүүний орчинд өөрчлөлт оруулах.
Энэ нийтлэлд бид тасралтгүй байршуулах (CD) үйл явц эсвэл хэрэглэгчийн платформд шинэчлэлт хүргэх бүх үе шатуудын талаар ярих болно.
- Энэ үйл явц хэрхэн эхэлдэг вэ?
- хэрэглэгчийн Git репозитортой синхрончлол хийх,
- арын болон урд талын угсралт,
- туршилтын орчинд автомат програм байрлуулах,
- Үйлдвэрлэлд автоматаар байршуулах.
Бид замын дагуу тохиргооны дэлгэрэнгүйг хуваалцах болно.
1. CD эхлүүлэх
Тасралтгүй байршуулалт нь хөгжүүлэгч манай Git репозиторын хувилбарын салбарт өөрчлөлт оруулахаас эхэлдэг.
Манай програм нь микро үйлчилгээний архитектур дээр ажилладаг бөгөөд түүний бүх бүрэлдэхүүн хэсэг нь нэг репозиторид хадгалагддаг. Үүний ачаар аль нэг нь өөрчлөгдсөн байсан ч бүх микро үйлчилгээг цуглуулж суулгадаг.
Бид хэд хэдэн шалтгааны улмаас нэг репозитороор дамжуулан ажлыг зохион байгуулсан.
- Хөгжүүлэхэд хялбар - програм идэвхтэй хөгжиж байгаа тул та бүх кодтой нэг дор ажиллах боломжтой.
- Нэг CI/CD дамжуулах хоолой нь програмыг нэг систем болгон бүх туршилтыг давж, хэрэглэгчийн үйлдвэрлэлийн орчинд хүргэх баталгаа болдог.
- Бид хувилбаруудын будлианыг арилгадаг - бид микро үйлчилгээний хувилбаруудын газрын зургийг хадгалах шаардлагагүй бөгөөд микро үйлчилгээ тус бүрийн тохиргоог Helm скрипт дээр тайлбарлах шаардлагагүй.
2. Хэрэглэгчийн эх кодын Git репозитортой синхрончлол хийх
Хийсэн өөрчлөлтүүд нь хэрэглэгчийн Git репозитортой автоматаар синхрончлогддог. Тэнд програмын угсралт тохируулагдсан бөгөөд энэ нь салбарыг шинэчилж, үргэлжлүүлэн суулгасны дараа эхлүүлдэг. Хоёр процесс хоёулаа Git репозитороос хүрээлэн буй орчиндоо үүсдэг.
Бидэнд хөгжүүлэлт, туршилт хийх орчин хэрэгтэй байгаа тул бид хэрэглэгчийн репозитортой шууд ажиллах боломжгүй. Бид эдгээр зорилгоор Git репозиторыг ашигладаг - энэ нь Git репозитортой синхрончлогдсон. Хөгжүүлэгч манай репозиторын зохих салбар руу өөрчлөлт оруулмагц GitLab эдгээр өөрчлөлтүүдийг шууд хэрэглэгч рүү шилжүүлдэг.
Үүний дараа та угсралтыг хийх хэрэгтэй. Энэ нь хэд хэдэн үе шатаас бүрдэнэ: арын болон урд талын угсралт, туршилт, үйлдвэрлэлд хүргэх.
3. Арын болон урд талын хэсгийг угсарч байна
Backend болон frontend-ийг бүтээх нь GitLab Runner системд хийгдэх хоёр зэрэгцээ ажил юм. Түүний анхны угсралтын тохиргоо нь ижил агуулахад байрладаг.
.
GitLab Runner нь шаардлагатай репозитороос код авч, Java application build командын тусламжтайгаар угсарч Docker регистрт илгээдэг. Энд бид backend болон frontend-ийг угсарч, Docker-ийн зургуудыг авч, хэрэглэгчийн талд байрлах агуулахад байрлуулна. Docker зургуудыг удирдахын тулд бид ашигладаг .
Бид зургийнхаа хувилбаруудыг Docker дээр нийтлэх хувилбартай синхрончилдог. Гөлгөр ажиллахын тулд бид хэд хэдэн тохируулга хийсэн:
1. Туршилтын орчин болон үйлдвэрлэлийн орчны хооронд савыг дахин бүтээдэггүй. Бид ижил контейнер бүх тохиргоо, орчны хувьсагч, үйлчилгээтэй туршилтын орчин болон үйлдвэрлэлийн аль алинд нь дахин бүтээн байгуулалт хийхгүйгээр ажиллах боломжтой байхын тулд параметржуулалт хийсэн.
2. Helm-ээр дамжуулан програмыг шинэчлэхийн тулд та түүний хувилбарыг зааж өгөх ёстой. Бид backend, frontend хийж, програмыг шинэчилдэг - эдгээр нь гурван өөр ажил тул програмын ижил хувилбарыг хаа сайгүй ашиглах нь чухал юм. Манай K8S кластерын тохиргоо болон програмууд Git репозитортой ижил байдаг тул бид энэ ажилд Git-н түүхийн өгөгдлийг ашигладаг.
Бид тушаалын гүйцэтгэлийн үр дүнгээс програмын хувилбарыг авдаг
git describe --tags --abbrev=7.
4. Туршилтын орчин дахь бүх өөрчлөлтийг автоматаар байршуулах (UAT)
Энэхүү бүтээх скриптийн дараагийн алхам бол K8S кластерийг автоматаар шинэчлэх явдал юм. Энэ нь програмыг бүхэлд нь бүтээж, бүх олдворуудыг Docker Registry-д нийтэлсэн тохиолдолд тохиолддог. Үүний дараа туршилтын орчны шинэчлэл эхэлнэ.
Кластерын шинэчлэлийг ашиглаж эхэллээ . Хэрэв үр дүнд нь ямар нэг зүйл төлөвлөгөөний дагуу явагдаагүй бол Helm бүх өөрчлөлтөө автоматаар, бие даан буцаах болно. Түүний ажлыг хянах шаардлагагүй.
Бид K8S кластерийн тохиргоог угсралтын хамт нийлүүлдэг. Тиймээс дараагийн алхам бол үүнийг шинэчлэх явдал юм: configMaps, байршуулалт, үйлчилгээ, нууц болон бидний өөрчилсөн бусад K8S тохиргоонууд.
Дараа нь Helm нь туршилтын орчинд програмын RollOut шинэчлэлтийг ажиллуулдаг. Програмыг үйлдвэрлэлд нэвтрүүлэхээс өмнө . Энэ нь хэрэглэгчид бидний туршилтын орчинд оруулсан бизнесийн онцлогуудыг гараар шалгахын тулд хийгддэг.
5. Бүтээгдэхүүний бүх өөрчлөлтийг автоматаар байршуулах
Үйлдвэрлэлийн орчинд шинэчлэлт оруулахын тулд та GitLab дээрх нэг товчлуур дээр дарахад л хангалттай бөгөөд савнууд нь үйлдвэрлэлийн орчинд шууд хүргэгдэнэ.
Нэг програм нь дахин бүтээхгүйгээр өөр өөр орчинд ажиллах боломжтой - туршилт, үйлдвэрлэл. Бид програмд юу ч өөрчлөхгүйгээр ижил олдворуудыг ашигладаг бөгөөд параметрүүдийг гаднаас нь тохируулдаг.
Програмын тохиргооны уян хатан параметрчилал нь тухайн програмыг гүйцэтгэх орчноос хамаарна. Бид хүрээлэн буй орчны бүх тохиргоог гаднаас нь шилжүүлсэн: бүх зүйл K8S тохиргоо болон Helm параметрүүдээр тодорхойлогддог. Helm нь угсралтыг туршилтын орчинд байрлуулах үед туршилтын тохиргоог түүнд хэрэглэж, бүтээгдэхүүний тохиргоог үйлдвэрлэлийн орчинд хэрэглэнэ.
Хамгийн хэцүү зүйл бол хүрээлэн буй орчноос хамаарах бүх ашигласан үйлчилгээ, хувьсагчдыг параметржүүлж, хүрээлэн буй орчны хувьсагчид болон Helm-д зориулсан орчны параметрүүдийн тайлбар-тохиргоо болгон хөрвүүлэх явдал байв.
Хэрэглээний тохиргоо нь орчны хувьсагчдыг ашигладаг. Тэдгээрийн утгыг Go загваруудыг ашиглан загварчилсан K8S configmap ашиглан саванд хийсэн болно. Жишээлбэл, домайн нэрэнд орчны хувьсагчийг дараах байдлаар тохируулж болно.
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – энэ хувьсагч нь орчны нэрийг (бүтээгдэхүүн, үе шат, UAT) хадгалдаг.
.Values.app.properties.app_external_domain – энэ хувьсагчаар бид .Values.yaml файлд хүссэн домайныг тохируулсан
Аппликешныг шинэчлэх үед Helm нь загваруудаас configmap.yaml файл үүсгэж, програмын шинэчлэлт эхэлж буй орчноос хамаарч APP_EXTERNAL_DOMAIN утгыг хүссэн утгаар дүүргэдэг. Энэ хувьсагчийг саванд аль хэдийн тохируулсан байна. Энэ нь програмаас хандах боломжтой тул програмын орчин бүр энэ хувьсагчийн өөр утгатай байх болно.
Харьцангуй саяхан K8S дэмжлэг Spring Cloud-д гарч ирсэн бөгөөд үүнд configMaps-тай ажиллах боломжтой. . Төсөл идэвхтэй хөгжиж, эрс өөрчлөгдөж байгаа ч бид үүнийг үйлдвэрлэлд ашиглах боломжгүй. Гэхдээ бид түүний нөхцөл байдлыг идэвхтэй хянаж, DEV тохиргоонд ашигладаг. Энэ нь тогтворжсон даруйд бид орчны хувьсагчийг ашиглахаас түүн рүү шилжих болно.
Нийт
Тиймээс Continous Deployment тохируулагдсан бөгөөд ажиллаж байна. Бүх шинэчлэлтүүд нэг товчлуур дарснаар хийгддэг. Бүтээгдэхүүний орчинд өөрчлөлт оруулах нь автоматаар хийгддэг. Хамгийн гол нь шинэчлэлтүүд системийг зогсоохгүй.
Ирээдүйн төлөвлөгөө: мэдээллийн санг автоматаар шилжүүлэх
Бид мэдээллийн баазыг шинэчлэх, эдгээр өөрчлөлтүүдийг буцаах талаар бодож үзсэн. Эцсийн эцэст, програмын хоёр өөр хувилбар нэгэн зэрэг ажиллаж байна: хуучин нь ажиллаж байгаа, шинэ нь ажиллаж байна. Шинэ хувилбар ажиллаж байгаа гэдэгт итгэлтэй байх үед л бид хуучин хувилбарыг унтраана. Өгөгдлийн сангийн шилжилт нь програмын хоёр хувилбартай ажиллах боломжийг танд олгоно.
Тиймээс бид баганын нэр эсвэл бусад өгөгдлийг өөрчлөх боломжгүй. Гэхдээ бид шинэ багана үүсгэж, хуучин баганаас өгөгдлийг хуулж, өгөгдлийг шинэчлэх үед өөр баганад нэгэн зэрэг хуулж, шинэчлэх триггерүүдийг бичиж болно. Програмын шинэ хувилбарыг амжилттай байрлуулсны дараа, эхлүүлсний дараа дэмжлэг үзүүлэх хугацаа дууссаны дараа бид хуучин багана болон шаардлагагүй болсон гохыг устгах боломжтой болно.
Хэрэв програмын шинэ хувилбар зөв ажиллахгүй бол бид өмнөх хувилбар, түүний дотор мэдээллийн сангийн өмнөх хувилбар руу буцах боломжтой. Товчхондоо, бидний өөрчлөлтүүд нь програмын хэд хэдэн хувилбартай нэгэн зэрэг ажиллах боломжийг олгоно.
Бид K8S ажлыг ашиглан мэдээллийн баазын шилжилтийг автоматжуулж, CD процесст оруулахаар төлөвлөж байна. Мөн бид энэ туршлагаа Хабре дээр хуваалцах нь гарцаагүй.
Эх сурвалж: www.habr.com