V True Engineering sme nastavili proces nepretržitého dodávania aktualizácií na servery zákazníka a chceme sa o túto skúsenosť podeliť.
Na začiatku sme vyvinuli online systém pre zákazníka a nasadili ho do vlastného klastrového prostredia Kubernetes. Teraz naše vysoko zaťažené riešenie presunulo na platformu zákazníka, pre čo sme nastavili plne automatizovaný proces Continuous Deployment. Vďaka tomu sme urýchlili time-to-market – dodanie zmien do produkčného prostredia.
V tomto článku prerozprávame všetky fázy procesu Continuous Deployment (CD) alebo dodávania aktualizácií na platformu zákazníka:
- ako tento proces začína,
- synchronizácia s Git-repozitárom zákazníka,
- kompilácia backendu a frontendu,
- automatické nasadenie aplikácie do testovacieho prostredia,
- automatické nasadenie na Prod.
Počas procesu sa podelíme o podrobnosti nastavenia.
1. Spustenie CD
Continuous Deployment začína tým, že vývojár zverejní zmeny do vydávacej vetvy nášho Git-repozitára.
Naša aplikácia funguje na báze mikroservisnej architektúry a všetky jej komponenty sú uložené v jednom repozitári. Vďaka tomu sa zostavujú a inštalujú všetky mikroservisy, aj keď sa zmenil jeden z nich.
Prácu sme organizovali cez jeden repozitár z niekoľkých dôvodov:
- Pohodlie vývoja – aplikácia sa aktívne rozvíja, preto je možné pracovať hneď so všetkým kódom.
- Jediný pipeline CI/CD, ktorý zaručuje, že aplikácia ako celok prechádza všetkými testami a dodáva sa do prod-prostredia zákazníka.
- Vylučujeme zmätok vo verziách – nemusíme uchovávať mapu verzií mikroservisov a opisovať pre každý mikroservis vlastnú konfiguráciu v skriptoch Helm.
2. Synchronizácia s Git-repozitárom zdrojového kódu zákazníka
Upravené zmeny sa automaticky synchronizujú s Git-repozitárom zákazníka. Tam je nastavená kompilácia aplikácie, ktorá sa spúšťa po aktualizácii vetvy a nasadení do produkcie. Obe procesy prebiehajú v ich prostredí z Git-repozitára.
Nemôžeme pracovať priamo s repozitárom zákazníka, pretože potrebujeme vlastné prostredia na vývoj a testovanie. Na tento účel používame náš Git-repozitár — je synchronizovaný s ich Git-repozitárom. Akonáhle vývojár zverejní zmeny v príslušnej vetve nášho repozitára, GitLab okamžite odosiela tieto zmeny zákazníkovi.
Po tomto je potrebné vykonať zostavenie. To pozostáva z viacerých krokov: zostavenia backendu a frontendu, testovania a nasadenia do produkcie.
3. Zostavenie backendu a frontendu
Zostavenie backendu a frontendu je dvojica paralelných úloh, ktoré sa vykonávajú v systéme GitLab Runner. Konfigurácia pôvodného zostavenia je uložená v tom istom repozitári.
.
GitLab Runner berie kód z potrebného repozitára, pomocou príkazu na zostavenie Java aplikácie ho zostaví a odošle do Docker registry. Tu zostavujeme backend a frontend, získavame Docker obrazy, ktoré ukládame do repozitára na strane zákazníka. Na správu Docker obrazov používame .
Synchronizujeme verzie našich obrazov s verziou vydania, ktorá bude vydaná v Dockeri. Pre hladký chod sme urobili niekoľko nastavení:
1. Medzi testovacím prostredím a produkčným sa kontajnery neprestavujú. Urobili sme parametrazáciu, aby ten istý kontajner mohol bez prestavovania fungovať so všetkými nastaveniami, premennými prostredím a službami ako v testovacej, tak v produkčnej fáze.
2. Na aktualizáciu aplikácie cez Helm je potrebné uviesť jej verziu. Naše zostavenie backendu, frontendu a aktualizácia aplikácie sú tri rôzne úlohy, preto je dôležité používať všade tú istú verziu aplikácie. Na tento účel využívame údaje z histórie Git, pretože naša konfigurácia K8S klastra a aplikácie sa nachádza v jednom Git-repozitári.
Verziu aplikácie získavame z výsledkov vykonania príkazu
git describe --tags --abbrev=7.
4. Automatické nasadenie všetkých zmien v testovacom prostredí (UAT)
Ďalším krokom v tomto skripte zostavenia je automatická aktualizácia klastra K8S. To sa deje pod podmienkou, že sa všetko aplikácia zostavila a všetky artefakty boli publikované v Docker Registry. Potom sa spustí aktualizácia testovacieho prostredia.
Aktualizácia klastra sa spúšťa pomocou . Ak niečo neprebehne podľa plánu, Helm automaticky vráti všetky svoje zmeny späť. Nie je potrebné sledovať jeho činnosť.
Dodávame spolu so zostavou konfiguráciu klastera K8S. Preto nasledujúcim krokom je jej aktualizácia: configMaps, deployments, services, secrets a akékoľvek iné konfigurácie K8S, ktoré sme zmenili.
Potom Helm spustí RollOut aktualizáciu samotnej aplikácie v testovacom prostredí. Predtým, ako bude aplikácia nasadená na produkčné prostredie. To je vykonané, aby používatelia mohli manuálne skontrolovať obchodné funkcie, ktoré sme nasadili do testovacieho prostredia.
5. Automatické nasadenie všetkých zmien na Prod
Na nasadenie aktualizácie do produkčného prostredia stačí stlačiť jedno tlačidlo v GitLab - a kontajnery okamžite prídu do produkčného prostredia.
Tá istá aplikácia môže bez opätovného zostavenia fungovať v rôznych prostrediach - testovom a produkčnom. Používame tie isté artefakty, bez toho, aby sme menili niečo v aplikácii, pričom parametre dávame zvonka.
Flexibilné parametrizovanie nastavení aplikácie závisí od prostredia, v ktorom bude aplikácia bežať. Všetky nastavenia prostredí sme preniesli von: všetko sa parametrizuje prostredníctvom konfigurácie K8S a parametrov Helm. Keď Helm nasadzuje zostavu do testovacieho prostredia, aplikujú sa testovacie parametre, a v produkčnom prostredí - produkčné parametre.
Najťažšie bolo parametrizovať všetky používané služby a premenne, ktoré závisia od prostredia, a previesť ich na premenné prostredia a popis-konfigurácie parametrov prostredia pre Helm.
V parametroch aplikácie sa používajú premenné prostredia. Ich hodnoty sú nastavené v kontajneroch pomocou K8S configmap, ktorý je šablonizovaný pomocou Go šablón. Napríklad, nastavenie premennej prostredia na názov domény môže byť urobené takto:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – táto premenná uchováva názov prostredia (prod, stage, UAT).
.Values.app.properties.app_external_domain – v tejto premennej nastavujeme potrebnú doménu v súbore .Values.yaml
Pri aktualizácii aplikácie Helm vytvára súbor configmap.yaml z šablón a vyplňuje hodnotu APP_EXTERNAL_DOMAIN požadovanou hodnotou v závislosti od prostredia, v ktorom sa aktualizácia aplikácie spúšťa. Táto premenná je nastavená už v kontajneri. Prístup k nej má aplikácia, a preto v každom prostredí aplikácie bude rôzna hodnota tejto premennej.
Relatívne nedávno sa v Spring Cloud objavila podpora K8S, vrátane práce s configMaps: . Kým sa projekt aktívne vyvíja a zásadne mení, nemôžeme ho používať v produkcii. Avšak aktívne monitorujeme jeho stav a používame ho v DEV konfiguráciách. Akonáhle sa stabilizuje, prepneme sa z používania premenných prostredia na neho.
Spolu
Takže, Continuous Deployment je nastavený a funguje. Všetky aktualizácie sa dejú jedným stlačením tlačidla. Dodávka zmien do produkčného prostredia je automatická. A čo je dôležité, aktualizácie nepřerušujú prácu systému.
Plány do budúcnosti: automatická migrácia databázy
Zamýšľali sme nad upgrade databázy a možnosťou zmeny týchto údajov vrátiť späť. Pretože súčasne bežia dve rôzne verzie aplikácie: stará verzia funguje, zatiaľ čo nová sa spúšťa. Stará verzia bude vypnutá len vtedy, keď sa uistíme, že nová verzia funguje. Migrácia databázy by mala umožniť fungovanie s oboma verziami aplikácie.
Preto nemôžeme len tak zmeniť názov stĺpca alebo iné údaje. Ale môžeme vytvoriť nový stĺpec, skopírovať do neho údaje zo starého stĺpca a napísať spúšťače, ktoré budú pri aktualizácii údajov zároveň kopírovať a aktualizovať ich v druhom stĺpci. A po úspešnom nasadení novej verzie aplikácie, po uplynutí doby post launch support, budeme môcť vymazať starý stĺpec a zbytočný spúšťač.
Ak nová verzia aplikácie nefunguje správne, môžeme sa vrátiť k predchádzajúcej verzii, vrátane predchádzajúcej verzie databázy. Skrátka, naše zmeny umožnia súbežne pracovať s viacerými verziami aplikácie.
Plánujeme automatizáciu migrácie databázy cez K8S job, integrovať ju do procesu CD. A určite sa podelíme o túto skúsenosť na Habre.
Zdroj: habr.com
