Mes, „True Engineering“, nustatėme nuolatinio atnaujinimų pristatymo į klientų serverius procesą ir norime pasidalinti šia patirtimi.
Pirmiausia klientui sukūrėme internetinę sistemą ir įdiegėme ją savo Kubernetes klasteryje. Dabar mūsų didelės apkrovos sprendimas persikėlė į kliento platformą, kuriai sukūrėme visiškai automatinį nuolatinio diegimo procesą. Dėl to paspartėjome pateikimo į rinką laiką – pokyčių pristatymą į produkto aplinką.
Šiame straipsnyje kalbėsime apie visus nuolatinio diegimo (CD) proceso etapus arba atnaujinimų pristatymą į kliento platformą:
- Kaip šis procesas prasideda?
- sinchronizavimas su kliento Git saugykla,
- galinės ir priekinės dalies surinkimas,
- automatinis programos diegimas bandomojoje aplinkoje,
- automatinis diegimas į Prod.
Pasidalinsime išsamia sąrankos informacija.
1. Paleiskite kompaktinį diską
Nuolatinis diegimas prasideda kūrėjui keičiant mūsų Git saugyklos leidimo šaką.
Mūsų programa veikia mikro paslaugų architektūroje, o visi jos komponentai yra saugomi vienoje saugykloje. Dėl to visos mikropaslaugos yra surenkamos ir įdiegiamos, net jei viena iš jų pasikeitė.
Mes organizavome darbą per vieną saugyklą dėl kelių priežasčių:
- Lengvas kūrimas - programa aktyviai vystosi, todėl galite dirbti su visu kodu vienu metu.
- Vienas CI/CD vamzdynas, garantuojantis, kad programa kaip viena sistema išlaikys visus testus ir bus pristatyta į kliento gamybos aplinką.
- Pašaliname painiavą versijose – mums nereikia saugoti mikro paslaugų versijų žemėlapio ir aprašyti jo konfigūraciją kiekvienai mikro paslaugai Helm scenarijuose.
2. Sinchronizavimas su kliento šaltinio kodo Git saugykla
Atlikti pakeitimai automatiškai sinchronizuojami su kliento „Git“ saugykla. Ten sukonfigūruojamas programos rinkinys, kuris paleidžiamas atnaujinus šaką, ir diegimas tęsiamas. Abu procesai atsiranda jų aplinkoje iš Git saugyklos.
Negalime tiesiogiai dirbti su kliento saugykla, nes mums reikia savo aplinkos kūrimui ir testavimui. Šiems tikslams naudojame savo Git saugyklą – ji sinchronizuojama su jų Git saugykla. Kai tik kūrėjas paskelbia pakeitimus atitinkamoje mūsų saugyklos šakoje, „GitLab“ nedelsiant perduoda šiuos pakeitimus klientui.
Po to turite atlikti surinkimą. Jį sudaro keli etapai: backend ir frontend surinkimas, testavimas ir pristatymas į gamybą.
3. Backend ir frontend surinkimas
Užpakalinės ir priekinės sistemos kūrimas yra dvi lygiagrečios užduotys, atliekamos sistemoje „GitLab Runner“. Jo pradinė surinkimo konfigūracija yra toje pačioje saugykloje.
.
„GitLab Runner“ paima kodą iš reikiamos saugyklos, surenka jį su „Java“ programos kūrimo komanda ir siunčia į „Docker“ registrą. Čia surenkame užpakalinę ir priekinę dalį, gauname „Docker“ atvaizdus, kuriuos įdedame į saugyklą kliento pusėje. Mes naudojame „Docker“ vaizdams valdyti .
Mes sinchronizuojame savo vaizdų versijas su leidimo versija, kuri bus paskelbta „Docker“. Kad veiktų sklandžiai, atlikome keletą pakeitimų:
1. Konteineriai neperstatomi tarp bandymo aplinkos ir gamybos aplinkos. Atlikome parametrizacijas, kad tas pats konteineris galėtų dirbti su visais nustatymais, aplinkos kintamaisiais ir paslaugomis tiek testinėje aplinkoje, tiek gamyboje be perstatymo.
2. Norėdami atnaujinti programą per Helm, turite nurodyti jos versiją. Kuriame backend, frontend ir atnaujiname aplikaciją – tai trys skirtingos užduotys, todėl svarbu visur naudoti tą pačią programos versiją. Šiai užduočiai atlikti naudojame duomenis iš „Git“ istorijos, nes mūsų K8S klasterio konfigūracija ir programos yra toje pačioje „Git“ saugykloje.
Programos versiją gauname iš komandos vykdymo rezultatų
git describe --tags --abbrev=7.
4. Automatinis visų bandymo aplinkos (UAT) pakeitimų diegimas
Kitas šio kūrimo scenarijaus veiksmas yra automatiškai atnaujinti K8S klasterį. Taip nutinka, jei visa programa buvo sukurta ir visi artefaktai paskelbti „Docker“ registre. Po to pradedamas bandomosios aplinkos naujinimas.
Pradedamas naudoti klasterio naujinimas . Jei dėl to kažkas neįvyko pagal planą, Helm automatiškai ir savarankiškai atšauks visus pakeitimus. Jo darbo nereikia kontroliuoti.
Kartu su surinkimu tiekiame K8S klasterio konfigūraciją. Todėl kitas žingsnis yra jį atnaujinti: configMaps, diegimai, paslaugos, paslaptys ir visos kitos mūsų pakeistos K8S konfigūracijos.
Tada „Helm“ bandomojoje aplinkoje paleidžia pačios programos „RollOut“ naujinimą. Prieš diegiant programą gamyboje. Tai daroma tam, kad vartotojai galėtų rankiniu būdu išbandyti verslo funkcijas, kurias mes įtraukėme į bandymo aplinką.
5. Automatinis visų Prod pakeitimų diegimas
Norėdami įdiegti naujinimą į gamybinę aplinką, tereikia spustelėti vieną mygtuką „GitLab“ – ir konteineriai iškart pristatomi į gamybos aplinką.
Ta pati programa gali veikti skirtingose aplinkose – bandymo ir gamybos – be atkūrimo. Mes naudojame tuos pačius artefaktus nieko nekeisdami programoje, o parametrus nustatome išoriškai.
Lankstus programos nustatymų parametrų nustatymas priklauso nuo aplinkos, kurioje programa bus vykdoma. Visus aplinkos nustatymus perkėlėme į išorę: viskas parametrizuojama per K8S konfigūraciją ir Helm parametrus. Kai „Helm“ diegia agregatą bandymo aplinkoje, jam taikomi bandymo parametrai, o gaminio parametrai – gamybos aplinkai.
Sunkiausia buvo parametrizuoti visas naudojamas paslaugas ir kintamuosius, kurie priklauso nuo aplinkos, ir paversti juos aplinkos kintamaisiais bei aplinkos parametrų aprašymais-konfigūracijas, skirtas Helm.
Programos nustatymuose naudojami aplinkos kintamieji. Jų reikšmės nustatomos konteineriuose naudojant K8S konfigūracijos žemėlapį, kuris yra suformuotas naudojant Go šablonus. Pavyzdžiui, nustatyti aplinkos kintamąjį domeno pavadinimui galima taip:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – šis kintamasis saugo aplinkos pavadinimą (prod, stage, UAT).
.Values.app.properties.app_external_domain – šiame kintamajame nustatome norimą domeną .Values.yaml faile
Atnaujindama programą, Helm sukuria configmap.yaml failą iš šablonų ir užpildo APP_EXTERNAL_DOMAIN reikšmę norima reikšme, priklausomai nuo aplinkos, kurioje pradedamas programos naujinimas. Šis kintamasis jau nustatytas sudėtiniame rodinyje. Jį galima pasiekti iš programos, todėl kiekviena programos aplinka turės skirtingą šio kintamojo reikšmę.
Palyginti neseniai „Spring Cloud“ pasirodė K8S palaikymas, įskaitant darbą su „configMaps“: . Kol projektas aktyviai vystosi ir radikaliai keičiasi, negalime jo panaudoti gamyboje. Tačiau mes aktyviai stebime jo būklę ir naudojame DEV konfigūracijas. Kai tik jis stabilizuosis, pereisime nuo aplinkos kintamųjų naudojimo prie jo.
Iš viso
Taigi, nuolatinis diegimas sukonfigūruotas ir veikia. Visi atnaujinimai atliekami vienu klavišo paspaudimu. Pakeitimų pristatymas į produkto aplinką yra automatinis. Ir, svarbiausia, atnaujinimai nesustabdo sistemos.
Ateities planai: automatinis duomenų bazių perkėlimas
Galvojome apie duomenų bazės atnaujinimą ir galimybę atšaukti šiuos pakeitimus. Juk vienu metu veikia dvi skirtingos aplikacijos versijos: veikia senoji, o nauja. O senąją išjungsime tik įsitikinę, kad naujoji versija veikia. Duomenų bazės perkėlimas turėtų leisti dirbti su abiem programos versijomis.
Todėl negalime tiesiog pakeisti stulpelio pavadinimo ar kitų duomenų. Bet galime sukurti naują stulpelį, nukopijuoti duomenis iš senojo stulpelio į jį ir įrašyti trigerius, kurie, atnaujindami duomenis, vienu metu nukopijuos ir atnaujins juos kitame stulpelyje. Sėkmingai įdiegus naują programos versiją, pasibaigus palaikymo laikotarpiui po paleidimo, galėsime ištrinti seną stulpelį ir trigerį, kuris tapo nereikalingas.
Jei naujoji programos versija neveikia tinkamai, galime grįžti prie ankstesnės versijos, įskaitant ankstesnę duomenų bazės versiją. Trumpai tariant, mūsų pakeitimai leis jums vienu metu dirbti su keliomis programos versijomis.
Planuojame automatizuoti duomenų bazių migraciją per K8S darbą, integruojant jį į CD procesą. Ir mes tikrai pasidalinsime šia patirtimi per Habré.
Šaltinis: www.habr.com