Pri True Engineering smo vzpostavili postopek za neprekinjeno dostavo posodobitev na strežnike strank in želimo deliti to izkušnjo.
Za začetek smo za naročnika razvili spletni sistem in ga uvedli v lastni gruči Kubernetes. Zdaj se je naša rešitev za visoke obremenitve preselila na platformo stranke, za katero smo vzpostavili popolnoma samodejen postopek neprekinjenega uvajanja. Zahvaljujoč temu smo pospešili čas do trga - dostavo sprememb v proizvodno okolje.
V tem članku bomo govorili o vseh stopnjah procesa neprekinjenega uvajanja (CD) oziroma dostave posodobitev na platformo stranke:
- Kako se začne ta proces?
- sinhronizacija s strankinim repozitorijem Git,
- sestavljanje backenda in frontenda,
- samodejno postavitev aplikacije v testnem okolju,
- samodejna uvedba v izdel.
Spotoma bomo delili podrobnosti o nastavitvi.
1. Zaženite CD
Neprekinjeno uvajanje se začne, ko razvijalec potisne spremembe v izdajno vejo našega repozitorija Git.
Naša aplikacija deluje na mikrostoritveni arhitekturi in vse njene komponente so shranjene v enem repozitoriju. Zahvaljujoč temu so zbrane in nameščene vse mikrostoritve, tudi če se je ena od njih spremenila.
Delo preko enega repozitorija smo organizirali iz več razlogov:
- Enostavnost razvoja - aplikacija se aktivno razvija, tako da lahko delate z vso kodo hkrati.
- En sam cevovod CI/CD, ki zagotavlja, da aplikacija kot enoten sistem prestane vse teste in je dostavljena v produkcijsko okolje stranke.
- Odpravljamo zmedo v različicah - ni nam treba shranjevati zemljevida različic mikrostoritve in opisovati njeno konfiguracijo za vsako mikrostoritev v skriptah Helm.
2. Sinhronizacija z repozitorijem Git izvorne kode stranke
Izvedene spremembe se samodejno sinhronizirajo s strankinim repozitorijem Git. Tam se konfigurira sklop aplikacije, ki se zažene po posodobitvi veje, in uvedba v nadaljevanje. Oba procesa izvirata iz svojega okolja iz repozitorija Git.
Ne moremo delati neposredno z repozitorijem stranke, ker potrebujemo lastna okolja za razvoj in testiranje. Za te namene uporabljamo naš Git repozitorij - sinhroniziran je z njihovim Git repozitorijem. Takoj ko razvijalec objavi spremembe v ustrezni veji našega skladišča, GitLab te spremembe nemudoma posreduje stranki.
Po tem morate opraviti montažo. Sestavljen je iz več faz: montaža zadnjega in sprednjega dela, testiranje in dobava v proizvodnjo.
3. Sestavljanje zaledja in sprednjega dela
Gradnja zaledja in sprednjega dela sta dve vzporedni nalogi, ki se izvajata v sistemu GitLab Runner. Njegova prvotna konfiguracija sestava se nahaja v istem skladišču.
.
GitLab Runner vzame kodo iz zahtevanega repozitorija, jo sestavi z ukazom za gradnjo aplikacije Java in jo pošlje v register Docker. Tu sestavimo backend in frontend, pridobimo Docker slike, ki jih damo v repozitorij na strani stranke. Za upravljanje slik Docker, ki jih uporabljamo .
Različice naših slik sinhroniziramo z različico za izdajo, ki bo objavljena v Dockerju. Za nemoteno delovanje smo naredili več prilagoditev:
1. Vsebniki se med testnim in produkcijskim okoljem ne sestavljajo znova. Naredili smo parametre, tako da lahko isti vsebnik deluje z vsemi nastavitvami, spremenljivkami okolja in storitvami tako v testnem okolju kot v produkciji brez ponovne gradnje.
2. Če želite posodobiti aplikacijo prek Helma, morate določiti njeno različico. Gradimo backend, frontend in posodobimo aplikacijo – to so tri različne naloge, zato je pomembno, da povsod uporabljamo isto različico aplikacije. Za to nalogo uporabljamo podatke iz zgodovine Git, saj so naša konfiguracija gruče K8S in aplikacije v istem repozitoriju Git.
Različico aplikacije dobimo iz rezultatov izvajanja ukaza
git describe --tags --abbrev=7.
4. Samodejna uvedba vseh sprememb v testno okolje (UAT)
Naslednji korak v tem gradbenem skriptu je samodejno posodabljanje gruče K8S. To se zgodi, če je bila zgrajena celotna aplikacija in so bili vsi artefakti objavljeni v registru Docker. Po tem se začne posodobitev testnega okolja.
Posodobitev gruče se začne z uporabo . Če zaradi tega nekaj ni šlo po načrtih, bo Helm samodejno in neodvisno povrnil vse svoje spremembe. Njegovega dela ni treba nadzirati.
Konfiguracijo gruče K8S dobavljamo skupaj s sklopom. Zato je naslednji korak, da ga posodobimo: configMaps, razmestitve, storitve, skrivnosti in vse druge konfiguracije K8S, ki smo jih spremenili.
Helm nato zažene RollOut posodobitev same aplikacije v testnem okolju. Preden je aplikacija uvedena v produkcijo. To je narejeno tako, da lahko uporabniki ročno preizkusijo poslovne funkcije, ki jih damo v testno okolje.
5. Samodejna uvedba vseh sprememb v Izd
Če želite namestiti posodobitev v produkcijsko okolje, morate samo klikniti en gumb v GitLabu - in vsebniki so takoj dostavljeni v produkcijsko okolje.
Ista aplikacija lahko deluje v različnih okoljih – testnem in produkcijskem – brez ponovne gradnje. Uporabljamo iste artefakte, ne da bi karkoli spremenili v aplikaciji, parametre pa nastavljamo od zunaj.
Fleksibilna parametrizacija nastavitev aplikacije je odvisna od okolja, v katerem se bo aplikacija izvajala. Vse nastavitve okolja smo premaknili navzven: vse je parametrirano prek konfiguracije K8S in parametrov Helm. Ko Helm razmesti sklop v testno okolje, se testne nastavitve uporabijo zanj, nastavitve izdelka pa se uporabijo za proizvodno okolje.
Najtežje je bilo vse uporabljene storitve in spremenljivke, ki so odvisne od okolja, parametrizirati in jih prevesti v spremenljivke okolja in opise-konfiguracije parametrov okolja za Helm.
Nastavitve aplikacije uporabljajo spremenljivke okolja. Njihove vrednosti so nastavljene v vsebnikih z uporabo konfiguracijskega zemljevida K8S, ki je oblikovan s predlogami Go. Nastavitev spremenljivke okolja za ime domene lahko na primer izvedete takole:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Vrednosti.global.env – ta spremenljivka shrani ime okolja (prod, stage, UAT).
.Values.app.properties.app_external_domain – v tej spremenljivki nastavimo želeno domeno v datoteki .Values.yaml
Pri posodabljanju aplikacije Helm ustvari datoteko configmap.yaml iz predlog in izpolni vrednost APP_EXTERNAL_DOMAIN z želeno vrednostjo glede na okolje, v katerem se začne posodobitev aplikacije. Ta spremenljivka je že nastavljena v vsebniku. Do nje je mogoče dostopati iz aplikacije, tako da bo vsako okolje aplikacije imelo drugačno vrednost za to spremenljivko.
Relativno nedavno se je podpora za K8S pojavila v Spring Cloudu, vključno z delom s configMaps: . Medtem ko se projekt aktivno razvija in se radikalno spreminja, ga ne moremo uporabiti v produkciji. Toda aktivno spremljamo njegovo stanje in ga uporabljamo v konfiguracijah DEV. Takoj ko se stabilizira, bomo prešli z uporabe okoljskih spremenljivk nanj.
Skupno
Tako je neprekinjeno uvajanje konfigurirano in deluje. Vse posodobitve se izvedejo z enim pritiskom na tipko. Dostava sprememb v okolju izdelka je avtomatska. In kar je pomembno, posodobitve ne ustavijo sistema.
Načrti za prihodnost: samodejna migracija baze podatkov
Razmišljali smo o nadgradnji baze podatkov in o možnosti vrnitve teh sprememb. Navsezadnje se hkrati izvajata dve različni različici aplikacije: stara teče, nova pa deluje. In staro bomo izklopili šele, ko bomo prepričani, da nova različica deluje. Selitev baze podatkov bi vam morala omogočiti delo z obema različicama aplikacije.
Zato ne moremo preprosto spremeniti imena stolpca ali drugih podatkov. Lahko pa ustvarimo nov stolpec, vanj kopiramo podatke iz starega stolpca in zapišemo sprožilce, ki jih bodo ob ažuriranju podatkov hkrati kopirali in ažurirali v drugem stolpcu. In po uspešni uvedbi nove različice aplikacije, po obdobju podpore po zagonu, bomo lahko izbrisali stari stolpec in sprožilec, ki je postal nepotreben.
Če nova različica aplikacije ne deluje pravilno, se lahko vrnemo na prejšnjo različico, vključno s prejšnjo različico baze podatkov. Skratka, naše spremembe vam bodo omogočile sočasno delo z več različicami aplikacije.
Načrtujemo avtomatizacijo migracije baz podatkov preko K8S job, ki jo bomo integrirali v proces CD. In to izkušnjo bomo zagotovo delili na Habréju.
Vir: www.habr.com