Eis Ëmsetzung vun der kontinuéierlecher Deployment op der Plattform vum Client

Mir bei True Engineering hunn e Prozess opgestallt fir eng kontinuéierlech Liwwerung vun Updates op Clientsserveren a wëllen dës Erfahrung deelen.

Fir unzefänken hu mir en Online System fir de Client entwéckelt an en an eisem eegene Kubernetes Cluster ofgesat. Elo ass eis High-Load-Léisung op d'Plattform vum Client geplënnert, fir déi mir e vollautomatesche Continuous Deployment Prozess ageriicht hunn. Dank dësem hu mir d'Zäit-ze-Maart beschleunegt - d'Liwwerung vun Ännerungen am Produktëmfeld.

An dësem Artikel schwätze mir iwwer all Etappe vum Continuous Deployment (CD) Prozess oder d'Liwwerung vun Updates op d'Plattform vum Client:

1. Wéi fänkt dëse Prozess un?
2. Synchroniséierung mam Client säi Git Repository,
3. Assemblée vum Backend a Frontend,
4. automatesch Uwendungsdeployment an engem Testëmfeld,
5. automatesch Deployment op Prod.

Mir deelen d'Installatiounsdetailer laanscht de Wee.

1. Start CD

Continuous Deployment fänkt mam Entwéckler un d'Verännerunge vun der Verëffentlechungszweig vun eisem Git Repository.

Eis Applikatioun leeft op enger Mikroservicearchitektur an all seng Komponenten ginn an engem Repository gelagert. Dank dësem ginn all Mikroservicer gesammelt an installéiert, och wann ee vun hinnen geännert huet.

Mir hunn Aarbecht duerch ee Repository aus verschiddene Grënn organiséiert:

• Einfachheet vun der Entwécklung - d'Applikatioun ass aktiv entwéckelt, sou datt Dir mat all de Code gläichzäiteg schaffe kënnt.
• Eng eenzeg CI / CD Pipeline déi garantéiert datt d'Applikatioun als eenzege System all Tester passéiert an an d'Produktiounsëmfeld vum Client geliwwert gëtt.
• Mir eliminéieren Duercherneen a Versiounen - mir mussen net eng Kaart vu Mikroservice Versiounen späicheren a seng Konfiguratioun fir all Mikroservice an Helm Scripten beschreiwen.

2. Synchroniséierung mam Git Repository vum Quellcode vum Client

Ännerungen gemaach ginn automatesch mat dem Client säi Git Repository synchroniséiert. Do ass d'Applikatiounsversammlung konfiguréiert, déi no der Aktualiséierung vun der Branche lancéiert gëtt, an d'Deployment op d'Fortsetzung. Béid Prozesser stamen aus hirem Ëmfeld aus engem Git Repository.

Mir kënnen net direkt mam Repository vum Client schaffen well mir eis eegen Ëmfeld fir Entwécklung an Testen brauchen. Mir benotzen eise Git Repository fir dës Zwecker - et ass mat hirem Git Repository synchroniséiert. Soubal en Entwéckler Ännerungen an der entspriechender Branche vun eisem Repository postt, dréckt GitLab dës Ännerungen direkt un de Client.

Duerno musst Dir d'Versammlung maachen. Et besteet aus e puer Etappen: Backend a Frontend Assemblée, Testen a Liwwerung fir d'Produktioun.

3. Assemblée Backend a Frontend

De Backend a Frontend bauen sinn zwou parallel Aufgaben déi am GitLab Runner System ausgefouert ginn. Seng originell Versammlungskonfiguratioun ass am selwechte Repository.

Tutorial fir e YAML Skript ze schreiwen fir am GitLab ze bauen.

GitLab Runner hëlt de Code aus dem erfuerderleche Repository, montéiert et mam Java Applikatioun Build Kommando a schéckt en an den Docker Registry. Hei versammele mir de Backend a Frontend, kréien Docker Biller, déi mir an e Repository op der Säit vum Client setzen. Fir Docker Biller ze managen benotze mir Gradle Plugin.

Mir synchroniséieren d'Versioune vun eise Biller mat der Verëffentlechungsversioun déi am Docker publizéiert gëtt. Fir glat Operatioun hu mir e puer Upassunge gemaach:

1. Container ginn net tëscht dem Testëmfeld an dem Produktiounsëmfeld nei opgebaut. Mir hunn Parametrisatioune gemaach fir datt dee selwechte Container mat all Astellungen, Ëmfeldvariablen a Servicer souwuel am Testëmfeld wéi och an der Produktioun ouni nei opzebauen kéint schaffen.

2. Fir eng Applikatioun via Helm ze aktualiséieren, musst Dir seng Versioun uginn. Mir bauen de Backend, de Frontend an aktualiséieren d'Applikatioun - dëst sinn dräi verschidden Aufgaben, also ass et wichteg déi selwecht Versioun vun der Applikatioun iwwerall ze benotzen. Fir dës Aufgab benotze mir Daten aus der Git Geschicht, well eis K8S Cluster Konfiguratioun an Uwendungen am selwechte Git Repository sinn.

Mir kréien d'Applikatioun Versioun vun de Kommando Ausféierung Resultater
git describe --tags --abbrev=7.

4. Automatesch Détachement vun all Ännerungen am Test Ëmfeld (UAT)

De nächste Schrëtt an dësem Build Skript ass automatesch de K8S Cluster ze aktualiséieren. Dëst geschitt virausgesat datt déi ganz Applikatioun gebaut gouf an all Artefakte am Docker Registry publizéiert goufen. Duerno fänkt d'Testëmfeldaktualiséierung un.

