Meie pideva juurutamise rakendus kliendi platvormile

Meie True Engineeringus oleme seadistanud pideva värskenduste kohaletoimetamise protsessi kliendi serveritesse ja soovime seda kogemust jagada.

Esiteks lõime veebipõhise süsteemi kliendi jaoks ja paigaldasime selle oma Kubernetes klastrisse. Nüüd on meie kõrge koormusega lahendus kolinud kliendi platvormile, mille jaoks oleme seadistanud täielikult automatiseeritud pideva kohaletoimetamise protsessi. Selle tõttu oleme kiirendanud toote keskkonda toimetamise aega.

Selles artiklis räägime kõigist pideva kohaletoimetamise (CD) protsessi etappidest või värskenduste kohaletoimetamisest kliendi platvormile:

1. kuidas see protsess algab,
2. sünkroonimine kliendi Git-reposiidiga,
3. tagaplaadi ja esiplaadi ehitamine,
4. rakenduse automaatne edasiviimine testkeskkonda,
5. rakenduse automaatne edasiviimine tootmisvõrku.

Protsessi käigus jagame seadistamise detaile.

1. CD käivitamine

Pidev kohaletoimetamine algab sellest, et arendaja paneb muudatused meie Git-reposiidi väljaanne harusse.

Meie rakendus töötab mikroteenuste arhitektuuri alusel ja kõik selle komponendid asuvad ühes repos. Seetõttu kogutakse ja installitakse kõik mikroteenused, isegi kui üks neist on muutunud.

Oleme korraldanud töö ühe repositooriumi kaudu mitmel põhjusel:

• Arendamise mugavus — rakendus areneb aktiivselt, seetõttu saab töödelda kohe kogu koodi.
• Üksik CI/CD torujuhe, mis tagab, et rakendus kui tervik läbib kõik testid ja toimetatakse kliendi tootmisvõrku.
• Vältime versioonide segadust — me ei pea hoidma mikroteenuste versioonikaarti ja kirjeldama iga mikroteenuse konfigureerimist Helm skritpides.

2. Sünkroonimine kliendi lähtekoodi Git-reposiidiga

Tehtud muudatused sünergeeruvad automaatselt kliendi Git-reposiidiga. Seal on seadistatud rakenduse kogumine, mis käivitub pärast haru värskendamist, ja tootmisvõrku edasiviimine. Mõlemad protsessid toimuvad nende keskkonnas Git-reposiidist.

Me ei saa töötada kliendi repositooriumiga otse, kuna meil on vaja oma arenduse ja testimise keskkondi. Me kasutame nende jaoks oma Git-repositooriumi — see on sünkroonitud nende Git-repositooriumiga. Kui arendaja väljendab muudatused meie repositooriumi vastavasse haru, saadab GitLab need kohe kliendile.

Seejärel tuleb teha kogumine. See koosneb mitmest etapist: tagaplaneeringu ja esipaneeli kogumine, testimine ja edastamine tootmisse.

3. Tagaplaneeringu ja esipaneeli kogumine

Tagaplaneeringu ja esipaneeli kogumine on kaks paralleelset ülesannet, mis täidetakse GitLab Runneris. Asetuse algse kogumise konfiguratsioon asub samas repositooriumis.

Juhend YAML-skripti kirjutamiseks GitLabis kogumiseks.

GitLab Runner võtab koodi õigest repositooriumist, kogumise Java-rakenduse käsuga kogub ja saadab selle Docker registry'sse. Siin me kogume tagaplaneeringu ja esipaneeli, saame Docker-pildid, mille paigutame kliendi poolel asuvasse repositooriumisse. Docker-piltide haldamiseks kasutame Gradle pluginit.

Me sünkroniseerime meie piltide versioonid väljaandmise versiooniga, mis Dockerisse pannakse. Sujuvaks toimimiseks tegime mõned seadistused:

1. Testkeskkonna ja tootmisest konteinerid ei koostatakse uuesti. Me tegime parameteriseerimise, et sama konteiner saaks töötada kõigi seadistuste, keskkonnaparameetrite ja teenustega nii testkeskkonnas kui ka tootmises ilma uuesti koostamiseta.

2. Rakenduse uuendamiseks Helmiga tuleb näidata selle versiooni. Meie tagaplaneeringu, esipaneeli kogumine ja rakenduse uuendamine on kolm erinevat ülesannet, seetõttu on oluline kasutada igal pool ühte ja sama rakenduse versiooni. Selle ülesande jaoks kasutame andmeid Git'i ajaloost, kuna meie K8S klastri ja rakenduse konfiguratsioon asub ühes Git-repositooriumis.

Rakenduse versiooni saadakse käsu
git describe --tags --abbrev=7.

4. Kõikide muudatuste automaatne juurutamine testkeskkonnas (UAT)

Selle kogumisskripti järgmisel etapil toimub K8S klastri automaatne uuendamine. See juhtub tingimusel, et kogu rakendus on kokku seatud ja kõik artefaktid on avaldatud Docker Registry's. Pärast seda käivitatakse testkeskkonna uuendamine.

