Biz True Engineering kompaniyasida mijozlar serverlariga yangilanishlarni uzluksiz yetkazib berish jarayonini o‘rnatdik va bu tajribani baham ko‘rmoqchimiz.
Boshlash uchun biz mijoz uchun onlayn tizimni ishlab chiqdik va uni o'z Kubernetes klasterimizga joylashtirdik. Endi bizning yuqori yukli yechimimiz mijoz platformasiga o'tdi, buning uchun biz to'liq avtomatik Uzluksiz joylashtirish jarayonini o'rnatdik. Buning yordamida biz bozorga chiqish vaqtini tezlashtirdik - mahsulot muhitiga o'zgarishlarni etkazib berish.
Ushbu maqolada biz doimiy joylashtirish (CD) jarayonining barcha bosqichlari yoki mijozning platformasiga yangilanishlarni etkazib berish haqida gaplashamiz:
- Bu jarayon qanday boshlanadi?
- mijozning Git ombori bilan sinxronlash,
- backend va frontendni yig'ish,
- sinov muhitida avtomatik ilovalarni joylashtirish,
- Prod.ga avtomatik joylashtirish.
Yo'l davomida sozlash tafsilotlarini baham ko'ramiz.
1. CD ni ishga tushiring
Uzluksiz joylashtirish dasturchi Git omborimizning relizlar bo'limiga o'zgarishlar kiritishi bilan boshlanadi.
Ilovamiz mikroservis arxitekturasida ishlaydi va uning barcha komponentlari bitta omborda saqlanadi. Buning yordamida barcha mikroservislar, hatto ulardan biri o'zgargan bo'lsa ham, yig'iladi va o'rnatiladi.
Biz bir nechta sabablarga ko'ra bitta ombor orqali ishni tashkil qildik:
- Rivojlanish qulayligi - dastur faol rivojlanmoqda, shuning uchun siz bir vaqtning o'zida barcha kodlar bilan ishlashingiz mumkin.
- Ilovaning yagona tizim sifatida barcha sinovlardan o'tishini va mijozning ishlab chiqarish muhitiga yetkazilishini kafolatlaydigan yagona CI/CD quvur liniyasi.
- Biz versiyalardagi chalkashliklarni bartaraf qilamiz - biz mikroservis versiyalari xaritasini saqlashimiz va Helm skriptlarida har bir mikroservis uchun uning konfiguratsiyasini tasvirlashimiz shart emas.
2. Mijozning manba kodining Git ombori bilan sinxronlash
Kiritilgan o'zgarishlar avtomatik ravishda mijozning Git ombori bilan sinxronlashtiriladi. U erda dasturni yig'ish konfiguratsiya qilinadi, u filialni yangilagandan so'ng ishga tushiriladi va davom ettirishga joylashtiriladi. Ikkala jarayon ham o'z muhitida Git omboridan kelib chiqadi.
Biz mijozning ombori bilan to'g'ridan-to'g'ri ishlay olmaymiz, chunki biz ishlab chiqish va sinovdan o'tkazish uchun o'z muhitimizga muhtojmiz. Biz ushbu maqsadlar uchun Git omborimizdan foydalanamiz - u ularning Git ombori bilan sinxronlashtiriladi. Ishlab chiquvchi bizning omborimizning tegishli bo'limiga o'zgarishlarni joylashtirgandan so'ng, GitLab bu o'zgarishlarni darhol mijozga yuboradi.
Shundan so'ng siz yig'ishni bajarishingiz kerak. U bir necha bosqichlardan iborat: backend va frontend yig'ish, sinovdan o'tkazish va ishlab chiqarishga yetkazib berish.
3. Backend va frontendni yig'ish
Backend va frontendni yaratish GitLab Runner tizimida bajariladigan ikkita parallel vazifadir. Uning asl yig'ish konfiguratsiyasi xuddi shu omborda joylashgan.
.
GitLab Runner kerakli ombordan kodni oladi, uni Java ilovasini yaratish buyrug'i bilan yig'adi va Docker registriga yuboradi. Bu erda biz backend va frontendni yig'amiz, Docker tasvirlarini olamiz, ularni mijoz tomonidagi omborga joylashtiramiz. Docker tasvirlarini boshqarish uchun biz foydalanamiz .
Biz rasmlarimiz versiyalarini Docker-da nashr etiladigan versiya bilan sinxronlashtiramiz. To'g'ri ishlash uchun biz bir nechta o'zgarishlar qildik:
1. Konteynerlar sinov muhiti va ishlab chiqarish muhiti o'rtasida qayta tiklanmaydi. Xuddi shu konteyner barcha sozlamalar, atrof-muhit o'zgaruvchilari va xizmatlar bilan sinov muhitida ham, ishlab chiqarishda ham qayta qurilmasdan ishlashi uchun parametrlashlarni amalga oshirdik.
2. Helm orqali dasturni yangilash uchun uning versiyasini ko'rsatish kerak. Biz backend, frontend quramiz va ilovani yangilaymiz - bular uch xil vazifa, shuning uchun hamma joyda dasturning bir xil versiyasidan foydalanish muhim. Ushbu vazifani bajarish uchun biz Git tarixidagi ma'lumotlardan foydalanamiz, chunki bizning K8S klaster konfiguratsiyasi va ilovalarimiz bir xil Git omborida joylashgan.
Biz dastur versiyasini buyruqni bajarish natijalaridan olamiz
git describe --tags --abbrev=7.
4. Sinov muhitiga barcha o'zgarishlarni avtomatik ravishda joylashtirish (UAT)
Ushbu qurish skriptidagi keyingi qadam K8S klasterini avtomatik yangilashdir. Bu, agar butun dastur qurilgan bo'lsa va barcha artefaktlar Docker registriga e'lon qilingan bo'lsa, sodir bo'ladi. Shundan so'ng, sinov muhitini yangilash boshlanadi.
Klaster yangilanishidan foydalanila boshlandi . Agar natijada biror narsa rejaga muvofiq ketmasa, Helm avtomatik ravishda va mustaqil ravishda barcha o'zgarishlarni orqaga qaytaradi. Uning ishini nazorat qilish kerak emas.
Biz K8S klaster konfiguratsiyasini yig'ish bilan birga yetkazib beramiz. Shuning uchun, keyingi qadam uni yangilashdir: configMaps, joylashtirishlar, xizmatlar, sirlar va biz o'zgartirgan boshqa K8S konfiguratsiyalari.
Keyin Helm sinov muhitida dasturning RollOut yangilanishini ishga tushiradi. Ilova ishlab chiqarishga joylashtirilgunga qadar. Bu foydalanuvchilar biz sinov muhitiga kiritgan biznes xususiyatlarini qo'lda sinab ko'rishlari uchun amalga oshiriladi.
5. Prod-ga barcha o'zgarishlarni avtomatik ravishda joylashtirish
Ishlab chiqarish muhitiga yangilanishni o'rnatish uchun GitLab-da bitta tugmani bosish kifoya - va konteynerlar darhol ishlab chiqarish muhitiga yetkaziladi.
Xuddi shu dastur turli muhitlarda - sinov va ishlab chiqarishda - qayta tiklanmasdan ishlashi mumkin. Biz dasturda hech narsani o'zgartirmasdan bir xil artefaktlardan foydalanamiz va parametrlarni tashqi tomondan o'rnatamiz.
Ilova sozlamalarini moslashuvchan parametrlashtirish dastur bajariladigan muhitga bog'liq. Biz barcha muhit sozlamalarini tashqariga ko'chirdik: hamma narsa K8S konfiguratsiyasi va Helm parametrlari orqali parametrlangan. Helm montajni sinov muhitiga joylashtirganda, sinov sozlamalari unga qo'llaniladi va mahsulot sozlamalari ishlab chiqarish muhitiga qo'llaniladi.
Eng qiyin narsa atrof-muhitga bog'liq bo'lgan barcha foydalanilgan xizmatlar va o'zgaruvchilarni parametrlash va ularni atrof-muhit o'zgaruvchilari va Helm uchun muhit parametrlarining tavsifi-konfiguratsiyalariga tarjima qilish edi.
Ilova sozlamalari muhit o'zgaruvchilaridan foydalanadi. Ularning qiymatlari Go shablonlari yordamida shablonlangan K8S konfiguratsiya xaritasi yordamida konteynerlarda o'rnatiladi. Masalan, domen nomiga muhit o'zgaruvchisini o'rnatish quyidagicha amalga oshirilishi mumkin:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – bu o‘zgaruvchi muhit nomini saqlaydi (mahsulot, bosqich, UAT).
.Values.app.properties.app_external_domain - bu o'zgaruvchida biz .Values.yaml faylida kerakli domenni o'rnatamiz
Ilovani yangilashda Helm shablonlardan configmap.yaml faylini yaratadi va ilovani yangilash boshlangan muhitga qarab APP_EXTERNAL_DOMAIN qiymatini kerakli qiymat bilan to'ldiradi. Bu o'zgaruvchi allaqachon konteynerda o'rnatilgan. Unga ilovadan kirish mumkin, shuning uchun har bir dastur muhiti ushbu o'zgaruvchi uchun boshqa qiymatga ega bo'ladi.
Nisbatan yaqinda Spring Cloud-da K8S qo'llab-quvvatlashi paydo bo'ldi, jumladan, configMaps bilan ishlash: . Loyiha faol rivojlanayotgan va tubdan o'zgarib borayotgan bo'lsa-da, biz uni ishlab chiqarishda ishlata olmaymiz. Ammo biz uning holatini faol ravishda kuzatib boramiz va uni DEV konfiguratsiyalarida ishlatamiz. U barqarorlashishi bilan biz atrof-muhit o'zgaruvchilaridan foydalanishga o'tamiz.
jami
Shunday qilib, Uzluksiz joylashtirish sozlangan va ishlaydi. Barcha yangilanishlar bitta tugmani bosish bilan amalga oshiriladi. Mahsulot muhitiga o'zgarishlarni etkazib berish avtomatik. Va, eng muhimi, yangilanishlar tizimni to'xtatmaydi.
Kelajakdagi rejalar: ma'lumotlar bazasini avtomatik ko'chirish
Biz ma'lumotlar bazasini yangilash va bu o'zgarishlarni orqaga qaytarish imkoniyati haqida o'yladik. Axir, dasturning ikki xil versiyasi bir vaqtning o'zida ishlaydi: eskisi ishlayapti, yangisi esa ishlamoqda. Va biz eskisini faqat yangi versiya ishlayotganiga amin bo'lganimizda o'chirib qo'yamiz. Ma'lumotlar bazasini ko'chirish ilovaning ikkala versiyasi bilan ishlashga imkon berishi kerak.
Shuning uchun biz ustun nomini yoki boshqa ma'lumotlarni o'zgartira olmaymiz. Ammo biz yangi ustun yaratishimiz, unga eski ustundan ma'lumotlarni nusxalashimiz va ma'lumotlarni yangilashda uni bir vaqtning o'zida boshqa ustunga nusxalash va yangilash uchun triggerlarni yozishimiz mumkin. Ilovaning yangi versiyasi muvaffaqiyatli o'rnatilgandan so'ng, ishga tushirishdan keyingi qo'llab-quvvatlash davridan keyin biz eski ustunni va keraksiz bo'lib qolgan triggerni o'chirib tashlashimiz mumkin bo'ladi.
Agar dasturning yangi versiyasi to'g'ri ishlamasa, biz oldingi versiyaga, shu jumladan ma'lumotlar bazasining oldingi versiyasiga qaytishimiz mumkin. Muxtasar qilib aytganda, bizning o'zgarishlarimiz bir vaqtning o'zida dasturning bir nechta versiyalari bilan ishlashga imkon beradi.
Biz K8S ishi orqali ma'lumotlar bazasi migratsiyasini avtomatlashtirishni, uni CD jarayoniga integratsiyalashni rejalashtirmoqdamiz. Va biz bu tajribani Habré-da baham ko'ramiz.
Manba: www.habr.com