Meil on True Engineeringis seadistatud pideva uuenduste kohaletoimetamise protsess kliendi serveritesse ning soovime seda kogemust jagada.
Alguses töötasime välja online-süsteemi kliendile ja juurutame selle oma Kubernetes'i klastrisse. Nüüd on meie suure koormusega lahendus kolinud kliendi platvormile, mille jaoks seadistasime täiesti automatiseeritud pideva juurutamise protsessi. Selle tulemusena suutsime kiirendada time-to-market – muudatuste kohaletoimetamist tootmiskeskkonda.
Selles artiklis räägime kõikidest pideva juurutamise (CD) protsessi etappidest, st. uuenduste kohaletoimetamisest kliendi platvormile:
- kuidas see protsess algab,
- sünkroneerimine kliendi Git-repositoriga,
- tagumise ja eesmise osa kokkuvõtmine,
- rakenduse automaatne juurutamine testkeskkonnas,
- automaatne juurutamine tootmisversioonis.
Protsessi käigus jagame seadistamise detaile.
1. CD algus
Pidev juurutamine algab sellest, et arendaja paneb muudatused meie Git-repositorio välja andmise haru.
Meie rakendus tugineb mikroteenuste arhitektuurile ja kõik selle komponendid on talletatud ühes hoidlates. Seetõttu kogutakse ja installitakse kõik mikroteenused, isegi kui üks neist on muutunud.
Oleme korraldanud töö ühes hoidlates mitmel põhjusel:
- Arenduse mugavus — rakendus areneb aktiivselt, seega saab töötada otse kogu koodiga.
- Ühtne CI/CD torustik, mis tagab, et rakendus kui tervik läbib kõik testid ja toimetatakse kliendi prod-keskkonda.
- Välistame versioonide segaduse — meil ei ole vaja hoida mikroteenuste versioonide kaarti ja määrata iga mikroteenuse jaoks oma konfiguratsiooni Helm'i skriptides.
2. Sünkroniseerimine kliendi lähtekoodi Git-repositooriumiga
Tehtud muudatused sünkroniseeritakse automaatselt kliendi Git-repositooriumiga. Seal on seadistatud rakenduse koostamine, mis käivitub pärast haru uuendamist, ja juurutamine prod. Mõlemad protsessid toimuvad nende keskkonnas Git-repositooriumist.
Me ei saa töötada kliendi repositooriumiga otse, kuna meil on vaja oma arendus- ja testimiskeskkondi. Me kasutame selleks oma Git-repositooriumi, mis on sünkroonitud nende Git-repositooriumiga. Kui arendaja paneb muudatused vastavasse meie repositooriumi haru, saadab GitLab need muudatused kohe kliendile.
Pärast seda tuleb teha kogumine. See koosneb mitmest etapist: tagakülje ja esikülje kogumisest, testimisest ja tootmiseks saatmisest.
3. Tagakülje ja esikülje kogumine
Tagakülje ja esikülje kogumine on kaks paralleelset ülesannet, mis täidetakse GitLab Runneri süsteemis. Algse kogumise konfigureerimine asub samas repositooriumis.
.
GitLab Runner toob koodi vajalikust repositooriumist, kogumist Java-rakendusele täidab ja saadab selle Docker registry. Siin me kogume tagakülje ja esikülje, saame Docker-pildid, mille viime kliendi repositooriumisse. Docker-piltide haldamiseks kasutame .
Sünkroniseerime oma piltide versioonid selle versiooniga, mis tuleb välja Dockerisse. Sujuva toimimise tagamiseks oleme sisse viinud mõned seadistused:
1. Testkeskkonna ja tootmisüksuste vahel ei toimu konteinerite uuesti koostamist. Oleme teinud parametreerimise, et sama konteiner saaks töötada erinevate seadistuste, muutujate ja teenustega nii testkeskkonnas kui ka tootmises ilma uuesti koostamata.
2. Rakenduse uuendamiseks läbi Helm tuleb määrata selle versioon. Meil on backend'i, frontend'i ja rakenduse uuendamine – see on kolm erinevat ülesannet, seega on oluline kasutada igas kohas sama rakenduse versiooni. Selle ülesande jaoks kasutame andmeid Git'i ajaloost, kuna meie K8S klastri ja rakenduse konfiguratsioon asuvad samas Git'i hoidis.
Rakenduse versiooni saame käsu täitmise tulemustest
git describe --tags --abbrev=7.
4. Kõikide muudatuste automaatne juurutamine testkeskkonnas (UAT)
Järgmine etapp selles koostamis skriptis on automaatne K8S klastri värskendamine. See toimub tingimusel, et kõik rakendused on kokku pandud ja kõik artefaktid on avaldatud Docker Registry's. Pärast seda käivitatakse testi keskkonna värskendamine.
Klastri värskendamine käivitatakse . Kui midagi ei lähe plaanipäraselt, tagastab Helm automaatselt kõik oma muudatused. Selle tööd ei pea jälgima.
Meie koostamisega kaasas on K8S klastri konfigureerimine. Seega järgmiseks sammuks värskendatakse seda: configMaps, deployments, services, secrets ja kõik muud K8S konfiguratsioonid, mida oleme muutnud.
Pärast seda käivitab Helm RollOut värskenduse rakendusele testikeskkonnas. Enne, kui rakendus viiakse tootmisettevõttesse. See toimub selleks, et kasutajad saaksid käsitsi kontrollida ärifunktsioone, mille me testikeskkonda välja panime.
5. Kõikide muudatuste automaatne juurutamine tootmisse
Et juurutada värskendust tootmiskeskkonda, peab lihtsalt vajutama ühele nupule GitLab'is — ja konteinerid toimetatakse kohe tootmiskeskkonda.
Sama rakendus saab töötada erinevates keskkondades — test- ja tootmises — ilma rekodeerimiseta. Kasutame samu artefakte, muutes rakenduses midagi, samas kui parameetrid määratakse väljaspool.
Rakenduse seadete paindlik parametriseerimine sõltub keskkonnast, kus rakendus hakkab töötama. Oleme viinud kõik keskkonna seadistused väljapoole: kõik parametreeritakse K8S konfiguratsiooni ja Helm parameetrite kaudu. Kui Helm paigaldab kokkuvõtte testkeskkonda, rakendatakse sellele testparameetreid, tootmises aga tootmisparameetreid.
Kõige keerulisem oli parametriseerida kõik kasutatavad teenused ja muutujad, mis sõltuvad keskkonnast, ning muuta need keskkonna muutujateks ja Helm parameetrite konfiguratsioonikirjelduseks.
Rakenduse parameetrites kasutatakse keskkonna muutujaid. Nende väärtused määratakse konteinerites K8S configmap'i abil, mis malleb Go-mallide abil. Näiteks saab keskkonna muutuja määrata domeeninime jaoks järgmiselt:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – selles muutuja salvestatakse keskkonna nimi (prod, stage, UAT).
.Values.app.properties.app_external_domain – selles muutuja määrame failis .Values.yaml soovitud domeeni
Rakenduse uuendamisel loob Helm configmap.yaml faili mallidest ja täidab APP_EXTERNAL_DOMAIN väärtuse vastavalt sellele, millises keskkonnas rakenduse uuendamine käivitatakse. See muutuja määratakse juba konteineris. Rakendus pääseb sellele juurde, seega on igas rakenduse keskkonnas selle muutuja väärtus erinev.
Suhteliselt hiljuti ilmus Spring Cloudisse K8S-i toetus, sealhulgas töö configMaps'iga: . Kuna projekt areneb aktiivselt ja muutub kardinaalselt, ei saa me seda prod'is kasutada. Kuid jälgime aktiivselt selle seisundit ja kasutame seda DEV konfiguratsioonides. Kui see stabiliseerub, lülitume keskkonna muutujate kasutamiselt selle peale.
Kokku
Nii et pidev juurutamine on seadistatud ja töötab. Kõik uuendused toimuvad ühe nupuvajutusega. Muudatuste tarnimine tootmisringkonda on automaatne. Ja mis kõige tähtsam, uuendused ei peata süsteemi tööd.
Tuleviku plaanid: automaatne andmebaasi migratsioon
Oleme mõelnud andmebaasi uuendamisele ja võimalustele need muutused tagasi pöörduda. Lõppude lõpuks töötavad samal ajal kaks erinevat versiooni rakendusest: vana versioon töötab ja uus tõstetakse üles. Vana versioon lülitame välja alles siis, kui oleme kindlad, et uus versioon töötab. Andmebaasi migratsioon peab võimaldama töötada mõlema rakenduse versiooniga.
Seetõttu ei saa me lihtsalt COLUMNi nime või teisi andmeid muuta. Kuid saame luua uue veeru, kopeerida andmed vanast veerust ja kirjutada käivitajad, mis andmete uuendamise korral samal ajal kopeerivad ja uuendavad need teises veerus. Ja pärast uue rakendusversiooni edukat juurutamist, pärast post-launch toe perioodi, saame vana veeru ja enam mitte vajalikud käivitajad eemaldada.
Kui uus rakendusversioon töötab ebaõigesti, saame naasta varasema versiooni juurde, sealhulgas varasema andmebaasi versiooni. Ühesõnaga, meie muudatused võimaldavad töötada samaaegselt mitme rakenduse versiooniga.
Küsimus on, kuidas planeeerime andmebaasi migreerimise automatiseerimist K8S töö jooksul, integreerides selle CD protsessiga. Jagame kindlasti seda kogemust Habras.
Allikas: habr.com
