Ne kemi vendosur një proces të vazhdueshëm të shpërndarjes së azhurnimeve në serverët e klientëve në True Engineering dhe dëshirojmë të ndajmë këtë përvojë.
Fillimisht, ne zhvilluam një sistem online për klientin dhe e vendosëm atë në klasterin tonë Kubernetes. Tani zgjidhja jonë me ngarkesë të lartë ka kaluar në platformën e klientit, për të cilën ne kemi konfiguruar një proces të plotë automatik të Continuous Deployment. Falë kësaj, ne e përshpejtuam kohën e shpërndarjes së azhurnimeve në mjedisin e produktit.
Në këtë artikull, ne do të flasim për të gjitha fazat e procesit të Continuous Deployment (CD) ose shpërndarjes së azhurnimeve në platformën e klientit:
- si fillon ky proces,
- synchronize me repositorin Git të klientit,
- ndërtime e backend dhe frontend,
- shpërndarja automatike e aplikacionit në mjedisin testues,
- shpërndarja automatike në Prod.
Gjatë procesit do të ndarim detajet e konfiguarit.
1. Fillimi i CD
Continuous Deployment fillon me faktin se zhvilluesi ngarkon ndryshimet në degën e lëshimit të repositorit tonë Git.
Aplikacioni ynë funksionon mbi një arkitekturë mikrosherish dhe të gjitha komponentët e tij ruhen në një repositor. Falë kësaj, të gjitha mikrosherit janë ndërtuar dhe instaluar, madje edhe nëse një prej tyre është ndryshuar.
Ne e organizuam punën përmes një repositor për disa arsye:
- Komoditeti i zhvillimit — aplikacioni aktivisht po zhvillohet, kështu që mund të punoni menjëherë me të gjithë kodin.
- Një pipeline i vetëm CI/CD, që garanton se aplikacioni si një sistem i vetëm kalon të gjitha testet dhe shpërndahet në mjedisin prodhues të klientit.
- Shkarkohet konfuzioni në versionet — ne nuk kemi nevojë të ruajmë një hartë versionesh të mikrosherive dhe të përshkruajmë konfigurimin për secilën mikrosherë në skriptet Helm.
2. Synchronizimi me repositorin Git të kodit burimor të klientit
Ndryshimet e bëra sinkronizohen automatikisht me repositorin Git të klientit. Aty është konfiguruar ndërtimi i aplikacionit, i cili aktivizohet pas përditësimit të degës, dhe shpërndarja në prodhimin. Të dy proceset ndodhin në mjedisin e tyre nga repositorin Git.
Ne mund të punojmë drejtpërdrejt me repositorin e klientit, pasi na duhen mjedise të veta për zhvillim dhe testim. Për këto qëllime, ne përdorim repozitorin tonë Git — ai është sinkronizuar me repozitorin e tyre Git. Sapo zhvilluesi publikon ndryshimet në degën përkatëse të repozitorios tonë, GitLab menjëherë i dërgon këto ndryshime klientit.
Pas kësaj, duhet të bëhet ndërtimi. Ai përbëhet nga disa etapa: ndërtimi i backend-it dhe frontend-it, testimi dhe dërgimi në prodhim.
3. Ndërtimi i backend-it dhe frontend-it
Ndërtimi i backend-it dhe frontend-it është dy detyra paralele që kryhen në sistemin GitLab Runner. Konfigurimi i ndërtimit origjinal ndodhet në këtë repozitor.
.
GitLab Runner merr kodin nga repozitori përkatës, me komandën e ndërtimit të aplikacionit Java, e ndërtuakan dhe e dërgon në Docker registry. Këtu ne ndërtojmë backend-in dhe frontend-in, marrim imazhe Docker, të cilat i ruajmë në repozitorin nga ana e klientit. Për menaxhimin e imazheve Docker përdorim .
Ne sinkronizojmë versionet e imazheve tona me versionin e lëshimit që do të publikohet në Docker. Për funksionimin e qetë, ne bëmë disa konfigurime:
1. Ndërmjet ambientit të testit dhe produktit, kontejnerët nuk rindërtohen. Ne kemi bërë parametrizime që njëjtë kontejner mund të funksionojë pa rindërtim me të gjitha konfigurimet, variablat e ambientit dhe shërbimet si në ambientin e testit ashtu edhe në prodhim.
2. Për përditësimin e aplikacionit përmes Helm, është e nevojshme të përcaktohet versioni i tij. Ndërtimi ynë i backend-it, frontend-it dhe përditësimi i aplikacionit është tre detyra të ndryshme, prandaj është e rëndësishme të përdorim gjithandej të njëjtin version të aplikacionit. Për këtë detyrë, ne përdorim të dhënat nga historia e Git, pasi konfigurimi i klasterit K8S dhe aplikacionit ndodhen në një repozitor Git.
Versionin e aplikacionit e marrim nga rezultatet e ekzekutimit të komandës
git describe --tags --abbrev=7.
4. Deployim automatik i të gjitha ndryshimeve në ambientin e testit (UAT)
Etapa e ardhshme në këtë skript ndërtimi është përditësimi automatik i klasterit K8S. Kjo ndodh nën kushtin që e gjithë aplikacioni të jetë ndërtuar dhe të gjithë artefaktet të jenë publikuar në Docker Registry. Pas kësaj, përgatitet përditësimi i ambientit të testit.
Përditësimi i klasterit fillohet me ndihmën e . Nëse diçka shkoi keq, Helm do ta kthente automatikisht çdo ndryshim. Nuk ka nevojë të kontrolloni punën e tij.
Ne furnizojmë së bashku me ndërtimin konfigurimin e klasterit K8S. Prandaj, hapi tjetër është përditësimi i tij: configMaps, deploymente, shërbime, sekrete dhe çdo konfigurim tjetër K8S që kemi ndërruar.
Pas kësaj, Helm niset përditësimin RollOut të aplikacionit në mjedisin e testimit. Para se aplikacioni të implementohet në prodhim. Kjo bëhet në mënyrë që përdoruesit të verifikojnë manualisht karakteristikat e biznesit që ne i kemi nxjerrë në mjedisin e testimit.
5. Implementimi automatik i të gjitha ndryshimeve në Prod
Për të implementuar përditësimin në mjedisin e prodhimit, duhet vetëm të shtypni një buton në GitLab — dhe kontejnerët menjëherë dërgohen në mjedisin produktiv.
I njëjti aplikacion mund të funksionojë pa ri-nxjerrje në mjedise të ndryshme — testim dhe prodhim. Ne përdorim të njëjtat artefakt, pa ndryshuar asgjë në aplikacion, ndërsa parametrat i përcaktojmë nga jashtë.
Parametrizimi fleksibël i cilësimeve të aplikacionit varet nga mjedisi në të cilin do të ekzekutohet ky aplikacion. Ne e kemi nxjerrë të gjitha cilësimet e mjediseve jashtë: gjithçka parametrizohet përmes konfigurimit K8S dhe parametrave të Helm. Kur Helm implementon ndërtimin në mjedisin e testimit, i aplikon parametrat testues, ndërsa në mjedisin produktiv — parametrat produktiv.
Më e vështira ishte parametrizimi i të gjithë shërbimeve dhe variablave të përdorura që varen nga mjedisi dhe t'i kthenim ato në variabla ambienti dhe përshkrimin-konfigurimin e parametrave për Helm.
Në parametrat e aplikacionit përdoren variabla ambienti. Vlerat e tyre përcaktohen në kontejnerët me anë të K8S configmap, i cili formohet me anë të shablloneve Go. Për shembull, përcaktimi i një variabli ambienti për emrin e domain-it mund të bëhet kështu:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – në këtë variabël ruhet emri i mjedisit (prod, stage, UAT).
.Values.app.properties.app_external_domain – në këtë variabël përcaktojmë domain-in e nevojshëm në skedarin .Values.yaml
Gjatë azhurnimit të aplikacionit, Helm krijon nga skedarët e shabllonit configmap.yaml dhe plotëson vlerën e APP_EXTERNAL_DOMAIN me vlerën e duhur në varësi të ambientit në të cilin startohet azhurnimi i aplikacionit. Kjo variabël vendoset tashmë në kontejner. Ajo është e qasshme nga aplikacioni, kështu që në çdo ambient aplikacioni do të ketë vlera të ndryshme për këtë variabël.
Në lidhje me të fundit, në Spring Cloud u shpall mbështetje për K8S, përfshirë punën me configMaps: . Ndërsa projekti po zhvillohet aktivisht dhe po ndryshon ndjeshëm, ne nuk mund ta përdorim atë në prodhim. Por e monitorojmë aktivisht gjendjen e tij dhe e përdorim në konfigurimet DEV. Sa herë që të stabilizohet, do të kalojmë nga përdorimi i variablave të ambientit në të.
Përveç kësaj
Pra, Continuous Deployment është konfiguruar dhe po funksionon. Të gjitha azhurnimet ndodhin me një klikim butoni. Dërgimi i ndryshimeve në ambientin prodhues është automatizuar. Dhe, çka është e rëndësishme, azhurnimet nuk ndalojnë punën e sistemit.
Planet për të ardhmen: migrimi automatizuar i bazës
Ne po mendojmë mbi përmirësimin e bazës dhe mundësinë për të kthyer këto ndryshime. Sepse në të njëjtën kohë funksionojnë dy versione të ndryshme të aplikacionit: e vjetra funksionon, ndërsa e reja ngrihet. Dhe e vjetra do ta fikim vetëm kur të sigurohemi se versiuni i ri punon. Migrimi i bazës duhet të lejojë punën me të dyja versionet e aplikacionit.
Prandaj nuk mund të ndryshojmë thjesht emrin e kolonës ose të dhëna të tjera. Por mund të krijojmë një kolonë të re, të kopjojmë të dhënat në të nga kolona e vjetër dhe të shkruajmë nxitës që do të kopjojnë dhe azhurnojnë ato në kolonën tjetër gjatë azhurnimit të të dhënave. Dhe pas një deploy të suksesshëm të versionit të ri të aplikacionit, pas një periudhe të mbështetjes pas lançimit, ne do të jemi në gjendje të fshijmë kolonën e vjetër dhe nxitësin që është bërë i padobishëm.
Nëse versioni i ri i aplikacionit nuk funksionon siç duhet, ne mund të kthehemi në versionin e mëparshëm, përfshirë versionin e mëparshëm të bazës. Me fjalë të tjera, ndryshimet tona do të lejojnë punën me disa versione të aplikacionit në të njëjtën kohë.
Ne planifikojmë të bëjmë automatizimin e migrimit të bazës përmes punës K8S, duke e integruar atë në procesin e CD. Dhe patjetër do të ndajmë këtë përvojë në Habra.
Burimi: habr.com
