Ne në True Engineering kemi krijuar një proces për dërgimin e vazhdueshëm të përditësimeve në serverët e klientëve dhe duam ta ndajmë këtë përvojë.
Si fillim, ne zhvilluam një sistem në internet për klientin dhe e vendosëm atë në grupin tonë Kubernetes. Tani zgjidhja jonë me ngarkesë të lartë ka kaluar në platformën e klientit, për të cilën ne kemi krijuar një proces plotësisht automatik të vendosjes së vazhdueshme. Falë kësaj, ne përshpejtuam kohën e hyrjes në treg - shpërndarjen e ndryshimeve në mjedisin e produktit.
Në këtë artikull do të flasim për të gjitha fazat e procesit të vendosjes së vazhdueshme (CD) ose dërgimit të përditësimeve në platformën e klientit:
- Si nis ky proces?
- sinkronizimi me depon e Git të klientit,
- montimi i pjesëve të pasme dhe të përparme,
- vendosja automatike e aplikacionit në një mjedis testimi,
- vendosja automatike në Prod.
Ne do të ndajmë detajet e konfigurimit gjatë rrugës.
1. Filloni CD-në
Vendosja e vazhdueshme fillon me shtytjen e ndryshimeve nga zhvilluesi në degën e lëshimit të depove tona Git.
Aplikacioni ynë funksionon në një arkitekturë mikroservice dhe të gjithë përbërësit e tij ruhen në një depo. Falë kësaj, të gjitha mikroshërbimet mblidhen dhe instalohen, edhe nëse njëri prej tyre ka ndryshuar.
Ne organizuam punën përmes një depoje për disa arsye:
- Lehtësia e zhvillimit - aplikacioni po zhvillohet në mënyrë aktive, kështu që ju mund të punoni me të gjithë kodin menjëherë.
- Një tubacion i vetëm CI/CD që garanton që aplikacioni si një sistem i vetëm i kalon të gjitha testet dhe i dorëzohet mjedisit të prodhimit të klientit.
- Ne eliminojmë konfuzionin në versione - nuk kemi pse të ruajmë një hartë të versioneve të mikroshërbimit dhe të përshkruajmë konfigurimin e tij për çdo mikroshërbim në skriptet Helm.
2. Sinkronizimi me depo Git të kodit burimor të klientit
Ndryshimet e bëra sinkronizohen automatikisht me depon e Git të klientit. Aty konfigurohet asambleja e aplikacionit, e cila niset pas përditësimit të degës dhe vendosjes në vazhdim. Të dy proceset e kanë origjinën në mjedisin e tyre nga një depo Git.
Ne nuk mund të punojmë drejtpërdrejt me depon e klientit sepse na duhen mjediset tona për zhvillim dhe testim. Ne përdorim depon tonë të Git për këto qëllime - ajo është e sinkronizuar me depon e tyre Git. Sapo një zhvillues poston ndryshime në degën përkatëse të depove tona, GitLab menjëherë i shtyn këto ndryshime te klienti.
Pas kësaj ju duhet të bëni montimin. Ai përbëhet nga disa faza: montimi i pjesës së pasme dhe të përparme, testimi dhe dërgimi në prodhim.
3. Montimi i pjesës së pasme dhe frontendit
Ndërtimi i backend dhe frontend janë dy detyra paralele që kryhen në sistemin GitLab Runner. Konfigurimi i tij origjinal i montimit ndodhet në të njëjtin depo.
.
GitLab Runner merr kodin nga depoja e kërkuar, e mbledh atë me komandën e ndërtimit të aplikacionit Java dhe e dërgon në regjistrin Docker. Këtu ne mbledhim fundin dhe frontin, marrim imazhe Docker, të cilat i vendosim në një depo në anën e klientit. Për të menaxhuar imazhet Docker ne përdorim .
Ne sinkronizojmë versionet e imazheve tona me versionin e lëshimit që do të publikohet në Docker. Për funksionim të qetë, ne kemi bërë disa rregullime:
1. Kontejnerët nuk rindërtohen midis mjedisit të testimit dhe mjedisit të prodhimit. Ne bëmë parametrizime në mënyrë që i njëjti kontejner të mund të funksiononte me të gjitha cilësimet, variablat e mjedisit dhe shërbimet si në mjedisin e testimit ashtu edhe në prodhim pa rindërtim.
2. Për të përditësuar një aplikacion nëpërmjet Helm, duhet të specifikoni versionin e tij. Ne ndërtojmë backend, frontend dhe përditësojmë aplikacionin - këto janë tre detyra të ndryshme, kështu që është e rëndësishme të përdorni të njëjtin version të aplikacionit kudo. Për këtë detyrë, ne përdorim të dhëna nga historia e Git, pasi konfigurimi dhe aplikacionet tona të grupit K8S janë në të njëjtin depo Git.
Ne marrim versionin e aplikacionit nga rezultatet e ekzekutimit të komandës
git describe --tags --abbrev=7.
4. Vendosja automatike e të gjitha ndryshimeve në mjedisin e testimit (UAT)
Hapi tjetër në këtë skript ndërtimi është përditësimi automatik i grupit K8S. Kjo ndodh me kusht që i gjithë aplikacioni të jetë ndërtuar dhe të gjitha artefaktet të jenë publikuar në Regjistrin Docker. Pas kësaj, fillon përditësimi i mjedisit të testimit.
Përditësimi i grupit ka filluar të përdoret . Nëse, si rezultat, diçka nuk shkoi sipas planit, Helm do të rikthejë automatikisht dhe në mënyrë të pavarur të gjitha ndryshimet e tij. Puna e tij nuk ka nevojë të kontrollohet.
Ne furnizojmë konfigurimin e grupit K8S së bashku me montimin. Prandaj, hapi tjetër është përditësimi i tij: konfigurimet, vendosjet, shërbimet, sekretet dhe çdo konfigurim tjetër K8S që kemi ndryshuar.
Helm më pas ekzekuton një përditësim RollOut të vetë aplikacionit në mjedisin e testimit. Përpara se aplikacioni të vendoset në prodhim. Kjo është bërë në mënyrë që përdoruesit të mund të testojnë manualisht veçoritë e biznesit që vendosim në mjedisin e testimit.
5. Vendosja automatike e të gjitha ndryshimeve në Prod
Për të vendosur një përditësim në mjedisin e prodhimit, thjesht duhet të klikoni një buton në GitLab - dhe kontejnerët dorëzohen menjëherë në mjedisin e prodhimit.
I njëjti aplikacion mund të funksionojë në mjedise të ndryshme - test dhe prodhim - pa rindërtim. Ne përdorim të njëjtat objekte pa ndryshuar asgjë në aplikacion dhe i vendosim parametrat nga jashtë.
Parametizimi fleksibël i cilësimeve të aplikacionit varet nga mjedisi në të cilin do të ekzekutohet aplikacioni. Ne kemi zhvendosur të gjitha cilësimet e mjedisit nga jashtë: gjithçka është e parametrizuar përmes konfigurimit K8S dhe parametrave Helm. Kur Helm vendos një asamble në mjedisin e provës, cilësimet e provës aplikohen në të dhe cilësimet e produktit aplikohen në mjedisin e prodhimit.
Gjëja më e vështirë ishte parametrizimi i të gjitha shërbimeve dhe variablave të përdorura që varen nga mjedisi, dhe përkthimi i tyre në variabla mjedisore dhe përshkrim-konfigurime të parametrave të mjedisit për Helm.
Cilësimet e aplikacionit përdorin variabla të mjedisit. Vlerat e tyre vendosen në kontejnerë duke përdorur hartën e konfigurimit K8S, e cila është modeluar duke përdorur shabllonet Go. Për shembull, vendosja e një ndryshoreje mjedisi në emrin e domenit mund të bëhet si kjo:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Vlerat.globale.env – kjo variabël ruan emrin e mjedisit (prod, stad, UAT).
.Vlerat.app.properties.app_external_domain – në këtë variabël vendosim domenin e dëshiruar në skedarin .Values.yaml
Kur përditëson një aplikacion, Helm krijon një skedar configmap.yaml nga shabllonet dhe mbush vlerën APP_EXTERNAL_DOMAIN me vlerën e dëshiruar në varësi të mjedisit në të cilin fillon përditësimi i aplikacionit. Kjo ndryshore është vendosur tashmë në kontejner. Mund të aksesohet nga aplikacioni, kështu që çdo mjedis aplikacioni do të ketë një vlerë të ndryshme për këtë variabël.
Relativisht kohët e fundit, mbështetja K8S u shfaq në Spring Cloud, duke përfshirë punën me configMaps: . Ndërsa projekti po zhvillohet në mënyrë aktive dhe po ndryshon rrënjësisht, ne nuk mund ta përdorim atë në prodhim. Por ne monitorojmë në mënyrë aktive gjendjen e tij dhe e përdorim atë në konfigurimet e DEV. Sapo të stabilizohet, ne do të kalojmë nga përdorimi i variablave të mjedisit në të.
Në total
Pra, Vendosja e vazhdueshme është konfiguruar dhe funksionon. Të gjitha përditësimet ndodhin me një goditje tasti. Dorëzimi i ndryshimeve në mjedisin e produktit është automatik. Dhe, më e rëndësishmja, përditësimet nuk e ndalojnë sistemin.
Planet e ardhshme: migrimi automatik i bazës së të dhënave
Ne menduam për përmirësimin e bazës së të dhënave dhe mundësinë e rikthimit të këtyre ndryshimeve. Në fund të fundit, dy versione të ndryshme të aplikacionit po ekzekutohen në të njëjtën kohë: i vjetri po funksionon dhe i riu është në funksion. Dhe ne do ta fikim të vjetrën vetëm kur të jemi të sigurt se versioni i ri funksionon. Migrimi i bazës së të dhënave duhet t'ju lejojë të punoni me të dy versionet e aplikacionit.
Prandaj, ne nuk mund të ndryshojmë thjesht emrin e kolonës ose të dhëna të tjera. Por ne mund të krijojmë një kolonë të re, të kopjojmë të dhënat nga kolona e vjetër në të dhe të shkruajmë nxitës që, kur përditësohen të dhënat, do t'i kopjojnë dhe përditësojnë njëkohësisht në një kolonë tjetër. Dhe pas vendosjes me sukses të versionit të ri të aplikacionit, pas periudhës së mbështetjes pas nisjes, ne do të jemi në gjendje të fshijmë kolonën e vjetër dhe këmbëzën që është bërë i panevojshëm.
Nëse versioni i ri i aplikacionit nuk funksionon siç duhet, ne mund të kthehemi në versionin e mëparshëm, duke përfshirë versionin e mëparshëm të bazës së të dhënave. Me pak fjalë, ndryshimet tona do t'ju lejojnë të punoni njëkohësisht me disa versione të aplikacionit.
Ne planifikojmë të automatizojmë migrimin e bazës së të dhënave përmes punës K8S, duke e integruar atë në procesin e CD-së. Dhe ne patjetër do ta ndajmë këtë përvojë në Habré.
Burimi: www.habr.com