Wy by True Engineering hawwe in proses ynsteld foar trochgeande levering fan updates oan klantservers en wolle dizze ûnderfining diele.
Om te begjinnen hawwe wy in online systeem foar de klant ûntwikkele en ynset yn ús eigen Kubernetes-kluster. No is ús oplossing mei hege lading ferhuze nei it platfoarm fan 'e klant, wêrfoar wy in folslein automatysk proses foar trochgeande ynset hawwe ynsteld. Hjirmei fersnelle wy de tiid-to-merk - de levering fan feroaringen yn 'e produktomjouwing.
Yn dit artikel sille wy prate oer alle stadia fan it Continuous Deployment (CD) proses, as levering fan updates oan it platfoarm fan 'e klant:
- Hoe begjint dit proses?
- syngronisaasje mei it Git-repository fan de klant,
- gearstalling fan backend en frontend,
- automatyske ynset fan applikaasjes yn in testomjouwing,
- automatyske ynset nei Prod.
Wy sille de opsetdetails ûnderweis diele.
1. Start CD
Continuous Deployment begjint mei de ûntwikkelder dy't wizigingen triuwt nei de frijlittingstûke fan ús Git-repository.
Us applikaasje rint op in microservice-arsjitektuer en al syn komponinten wurde opslein yn ien repository. Hjirmei wurde alle mikrotsjinsten sammele en ynstalleare, sels as ien fan har is feroare.
Wy organisearre wurk fia ien repository om ferskate redenen:
- Gemak fan ûntwikkeling - de applikaasje ûntwikkelet aktyf, sadat jo mei alle koade tagelyk kinne wurkje.
- In inkele CI / CD pipeline dy't garandearret dat de applikaasje as ien systeem trochgiet alle testen en wurdt levere oan de klant syn produksje omjouwing.
- Wy eliminearje betizing yn ferzjes - wy hoege net te bewarjen in kaart fan microservice ferzjes en beskriuwe syn konfiguraasje foar eltse microservice yn Helm skripts.
2. Syngronisaasje mei it Git-repository fan 'e boarnekoade fan' e klant
Feroarings makke wurde automatysk syngronisearre mei de klant Git repository. Dêr wurdt de applikaasje-assemblage konfigureare, dy't wurdt lansearre nei it bywurkjen fan de branch, en ynset nei de fuortsetting. Beide prosessen komme yn har omjouwing út in Git-repository.
Wy kinne net direkt wurkje mei it repository fan de klant, om't wy ús eigen omjouwings nedich binne foar ûntwikkeling en testen. Wy brûke ús Git-repository foar dizze doelen - it is syngronisearre mei har Git-repository. Sadree't in ûntwikkelder feroaringen pleatst yn 'e passende tûke fan ús repository, stjoert GitLab dizze wizigingen fuortendaliks nei de klant.
Nei dit moatte jo de gearkomste dwaan. It bestiet út ferskate stadia: backend en frontend assembly, testen en levering oan produksje.
3. Sammelje de efterkant en frontend
It bouwen fan de backend en frontend binne twa parallelle taken dy't wurde útfierd yn it GitLab Runner-systeem. De orizjinele konfiguraasje fan 'e gearstalling sit yn itselde repository.
.
GitLab Runner nimt de koade fan it fereaske repository, sammelet it mei it Java-applikaasje build kommando en stjoert it nei it Docker-register. Hjir sammelje wy de backend en frontend, krije Docker-ôfbyldings, dy't wy yn in repository pleatse oan 'e kant fan' e klant. Om Docker-ôfbyldings te behearjen brûke wy .
Wy syngronisearje de ferzjes fan ús ôfbyldings mei de releaseferzje dy't sil wurde publisearre yn Docker. Foar in soepele operaasje hawwe wy ferskate oanpassingen makke:
1. Containers wurde net opnij boud tusken de testomjouwing en de produksjeomjouwing. Wy makken parametrisaasjes sadat deselde kontener koe wurkje mei alle ynstellings, omjouwingsfariabelen en tsjinsten sawol yn 'e testomjouwing as yn produksje sûnder opnij te bouwen.
2. Om in applikaasje fia Helm te aktualisearjen, moatte jo de ferzje opjaan. Wy bouwe de backend, frontend en aktualisearje de applikaasje - dit binne trije ferskillende taken, dus it is wichtich om oeral deselde ferzje fan 'e applikaasje te brûken. Foar dizze taak brûke wy gegevens út Git-skiednis, om't ús K8S-klusterkonfiguraasje en applikaasjes yn itselde Git-repository binne.
Wy krije de applikaasjeferzje fan 'e resultaten fan kommando-útfiering
git describe --tags --abbrev=7.
4. Automatyske ynset fan alle wizigingen yn 'e testomjouwing (UAT)
De folgjende stap yn dit bouskript is om it K8S-kluster automatysk te aktualisearjen. Dit bart op betingst dat de heule applikaasje is boud en alle artefakten binne publisearre yn it Docker Registry. Hjirnei begjint de testomjouwingsupdate.
De klusterupdate is begon te brûken . As, as gefolch, iets net gie neffens plan, Helm sil automatysk en selsstannich weromdraaie al syn feroarings. Syn wurk hoecht net kontrolearre te wurden.
Wy leverje de K8S-klusterkonfiguraasje tegearre mei de gearkomste. Dêrom is de folgjende stap om it te aktualisearjen: configMaps, ynset, tsjinsten, geheimen en alle oare K8S-konfiguraasjes dy't wy hawwe feroare.
Helm rint dan in RollOut-fernijing fan 'e applikaasje sels yn 'e testomjouwing. Foardat de applikaasje wurdt ynset nei produksje. Dit wurdt dien sadat brûkers de saaklike funksjes manuell kinne testen dy't wy yn 'e testomjouwing sette.
5. Automatyske ynset fan alle feroarings oan Prod
Om in fernijing yn 'e produksjeomjouwing yn te setten, moatte jo gewoan op ien knop yn GitLab klikke - en de konteners wurde daliks levere oan' e produksjeomjouwing.
Deselde applikaasje kin wurkje yn ferskate omjouwings-test en produksje-sûnder werbouwen. Wy brûke deselde artefakten sûnder wat yn 'e applikaasje te feroarjen, en wy sette de parameters ekstern yn.
Fleksibele parameterisaasje fan applikaasjeynstellingen hinget ôf fan 'e omjouwing wêryn de applikaasje sil wurde útfierd. Wy hawwe alle omjouwingsynstellingen ekstern ferpleatst: alles wurdt parameterisearre troch de K8S-konfiguraasje en Helm-parameters. As Helm in gearkomste ynset yn 'e testomjouwing, wurde de testynstellingen derop tapast, en de produktynstellingen wurde tapast op' e produksjeomjouwing.
It dreechste wie om alle brûkte tsjinsten en fariabelen te parameterisearjen dy't ôfhinklik binne fan 'e omjouwing, en oersette se yn omjouwingsfariabelen en beskriuwing-konfiguraasjes fan omjouwingsparameters foar Helm.
Applikaasje ynstellings brûke omjouwingsfariabelen. Harren wearden wurde ynsteld yn konteners mei help fan K8S configmap, dat is sjabloan mei Go-sjabloanen. Bygelyks, it ynstellen fan in omjouwingsfariabele foar de domeinnamme kin sa dien wurde:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env - dizze fariabele bewarret de namme fan 'e omjouwing (prod, poadium, UAT).
.Values.app.properties.app_external_domain - yn dizze fariabele sette wy it winske domein yn 'e .Values.yaml triem
By it bywurkjen fan in applikaasje makket Helm in configmap.yaml-bestân fan sjabloanen en foltôget de APP_EXTERNAL_DOMAIN-wearde mei de winske wearde ôfhinklik fan de omjouwing wêryn de applikaasje-fernijing begjint. Dizze fariabele is al ynsteld yn 'e kontener. It kin tagonklik wurde fanút de applikaasje, sadat elke applikaasje-omjouwing in oare wearde sil hawwe foar dizze fariabele.
Relatyf koartlyn ferskynde K8S-stipe yn Spring Cloud, ynklusyf wurkjen mei configMaps: . Wylst it projekt aktyf ûntwikkelet en radikaal feroaret, kinne wy it net brûke yn produksje. Mar wy kontrolearje har tastân aktyf en brûke it yn DEV-konfiguraasjes. Sadree't it stabilisearret, sille wy oerskeakelje fan it brûken fan omjouwingsfariabelen nei it.
Totaal
Dat, Continuous Deployment is konfigureare en wurket. Alle updates komme foar mei ien toetsoanslag. Levering fan feroarings oan 'e produktomjouwing is automatysk. En, wichtich, updates stopje it systeem net.
Takomstplannen: automatyske databankmigraasje
Wy tochten oer it opwurdearjen fan de databank en de mooglikheid om dizze wizigingen werom te rôljen. Ommers, twa ferskillende ferzjes fan de applikaasje rinne tagelyk: de âlde rint, en de nije is up. En wy sille de âlde allinich útsette as wy wis binne dat de nije ferzje wurket. De databankmigraasje soe jo moatte wurkje mei beide ferzjes fan 'e applikaasje.
Dêrom kinne wy de kolomnamme of oare gegevens net gewoan feroarje. Mar wy kinne in nije kolom oanmeitsje, gegevens fan 'e âlde kolom deryn kopiearje en triggers skriuwe dy't, by it bywurkjen fan gegevens, tagelyk kopiearje en aktualisearje yn in oare kolom. En nei de suksesfolle ynset fan 'e nije ferzje fan' e applikaasje, nei de stipeperioade nei de lansearring, sille wy de âlde kolom en de trigger kinne wiskje dy't net nedich is.
As de nije ferzje fan 'e applikaasje net goed wurket, kinne wy weromrolje nei de foarige ferzje, ynklusyf de foarige ferzje fan 'e databank. Koartsein, mei ús wizigingen kinne jo tagelyk wurkje mei ferskate ferzjes fan 'e applikaasje.
Wy binne fan plan in automate database migraasje fia K8S baan, yntegrearje it yn de CD proses. En wy sille dizze ûnderfining perfoarst diele op Habré.
Boarne: www.habr.com