Meie ettevõttes True Engineering oleme loonud protsessi pidevaks värskenduste edastamiseks klientide serveritesse ja soovime seda kogemust jagada.
Alustuseks töötasime kliendi jaoks välja veebipõhise süsteemi ja juurutasime selle oma Kubernetese klastris. Nüüd on meie suure koormusega lahendus kolinud kliendi platvormile, mille jaoks oleme seadistanud täisautomaatse pideva juurutamise protsessi. Tänu sellele kiirendasime turuletuleku aega – muudatuste tarnimist tootekeskkonda.
Selles artiklis räägime kõigist pideva juurutamise (CD) protsessi või kliendi platvormile värskenduste tarnimise etappidest:
- Kuidas see protsess algab?
- sünkroonimine kliendi Giti hoidlaga,
- tausta- ja esiosa kokkupanek,
- automaatne rakenduse juurutamine testkeskkonnas,
- automaatne juurutamine tootele.
Jagame seadistamise üksikasju.
1. Käivitage CD
Pidev juurutamine algab sellega, et arendaja teeb muudatused meie Giti hoidla väljalaskeharus.
Meie rakendus töötab mikroteenuse arhitektuuril ja kõik selle komponendid on salvestatud ühte hoidlasse. Tänu sellele kogutakse ja paigaldatakse kõik mikroteenused, isegi kui üks neist on muutunud.
Korraldasime tööd ühe hoidla kaudu mitmel põhjusel:
- Arenduslihtsus - rakendus areneb aktiivselt, nii et saate kogu koodiga korraga töötada.
- Üks CI/CD konveier, mis tagab, et rakendus ühtse süsteemina läbib kõik testid ja tarnitakse kliendi tootmiskeskkonda.
- Me välistame segaduse versioonides – me ei pea salvestama mikroteenuse versioonide kaarti ega kirjeldama selle konfiguratsiooni iga mikroteenuse jaoks Helmi skriptides.
2. Sünkroonimine kliendi lähtekoodi Giti hoidlaga
Tehtud muudatused sünkroonitakse automaatselt kliendi Giti hoidlaga. Seal konfigureeritakse rakenduse koost, mis käivitatakse pärast haru värskendamist, ja juurutamine jätkuks. Mõlemad protsessid pärinevad nende keskkonnast Giti hoidlast.
Me ei saa otse kliendi hoidlaga töötada, sest vajame arendamiseks ja testimiseks oma keskkondi. Kasutame nendel eesmärkidel oma Giti hoidlat – see on sünkroonitud nende Giti hoidlaga. Niipea, kui arendaja postitab muudatused meie hoidla vastavasse haru, edastab GitLab need muudatused kohe kliendile.
Pärast seda peate tegema montaaži. See koosneb mitmest etapist: tausta- ja esiosa kokkupanek, testimine ja tootmisse tarnimine.
3. Tausta- ja esiosa kokkupanek
Taustaprogrammi ja esiprogrammi loomine on kaks paralleelset ülesannet, mida tehakse GitLab Runneri süsteemis. Selle algne koostekonfiguratsioon asub samas hoidlas.
.
GitLab Runner võtab koodi vajalikust hoidlast, paneb selle Java rakenduse ehitamise käsuga kokku ja saadab Dockeri registrisse. Siin paneme kokku tausta- ja esiosa, hangime Dockeri pildid, mille paneme kliendi poolel olevasse hoidlasse. Dockeri piltide haldamiseks kasutame .
Sünkroonime oma piltide versioonid Dockeris avaldatava versiooniga. Sujuva töö tagamiseks oleme teinud mitmeid kohandusi:
1. Testkeskkonna ja tootmiskeskkonna vahel konteinereid ümber ei ehitata. Tegime parameetrid, et sama konteiner saaks ilma ümberehitamiseta töötada kõigi seadete, keskkonnamuutujate ja teenustega nii testkeskkonnas kui ka tootmises.
2. Rakenduse värskendamiseks Helmi kaudu peate määrama selle versiooni. Ehitame taustaprogrammi, frontendi ja värskendame rakendust – need on kolm erinevat ülesannet, mistõttu on oluline kasutada kõikjal sama rakenduse versiooni. Selle ülesande jaoks kasutame Giti ajaloo andmeid, kuna meie K8S-i klastri konfiguratsioon ja rakendused asuvad samas Giti hoidlas.
Rakenduse versiooni saame käsu täitmise tulemustest
git describe --tags --abbrev=7.
4. Kõigi testkeskkonna (UAT) muudatuste automaatne juurutamine
Selle ehitusskripti järgmine samm on K8S-i klastri automaatne värskendamine. See juhtub tingimusel, et kogu rakendus on loodud ja kõik artefaktid on Dockeri registris avaldatud. Pärast seda käivitub testkeskkonna värskendus.
Klastri värskendust hakatakse kasutama . Kui selle tulemusena ei läinud miski plaanipäraselt, tühistab Helm kõik oma muudatused automaatselt ja iseseisvalt. Tema tööd ei pea kontrollima.
Tarnime K8S klastri konfiguratsiooni koos koostuga. Seetõttu on järgmine samm selle värskendamine: konfiguratsioonikaardid, juurutused, teenused, saladused ja kõik muud K8S-i konfiguratsioonid, mida oleme muutnud.
Seejärel käivitab Helm testkeskkonnas rakenduse enda juurutamise värskenduse. Enne rakenduse tootmisse juurutamist. Seda tehakse selleks, et kasutajad saaksid käsitsi testida ärifunktsioone, mille me testkeskkonda lisame.
5. Prod. kõigi muudatuste automaatne juurutamine
Tootmiskeskkonna värskenduse juurutamiseks peate lihtsalt klõpsama GitLabis ühte nuppu – ja konteinerid toimetatakse kohe tootmiskeskkonda.
Sama rakendus võib töötada erinevates keskkondades – katse- ja tootmiskeskkondades – ilma ümberehitamiseta. Kasutame samu artefakte ilma rakenduses midagi muutmata ja parameetrid määrame väliselt.
Rakenduse sätete paindlik parameetrite määramine sõltub keskkonnast, milles rakendust käivitatakse. Kõik keskkonnaseaded oleme teisaldanud väljastpoolt: kõike parameetristatakse K8S konfiguratsiooni ja Helmi parameetrite kaudu. Kui Helm juurutab koostu testkeskkonda, rakendatakse sellele testisätted ja tootesätted tootmiskeskkonnale.
Kõige keerulisem oli kõigi kasutatavate keskkonnast sõltuvate teenuste ja muutujate parameetrite määramine ning nende tõlkimine keskkonnamuutujateks ja keskkonnaparameetrite kirjeldusteks-konfiguratsioonideks Helmi jaoks.
Rakenduse seaded kasutavad keskkonnamuutujaid. Nende väärtused määratakse konteineritesse, kasutades K8S-i konfiguratsioonikaarti, mis on koostatud Go mallide abil. Näiteks saab domeeninimele keskkonnamuutuja määrata järgmiselt:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – see muutuja salvestab keskkonna nime (prod, stage, UAT).
.Values.app.properties.app_external_domain – selles muutujas määrame failis .Values.yaml soovitud domeeni
Rakenduse värskendamisel loob Helm mallidest faili configmap.yaml ja täidab APP_EXTERNAL_DOMAIN väärtuse soovitud väärtusega olenevalt keskkonnast, kus rakenduse värskendus algab. See muutuja on konteineris juba määratud. Sellele pääseb juurde rakendusest, seega on igal rakendusekeskkonnal selle muutuja jaoks erinev väärtus.
Suhteliselt hiljuti ilmus Spring Cloudis K8S-i tugi, sealhulgas töö configMapsiga: . Kuigi projekt areneb aktiivselt ja muutub radikaalselt, ei saa me seda tootmises kasutada. Kuid jälgime aktiivselt selle seisukorda ja kasutame seda DEV-i konfiguratsioonides. Niipea kui see stabiliseerub, läheme keskkonnamuutujate kasutamiselt sellele üle.
Kogusummas
Seega on pidev juurutamine konfigureeritud ja töötab. Kõik uuendused toimuvad ühe klahvivajutusega. Muudatuste edastamine tootekeskkonda on automaatne. Ja mis kõige tähtsam, värskendused ei peata süsteemi.
Tulevikuplaanid: automaatne andmebaaside migratsioon
Mõtlesime andmebaasi uuendamisele ja võimalusele need muudatused tagasi pöörata. Lõppude lõpuks töötab korraga kaks erinevat rakenduse versiooni: vana töötab ja uus on üleval. Ja me lülitame vana välja alles siis, kui oleme kindlad, et uus versioon töötab. Andmebaasi migreerimine peaks võimaldama teil töötada rakenduse mõlema versiooniga.
Seetõttu ei saa me lihtsalt veeru nime ega muid andmeid muuta. Aga me saame luua uue veeru, kopeerida sinna andmed vanast veerust ja kirjutada trigerid, mis andmete uuendamisel samaaegselt kopeerivad ja värskendavad neid teises veerus. Ja pärast rakenduse uue versiooni edukat juurutamist, pärast käivitamisjärgset tugiperioodi, saame kustutada vana veeru ja tarbetuks muutunud päästiku.
Kui rakenduse uus versioon ei tööta korralikult, saame tagasi pöörduda eelmisele versioonile, sealhulgas andmebaasi eelmisele versioonile. Lühidalt, meie muudatused võimaldavad teil töötada samaaegselt mitme rakenduse versiooniga.
Kavatseme automatiseerida andmebaaside migratsiooni K8S töö kaudu, integreerides selle CD protsessi. Ja kindlasti jagame seda kogemust ka Habres.
Allikas: www.habr.com