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