Klastri uuendamine käivitatakse kasutades Helm'i uuendamine. Kui see protsess läheb valesti, tagab Helm automaatselt ja iseseisvalt kõik muudatused tagasi. Tema tööd ei pea jälgima.

Koos kogumisega anname K8S klastrikonfiguratsiooni. Seetõttu on järgmine samm selle uuendamine: configMaps, deployments, services, secrets ja kõik muud K8S konfiguratsioonid, mida oleme muutnud.

Pärast seda käivitab Helm rakenduse RollOut uuendamise testkeskkonnas. Enne rakenduse käivitamist tootmises. See on tehtud selleks, et kasutajad saaksid käesolevas testkeskkonnas käsitsi kontrollida meie välja pandud äriomadusi.

5. Kõigi muudatuste automaatne juurutamine Prod- keskkonda

Tootmisse uuenduse juurutamiseks tuleb vaid GitLabis vajutada ühele nupule — ja konteinerid toimetatakse kohe tootmiskeskkonda.

Sama rakendus võib töötada erinevates keskkondades — testimis- ja tootmisrežiimis — ilma uuesti üles ehitamata. Me kasutame samu artefakte, muutes rakenduses midagi, samas kui parameetrid määratakse väljastpoolt.

Rakenduse seadistuste paindlik parametriseerimine sõltub keskkonnast, kus rakendus töötab. Me oleme kõik keskkonnaseadistused välja viinud: kõik parametriseeritakse läbi K8S konfiguratsiooni ja Helm parameetrite. Kui Helm juurutab kogumise testkeskkonda, rakendatakse sellele testparameetreid, tootmiskeskkonnas aga tootmisparameetreid.

Kõige keerulisem oli kõiki kasutatavaid teenuseid ja muutujaid, mis sõltuvad keskkonnast, parametriseerida ning tõlkida need keskkonna muutujateks ja Helm'i parameetrite kirjeldamiseks.

Rakenduse parameetrites kasutatakse keskkonna muutujaid. Nende väärtused määratakse konteinerites K8S configmap'i kaudu, mis on Go-mallide abil mallitud. Näiteks, keskkonna muutuja määramine domeeni nimele võib välja näha selline:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – see muutuja sisaldab keskkonna nime (prod, stage, UAT).
.Values.app.properties.app_external_domain – selles muutuja, määrame .Values.yaml failis vajaliku domeeni

Helm rakenduse värskendamisel loob configmap.yaml faili šablonite põhjal ja täidab APP_EXTERNAL_DOMAIN väärtuse, mis sõltub keskkonnast, kus rakenduse värskendus käivitatakse. See muutujat kasutatakse juba konteineris. Rakendusel on sellele juurdepääs, seega on rakenduse igas keskkonnas selle muutuja väärtus erinev.

Suhteliselt hiljuti ilmus Spring Cloudis K8S tugi, sealhulgas töö configMapidega: Spring Cloud Kubernetes. Kuna projekt areneb aktiivselt ja muutub radikaalselt, ei saa me seda tootmises kasutada. Kuid jälgime selle seisukorda ja kasutame seda DEV konfiguratsioonides. Kui see stabiliseerub, siis liigume keskkonnamuutujate kasutamiselt selle juurde.

Kokkuvõttes

Nii et pidev juurutamine on seadistatud ja töötab. Kõik värskendused toimuvad ühe nupu vajutusega. Muudatuste toimetamine tootmisse toimub automaatselt. Ja mis oluline, värskendused ei peata süsteemi tööd.

Tulevikuplaanid: automaatne andmebaasi migratsioon

Oleme mõelnud andmebaasi uuendamisele ja võimalusele need muutused tagasi pöörata. Sest samal ajal töötavad kaks erinevat rakenduse versiooni: vana töötab ja uus tõstetakse üles. Ja vana välja lülitame alles siis, kui veendume, et uus versioon töötab. Andmebaasi migratsioon peab võimaldama töötada mõlema rakenduse versiooniga.

Seega ei saa me lihtsalt muuta veeru nime või muid andmeid. Kuid me saame luua uue veeru, kopeerida sinna andmed vanast veerust ja kirjutada triggerid, mis värskendades andmeid kopeerivad ja uuendavad need samal ajal teises veerus. Ja pärast uus versioon rakenduse edukat juurutamist, pärast post-launch toetuse perioodi, saame eemaldada vana veeru ja muutunud tarbetu triggeri.

Kui uus versioon rakendusest ei tööta korralikult, saame tagasi minna eelnenud versiooni juurde, sealhulgas ka eelneva andmebaasi versiooni juurde. Ühesõnaga, meie muudatused võimaldavad üheaegselt töötada mitme rakenduse versiooniga.

Kavandame andmebaasi migratsiooni automatiseerimist K8S töö kaudu, integreerides selle CD protsessi. Ja kindlasti jagame seda kogemust Habr's.

Allikas: habr.com