My v True Engineering sme nastavili proces nepretržitého doručovania aktualizácií na zákaznícke servery a chceme sa o túto skúsenosť podeliť.
Na začiatok sme pre zákazníka vyvinuli online systém a nasadili ho v našom vlastnom klastri Kubernetes. Teraz sa naše vysokozáťažové riešenie presunulo na zákaznícku platformu, pre ktorú sme nastavili plne automatický proces Continuous Deployment. Vďaka tomu sme zrýchlili time-to-market – dodanie zmien do produktového prostredia.
V tomto článku si povieme o všetkých fázach procesu Continuous Deployment (CD) alebo dodania aktualizácií na platformu zákazníka:
- Ako tento proces začína?
- synchronizácia s Git úložiskom zákazníka,
- montáž backendu a frontendu,
- automatické nasadenie aplikácie v testovacom prostredí,
- automatické nasadenie do Prod.
O podrobnostiach nastavenia sa podelíme.
1. Spustite CD
Nepretržité nasadzovanie sa začína tým, že vývojár zatlačí zmeny do vetvy vydania nášho úložiska Git.
Naša aplikácia beží na mikroservisnej architektúre a všetky jej komponenty sú uložené v jednom úložisku. Vďaka tomu sa zhromažďujú a inštalujú všetky mikroslužby, aj keď sa jedna z nich zmenila.
Prácu sme zorganizovali prostredníctvom jedného úložiska z niekoľkých dôvodov:
- Jednoduchosť vývoja - aplikácia sa aktívne vyvíja, takže môžete pracovať so všetkým kódom naraz.
- Jediný kanál CI/CD, ktorý zaručuje, že aplikácia ako jeden systém prejde všetkými testami a bude doručená do produkčného prostredia zákazníka.
- Eliminujeme zmätok vo verziách – nemusíme ukladať mapu verzií mikroslužby a popisovať jej konfiguráciu pre každú mikroslužbu v skriptoch Helm.
2. Synchronizácia zdrojového kódu zákazníka s úložiskom Git
Vykonané zmeny sa automaticky synchronizujú s úložiskom Git zákazníka. Tam sa konfiguruje zostava aplikácie, ktorá sa spustí po aktualizácii vetvy a nasadení do pokračovania. Oba procesy pochádzajú z ich prostredia z úložiska Git.
Nemôžeme pracovať priamo s úložiskom zákazníka, pretože na vývoj a testovanie potrebujeme vlastné prostredia. Na tieto účely používame naše úložisko Git – je synchronizované s ich úložiskom Git. Akonáhle vývojár odošle zmeny do príslušnej pobočky nášho úložiska, GitLab tieto zmeny okamžite pošle zákazníkovi.
Potom musíte vykonať montáž. Pozostáva z niekoľkých fáz: backend a frontend montáž, testovanie a dodávka do výroby.
3. Zostavenie backendu a frontendu
Budovanie backendu a frontendu sú dve paralelné úlohy, ktoré sa vykonávajú v systéme GitLab Runner. Jeho pôvodná konfigurácia zostavy sa nachádza v rovnakom úložisku.
.
GitLab Runner vezme kód z požadovaného úložiska, zostaví ho pomocou príkazu na zostavenie aplikácie Java a odošle ho do registra Docker. Tu zostavíme backend a frontend, získame obrázky Docker, ktoré uložíme do úložiska na strane zákazníka. Na správu obrázkov Docker, ktoré používame .
Verzie našich obrázkov synchronizujeme s verziou vydania, ktorá bude zverejnená v Dockeri. Pre bezproblémovú prevádzku sme urobili niekoľko úprav:
1. Kontajnery sa neprestavujú medzi testovacím prostredím a produkčným prostredím. Urobili sme parametrizácie tak, aby rovnaký kontajner mohol pracovať so všetkými nastaveniami, premennými prostredia a službami v testovacom prostredí aj vo výrobe bez prestavby.
2. Ak chcete aktualizovať aplikáciu cez Helm, musíte zadať jej verziu. Budujeme backend, frontend a aktualizujeme aplikáciu – ide o tri rôzne úlohy, preto je dôležité všade používať rovnakú verziu aplikácie. Na túto úlohu používame údaje z histórie Git, pretože naša konfigurácia klastra K8S a aplikácie sú v rovnakom úložisku Git.
Verziu aplikácie získame z výsledkov vykonania príkazu
git describe --tags --abbrev=7.
4. Automatické nasadenie všetkých zmien do testovacieho prostredia (UAT)
Ďalším krokom v tomto zostavovacom skripte je automatická aktualizácia klastra K8S. K tomu dochádza za predpokladu, že bola vytvorená celá aplikácia a všetky artefakty boli zverejnené v registri Docker. Potom sa spustí aktualizácia testovacieho prostredia.
Aktualizácia klastra sa spustí pomocou . Ak v dôsledku toho niečo nejde podľa plánu, Helm automaticky a nezávisle vráti späť všetky svoje zmeny. Jeho prácu netreba kontrolovať.
Klastrovú konfiguráciu K8S dodávame spolu s montážou. Ďalším krokom je preto jeho aktualizácia: configMaps, nasadenia, služby, tajomstvá a akékoľvek ďalšie konfigurácie K8S, ktoré sme zmenili.
Helm potom spustí RollOut aktualizáciu samotnej aplikácie v testovacom prostredí. Pred nasadením aplikácie do produkcie. Deje sa tak preto, aby používatelia mohli manuálne testovať obchodné funkcie, ktoré sme vložili do testovacieho prostredia.
5. Automatické nasadenie všetkých zmien do Prod
Ak chcete nasadiť aktualizáciu do produkčného prostredia, stačí kliknúť na jedno tlačidlo v GitLab – a kontajnery sú okamžite doručené do produkčného prostredia.
Tá istá aplikácia môže fungovať v rôznych prostrediach – testovacie a produkčné – bez prestavby. Používame rovnaké artefakty bez toho, aby sme v aplikácii čokoľvek menili a parametre nastavujeme externe.
Flexibilná parametrizácia nastavení aplikácie závisí od prostredia, v ktorom sa bude aplikácia vykonávať. Všetky nastavenia prostredia sme presunuli externe: všetko je parametrizované cez konfiguráciu K8S a parametre Helm. Keď Helm nasadí zostavu do testovacieho prostredia, použijú sa na ňu testovacie nastavenia a nastavenia produktu sa aplikujú na produkčné prostredie.
Najťažšie bolo parametrizovať všetky používané služby a premenné, ktoré závisia od prostredia, a previesť ich do premenných prostredia a popis-konfigurácia parametrov prostredia pre Helm.
Nastavenia aplikácie používajú premenné prostredia. Ich hodnoty sa nastavujú v kontajneroch pomocou konfiguračnej mapy K8S, ktorá je šablónovaná pomocou šablón Go. Napríklad nastavenie premennej prostredia na názov domény možno vykonať takto:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Hodnoty.globálne.sk – táto premenná ukladá názov prostredia (prod, stage, UAT).
.Values.app.properties.app_external_domain – v tejto premennej nastavíme požadovanú doménu v súbore .Values.yaml
Pri aktualizácii aplikácie Helm vytvorí súbor configmap.yaml zo šablón a naplní hodnotu APP_EXTERNAL_DOMAIN požadovanou hodnotou v závislosti od prostredia, v ktorom sa aktualizácia aplikácie spustí. Táto premenná je už nastavená v kontajneri. Dá sa k nej dostať z aplikácie, takže každé prostredie aplikácie bude mať pre túto premennú inú hodnotu.
Relatívne nedávno sa v Spring Cloud objavila podpora K8S vrátane práce s configMaps: . Zatiaľ čo sa projekt aktívne vyvíja a radikálne mení, nemôžeme ho použiť vo výrobe. Ale aktívne sledujeme jeho stav a používame ho v konfiguráciách DEV. Hneď ako sa stabilizuje, prejdeme naň z používania premenných prostredia.
Celkom
Nepretržité nasadenie je teda nakonfigurované a funguje. Všetky aktualizácie sa uskutočnia jedným stlačením klávesu. Doručenie zmien do prostredia produktu je automatické. A čo je dôležité, aktualizácie nezastavia systém.
Plány do budúcnosti: automatická migrácia databázy
Uvažovali sme o aktualizácii databázy a možnosti vrátenia týchto zmien späť. Koniec koncov, súčasne bežia dve rôzne verzie aplikácie: stará je spustená a nová je spustená. A tú starú vypneme, až keď budeme mať istotu, že nová verzia funguje. Migrácia databázy by vám mala umožniť prácu s oboma verziami aplikácie.
Preto nemôžeme jednoducho zmeniť názov stĺpca alebo iné údaje. Môžeme ale vytvoriť nový stĺpec, skopírovať doň dáta zo starého stĺpca a napísať spúšťače, ktoré pri aktualizácii dát súčasne skopírujú a aktualizujú dáta do iného stĺpca. A po úspešnom nasadení novej verzie aplikácie, po období podpory po spustení, budeme môcť vymazať starý stĺpec a spúšťač, ktorý sa stal nepotrebným.
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. Naše zmeny vám skrátka umožnia pracovať súčasne s viacerými verziami aplikácie.
Plánujeme automatizovať migráciu databázy prostredníctvom úlohy K8S a integrovať ju do procesu CD. A o tento zážitok sa na Habrého určite podelíme.
Zdroj: hab.com