True Engineering-n bezeroen zerbitzariei eguneraketak etengabe emateko prozesu bat ezarri dugu eta esperientzia hau partekatu nahi dugu.
Hasteko, bezeroarentzako lineako sistema bat garatu genuen eta gure Kubernetes klusterrean zabaldu genuen. Orain gure karga handiko irtenbidea bezeroaren plataformara eraman da, eta horretarako Etengabeko Inplementazio prozesu guztiz automatikoa ezarri dugu. Horri esker, merkaturatzeko denbora azkartu dugu - produktuaren ingurunean aldaketak ematea.
Artikulu honetan Etengabeko Inplementazioaren (CD) prozesuaren edo eguneratzeak bezeroaren plataformaren entregaren fase guztiei buruz hitz egingo dugu:
- Nola hasten da prozesu hau?
- bezeroaren Git biltegiarekin sinkronizatzea,
- backend eta frontend muntaketa,
- aplikazio automatikoa inplementatzea proba-ingurunean,
- inplementazio automatikoa Prod.
Konfigurazio xehetasunak partekatuko ditugu bidean.
1. Hasi CDa
Etengabeko inplementazioa garatzaileak gure Git biltegiaren bertsio-adarrean aldaketak bultzatzen dituenetik hasten da.
Gure aplikazioa mikrozerbitzuen arkitektura batean exekutatzen da eta bere osagai guztiak biltegi batean gordetzen dira. Horri esker, mikrozerbitzu guztiak bildu eta instalatzen dira, nahiz eta horietako bat aldatu.
Lanak biltegi baten bidez antolatu genituen hainbat arrazoirengatik:
- Garatzeko erraztasuna - aplikazioa aktiboki garatzen ari da, beraz, kode guztiekin batera lan egin dezakezu.
- CI/CD kanalizazio bakarra, aplikazioak sistema bakar gisa proba guztiak gainditzen dituela eta bezeroaren ekoizpen-ingurunera entregatzen dela bermatzen duena.
- Bertsioetan nahasmena ezabatzen dugu; ez dugu mikrozerbitzuen bertsioen maparik gorde beharrik eta mikrozerbitzu bakoitzaren konfigurazioa Helm scriptetan deskribatu beharrik.
2. Bezeroaren iturburu-kodearen Git biltegiarekin sinkronizatzea
Egindako aldaketak automatikoki sinkronizatzen dira bezeroaren Git biltegiarekin. Bertan aplikazioaren muntaia konfiguratzen da, adarra eguneratu ondoren abiarazten dena, eta jarraipenera hedatzen dena. Bi prozesuek beren ingurunean dute jatorria Git biltegi batetik.
Ezin dugu bezeroaren biltegiarekin zuzenean lan egin, gure inguruneak behar ditugulako garatzeko eta probak egiteko. Helburu horietarako gure Git biltegia erabiltzen dugu - haien Git biltegiarekin sinkronizatuta dago. Garatzaile batek gure biltegiaren adar egokian aldaketak argitaratu bezain laster, GitLab-ek berehala bultzatzen dizkio aldaketa hauek bezeroari.
Horren ostean muntaia egin behar duzu. Hainbat fase ditu: backend eta frontend muntaketa, probak eta ekoizpenera entrega.
3. Backend-a eta frontend-a muntatzea
Backend-a eta frontend-a eraikitzea GitLab Runner sisteman egiten diren bi zeregin paralelo dira. Bere jatorrizko muntaia-konfigurazioa biltegi berean dago.
.
GitLab Runner-ek kodea behar den biltegitik hartzen du, Java aplikazioa eraikitzeko komandoarekin muntatzen du eta Docker erregistrora bidaltzen du. Hemen backend-a eta frontend-a muntatzen dugu, Docker-en irudiak lortzen ditugu, bezeroaren aldean biltegi batean jartzen ditugunak. Erabiltzen ditugun Docker irudiak kudeatzeko .
Gure irudien bertsioak Docker-en argitaratuko den bertsioarekin sinkronizatzen ditugu. Funtzionamendu ona izateko hainbat doikuntza egin ditugu:
1. Ontziak ez dira berreraikitzen proba-ingurunearen eta ekoizpen-ingurunearen artean. Parametrizazioak egin genituen, edukiontzi berak ezarpen, ingurune-aldagai eta zerbitzu guztiekin lan egin zezan bai proba-ingurunean bai ekoizpenean berreraiki gabe.
2. Helm bidez aplikazio bat eguneratzeko, bere bertsioa zehaztu behar duzu. Backend-a, frontend-a eta aplikazioa eguneratzen ditugu - hiru zeregin desberdinak dira, beraz, garrantzitsua da aplikazioaren bertsio bera nonahi erabiltzea. Zeregin honetarako, Git historiako datuak erabiltzen ditugu, gure K8S klusterraren konfigurazioa eta aplikazioak Git biltegi berean baitaude.
Aplikazioaren bertsioa komandoen exekuzio emaitzetatik lortzen dugu
git describe --tags --abbrev=7.
4. Proba-ingurunean (UAT) aldaketa guztiak automatikoki zabaltzea
Eraikitze script honen hurrengo urratsa K8S klusterra automatikoki eguneratzea da. Hau gertatzen da aplikazio osoa eraiki eta artefaktu guztiak Docker Erregistroan argitaratu badira. Horren ondoren, proba-ingurunearen eguneratzea hasten da.
Kluster eguneratzea erabiltzen hasi da . Ondorioz, zerbait planaren arabera joan ez bada, Helm-ek automatikoki eta modu independentean atzera egingo ditu bere aldaketa guztiak. Bere lana ez da kontrolatu behar.
K8S kluster konfigurazioa hornitzen dugu muntaiarekin batera. Hori dela eta, hurrengo urratsa eguneratzea da: konfigMaps, inplementazioak, zerbitzuak, sekretuak eta aldatu ditugun beste edozein K8S konfigurazioak.
Helm-ek aplikazioaren beraren RollOut eguneraketa bat exekutatzen du proba-ingurunean. Aplikazioa ekoizpenera zabaldu aurretik. Hau egiten da erabiltzaileek eskuz proba ditzaten proba-ingurunean jartzen ditugun negozio-eginbideak.
5. Prod-en aldaketa guztiak automatikoki zabaltzea
Ekoizpen-ingurunean eguneratze bat zabaltzeko, GitLab-eko botoi bat sakatu behar duzu eta edukiontziak berehala entregatuko dira ekoizpen-ingurunera.
Aplikazio berak ingurune desberdinetan lan egin dezake βprobak eta ekoizpenakβ berreraiki gabe. Artefaktu berdinak erabiltzen ditugu aplikazioan ezer aldatu gabe, eta parametroak kanpotik ezartzen ditugu.
Aplikazioaren ezarpenen parametrizazio malgua aplikazioa exekutatuko den ingurunearen araberakoa da. Ingurunearen ezarpen guztiak kanpotik eraman ditugu: dena K8S konfigurazioaren eta Helm parametroen bidez parametrizatzen da. Helm-ek muntaia bat proba-ingurunean zabaltzen duenean, proba-ezarpenak aplikatzen zaizkio eta produktuaren ezarpenak ekoizpen-inguruneari aplikatzen zaizkio.
Zailena ingurunearen araberakoak diren erabilitako zerbitzu eta aldagai guztiak parametrizatzea izan zen, eta Helm-erako ingurune-aldagaietan eta ingurune-parametroen deskribapen-konfigurazioetan itzultzea.
Aplikazioaren ezarpenek ingurune-aldagaiak erabiltzen dituzte. Haien balioak edukiontzietan ezartzen dira K8S konfigmap erabiliz, Go txantiloiak erabiliz moldatzen dena. Adibidez, domeinu-izenari ingurune-aldagai bat ezartzea honela egin daiteke:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Balioak.global.env β aldagai honek ingurunearen izena gordetzen du (prod, stage, UAT).
.Balioak.app.properties.app_external_domain β aldagai honetan nahi den domeinua ezarri dugu .Values.yaml fitxategian
Aplikazio bat eguneratzean, Helm-ek configmap.yaml fitxategi bat sortzen du txantiloietatik eta APP_EXTERNAL_DOMAIN balioa nahi duzun balioarekin betetzen du aplikazioaren eguneraketa hasten den ingurunearen arabera. Aldagai hau dagoeneko ezarrita dago edukiontzian. Aplikaziotik atzitu daiteke, beraz, aplikazio-ingurune bakoitzak balio ezberdin bat izango du aldagai honentzat.
Duela gutxi, K8S laguntza agertu zen Spring Cloud-en, configMaps-ekin egindako lana barne: . Proiektua aktiboki garatzen eta errotik aldatzen ari den bitartean, ezin dugu produkzioan erabili. Baina bere egoera aktiboki kontrolatzen dugu eta DEV konfigurazioetan erabiltzen dugu. Egonkortu bezain laster, ingurune-aldagaiak erabiltzetik horretara pasatuko gara.
Guztira
Beraz, Etengabeko Hedapena konfiguratuta eta funtzionatzen du. Eguneratze guztiak tekla sakatuz egiten dira. Aldaketak produktuaren ingurunean bidaltzea automatikoa da. Eta, batez ere, eguneratzeek ez dute sistema geldiarazten.
Etorkizuneko planak: datu-baseen migrazio automatikoa
Datu-basea berritzea eta aldaketa horiek atzera botatzeko aukera pentsatu genuen. Azken finean, aplikazioaren bi bertsio ezberdin exekutatzen ari dira aldi berean: zaharra exekutatzen ari da, eta berria martxan. Eta bertsio berria funtzionatzen duela ziur gaudenean bakarrik itzaliko dugu zaharra. Datu-basearen migrazioak aplikazioaren bi bertsioekin lan egiteko aukera eman beharko luke.
Hori dela eta, ezin dugu zutabearen izena edo beste datu batzuk aldatu. Baina zutabe berri bat sor dezakegu, zutabe zaharreko datuak bertan kopiatu eta abiarazleak idatzi ditzakegu, datuak eguneratzean, aldi berean beste zutabe batean kopiatu eta eguneratuko dituztenak. Eta aplikazioaren bertsio berria arrakastaz zabaldu ondoren, abiaraztearen ondorengo laguntza-epearen ondoren, zutabe zaharra eta beharrezkoa ez den abiarazlea ezabatu ahal izango ditugu.
Aplikazioaren bertsio berriak behar bezala funtzionatzen ez badu, aurreko bertsiora itzuli dezakegu, datu-basearen aurreko bertsiora barne. Laburbilduz, gure aldaketek aplikazioaren hainbat bertsiorekin aldi berean lan egiteko aukera emango dizute.
K8S lanaren bidez datu-baseen migrazioa automatizatzeko asmoa dugu, CD prozesuan integratuz. Eta zalantzarik gabe esperientzia hau HabrΓ©-n partekatuko dugu.
Iturria: www.habr.com