De Clusterupdate gëtt ugefaang ze benotzen Helm Update. Wann, als Resultat, eppes net no Plang gelaf ass, wäert Helm automatesch an onofhängeg all seng Ännerungen zréckrollen. Seng Aarbecht brauch net kontrolléiert ze ginn.

Mir liwweren d'K8S Cluster Konfiguratioun zesumme mat der Assemblée. Dofir ass de nächste Schrëtt et ze aktualiséieren: configMaps, Deployment, Servicer, Geheimnisser an all aner K8S Konfiguratiounen déi mir geännert hunn.

Helm leeft dann e RollOut Update vun der Applikatioun selwer am Testëmfeld. Ier d'Applikatioun op d'Produktioun ofgesat gëtt. Dëst gëtt gemaach fir datt d'Benotzer d'Geschäftsfeatures manuell testen, déi mir an d'Testëmfeld setzen.

5. Automatesch Détachement vun all Ännerungen ze Prod

Fir en Update an d'Produktiounsëmfeld z'installéieren, musst Dir just ee Knäppchen am GitLab klicken - an d'Container ginn direkt an d'Produktiounsëmfeld geliwwert.

Déi selwecht Applikatioun kann a verschiddenen Ëmfeld schaffen - Test a Produktioun - ouni nei opzebauen. Mir benotzen déiselwecht Artefakte ouni eppes an der Applikatioun z'änneren, a mir setzen d'Parameteren extern.

Flexibel Parameteriséierung vun Applikatiounsastellungen hänkt vun der Ëmwelt of an där d'Applikatioun ausgefouert gëtt. Mir hunn all d'Ëmweltastellungen extern geplënnert: alles gëtt parametriséiert duerch d'K8S Konfiguratioun an Helm Parameteren. Wann Helm eng Assemblée an d'Testëmfeld ofbaut, ginn d'Test-Astellunge drop ugewannt, an d'Produktastellunge ginn op d'Produktiounsëmfeld applizéiert.

Déi schwieregst Saach war all benotzt Servicer a Variabelen ze parameteriséieren, déi vun der Ëmwelt ofhängeg sinn, an iwwersetze se an Ëmweltvariablen a Beschreiwungskonfiguratiounen vun Ëmweltparameter fir Helm.

Applikatioun Astellunge benotzen Ëmfeld Variablen. Hir Wäerter ginn a Container gesat mat K8S Configmap, déi mat Go Template geschaaft gëtt. Zum Beispill, eng Ëmfeldvariabel op den Domain Numm ze setzen kann esou gemaach ginn:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env - dës Variabel späichert den Numm vun der Ëmwelt (Prod, Bühn, UAT).
.Values.app.properties.app_external_domain - an dëser Variabel setzen mir de gewënschte Domain an der .Values.yaml Datei

Beim Aktualiséierung vun enger Applikatioun erstellt Helm eng configmap.yaml-Datei aus Schablounen a fëllt den APP_EXTERNAL_DOMAIN-Wäert mat dem gewënschten Wäert jee no der Ëmgéigend, an där d'Aktualiséierung vun der Applikatioun ufänkt. Dës Variabel ass schonn am Container gesat. Et kann aus der Applikatioun zougänglech sinn, sou datt all Applikatiounsëmfeld en anere Wäert fir dës Variabel huet.

Relativ viru kuerzem ass K8S Ënnerstëtzung a Spring Cloud erschéngt, inklusiv mat configMaps schaffen: Fréijoer Cloud Kubernetes. Während de Projet aktiv entwéckelt a radikal verännert, kënne mir et net an der Produktioun benotzen. Awer mir iwwerwaachen aktiv säin Zoustand a benotzen se an DEV Konfiguratiounen. Soubal et stabiliséiert, wäerte mir vun der Benotzung vun Ëmfeldvariablen wiesselen.

Total

Also, Continuous Deployment ass konfiguréiert a funktionnéiert. All Updates geschéien mat engem Tastatur. D'Liwwerung vun Ännerungen am Produktëmfeld ass automatesch. An, Wichteg, Updates stoppen de System net.

Zukunft Pläng: automatesch Datebank Migratioun

Mir hunn iwwer d'Upgrade vun der Datebank geduecht an d'Méiglechkeet dës Ännerungen zréckzekréien. No allem lafen zwou verschidde Versioune vun der Applikatioun zur selwechter Zäit: déi al leeft, an déi nei ass op. A mir wäerten déi al nëmmen ausschalten wa mir sécher sinn datt déi nei Versioun funktionnéiert. D'Datebankmigratioun sollt Iech erlaben mat béide Versioune vun der Applikatioun ze schaffen.

Dofir kënne mir net einfach de Kolonnennumm oder aner Donnéeën änneren. Awer mir kënnen eng nei Kolonn erstellen, Daten aus der aler Kolonn an et kopéieren an Trigger schreiwen, déi, wann Dir d'Donnéeën aktualiséiert, gläichzäiteg kopéieren an aktualiséieren se an enger anerer Kolonn. An no der erfollegräicher Installatioun vun der neier Versioun vun der Applikatioun, no der Post-Start-Ënnerstëtzungsperiod, kënne mir déi al Kolonn an den Ausléiser läschen, deen onnéideg ass.

Wann déi nei Versioun vun der Applikatioun net richteg funktionnéiert, kënne mir op déi viregt Versioun zréckrollen, och déi fréier Versioun vun der Datebank. Kuerz gesot, eis Ännerungen erlaben Iech gläichzäiteg mat verschiddene Versioune vun der Applikatioun ze schaffen.

Mir plangen eng Datebank Migratioun via K8S Aarbecht automatiséieren, et an der CD Prozess intégréieren. A mir wäerten dës Erfahrung definitiv op Habré deelen.

Source: will.com