Në True Engineering kemi vendosur procesin e dorëzimit të vazhdueshëm të azhurnimeve në serverat e klientëve dhe duam të ndajmë këtë përvojë.
PĂ«r tĂ« filluar, ne zhvilluam njĂ« sistem online pĂ«r klientin dhe e implementuam nĂ« klasĂ«n tonĂ« Kubernetes. Tani zgjidhja jonĂ« e ngarkesĂ«s sĂ« lartĂ« ka kaluar nĂ« platformĂ«n e klientit, pĂ«r tĂ« cilin ne vendosĂ«m njĂ« proces tĂ« plotĂ« automatik tĂ« Continuous Deployment. FalĂ« kĂ«saj, ne e pĂ«rshpejtuam kohĂ«n pĂ«r tĂ« dalĂ« nĂ« treg â dorĂ«zimin e ndryshimeve nĂ« ambientin produktiv.
Në këtë artikull, ne do të flasim për të gjitha fazat e procesit të Continuous Deployment (CD) ose dorëzimin e azhurnimeve në platformën e klientit:
- si fillon ky proces,
- synchronize with the clientâs Git repository,
- ndërtimi i backend-it dhe frontend-it,
- implementimi automatik i aplikacionit në mjedisin e testimit,
- implementimi automatik në Prod.
Gjatë procesit do të ndajmë detajet e konfigurimit.
1. Fillimi i CD
Continuous Deployment nisin kur zhvilluesi bën ndryshime në degën e lëshimit të Git-repozitorit tonë.
Aplikacioni ynë funksionon në bazë të një arkitekture mikroshërbimi dhe të gjitha komponentët e tij ruhen në një repozitor. Falë kësaj, të gjitha mikroshërbimet janë ndërtuar dhe instaluar, madje edhe nëse njëra prej tyre është ndryshuar.
Ne e organizuam punën nëpërmjet një repozitori për disa arsye:
- LehtĂ«sia e zhvillimit â aplikacioni Ă«shtĂ« nĂ« proces tĂ« aktiv zhvillimi, prandaj mund tĂ« punohet menjĂ«herĂ« me tĂ« gjithĂ« kodin.
- Një pipeline i vetme CI/CD, që garanton që aplikacioni si një sistem i vetëm kalon të gjitha testet dhe dorëzohet në ambientin prodhues të klientit.
- Eliminon ngatĂ«rresat me versionet â ne nuk kemi nevojĂ« tĂ« mbajmĂ« njĂ« hartĂ« tĂ« versioneve tĂ« mikroshĂ«rbimeve dhe tĂ« pĂ«rshkruajmĂ« konfigurimin pĂ«r secilin mikroshĂ«rbim nĂ« skriptet Helm.
2. Synchronizimi me Git-repozitorin e kodit burimor të klientit
Ndryshimet e bëra sinkronizohen automatikisht me Git-repozitorin e klientit. Atje është e vendosur ndërtimi i aplikacionit, i cili aktivizohet pas përditësimit të degës dhe implementimi në prodhimin. Të dy proceset ndodhin në ambientin e tyre nga Git-repozitori.
Ne nuk mund tĂ« punojmĂ« drejtpĂ«rdrejt me repozitorin e klientit, pasi na nevojiten ambientet tona pĂ«r zhvillim dhe testim. Ne pĂ«rdorim pĂ«r kĂ«to qĂ«llime repozitorin tonĂ« Git â ai Ă«shtĂ« sinkronizuar me repozitorin e tyre Git. Sa herĂ« qĂ« zhvilluesi ngarkon ndryshime nĂ« degĂ«n pĂ«rkatĂ«se tĂ« repozitorit tonĂ«, GitLab menjĂ«herĂ« dĂ«rgon kĂ«to ndryshime te klienti.
Pas kësaj duhet të bëhet ndërtimi. Ai përbëhet nga disa faza: ndërtimi i backend-it dhe frontend-it, testimi dhe dorëzimi 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 fillestar është në këtë repozitor.
.
GitLab Runner merr kodin nga repozitori i nevojshëm, me komandën e ndërtimit të aplikacionit Java, e ndërron dhe e dërgon atë në Docker registry. Këtu ne ndërtojmë backend-in dhe frontend-in, fitojmë imazhe të Docker-it, të cilat i ruajmë në repozitorin 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 një funksionim të qetë kemi bërë disa konfigurime:
1. Ndërmjet ambientit të testimit dhe produktit, enët nuk ri-ndërtohen. Ne kemi bërë parametërizime, që e njëjta enë mund të funksionojë pa ri-ndërtim me të gjitha konfigurimet, variablat e ambientit dhe shërbimet si në ambientin e testimit ashtu edhe në prodhim.
2. PĂ«r tĂ« pĂ«rditĂ«suar aplikacionin pĂ«rmes Helm duhet tĂ« specifikohet versioni i tij. NĂ« ndĂ«rtimin tonĂ« tĂ« backend-it, frontend-it dhe pĂ«rditĂ«simin e aplikacionit â janĂ« tri detyra tĂ« ndryshme, prandaj Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rdoret tĂ« njĂ«jtin version tĂ« aplikacionit kudo. PĂ«r kĂ«tĂ« detyrĂ« ne pĂ«rdorim tĂ« dhĂ«nat nga historia Git, pasi konfigurations e klasterit K8S dhe aplikacionit janĂ« nĂ« njĂ« Git-repozitor.
Ne e marrim versionin e aplikacionit nga rezultatet e ekzekutimit të komandës
git describe --tags --abbrev=7.
4. Implementimi automatik i të gjitha ndryshimeve në ambientin e testimit (UAT)
Faza e ardhshme në këtë skript ndërtimi kryen përditësimin automatik të klasterit K8S. Kjo ndodh për sa kohë që të gjithë aplikacioni është ndërtuar dhe të gjithë artefaktet janë publikuar në Docker Registry. Pas kësaj, aktivizohet përditësimi i ambientit të testimit.
Përditësimi i klasterit aktivizohet me . Nëse ndonjëherë diçka nuk shkon siç është parashikuar, Helm automatikisht dhe vetë do ta kthejë çdo ndryshim. Funksionimin e tij nuk ka nevojë ta kontrollosh.
Ne ofrojmë bashkë me montimin konfigurimin e klasterit K8S. Prandaj hapi tjetër është përditësimi i tij: configMaps, deployments, services, secrets dhe çdo konfigurim tjetër K8S që kemi ndryshuar.
Pas kësaj, Helm nis RollOut për të përditësuar vetë aplikacionin në ambientin e testimit. Para se aplikacioni të vendoset në prodhim. Kjo bëhet në mënyrë që përdoruesit të kontrollojnë manualisht karakteristikat biznesore që kemi vendosur në ambientin e testimit.
5. Zhvillimi automatik i të gjitha ndryshimeve në Prod
PĂ«r tĂ« zhvilluar pĂ«rditĂ«simin nĂ« ambientin produktiv, mbetet vetĂ«m tĂ« shtypni njĂ« buton nĂ« GitLab â dhe kontejnerĂ«t dĂ«rgohen menjĂ«herĂ« nĂ« ambientin produktiv.
I njĂ«jti aplikacion mund tĂ« funksionojĂ« pa riparim nĂ« ambiente tĂ« ndryshme â testuese dhe nĂ« prodhim. Ne pĂ«rdorim tĂ« njĂ«jtat artefakte, pa ndryshuar asgjĂ« nĂ« aplikacion, ndĂ«rsa parametrat i caktojmĂ« jashtĂ«.
Parametrizimi fleksibĂ«l i cilĂ«simeve tĂ« aplikacionit varet nga ambienti ku ky aplikacion do tĂ« ekzekutohet. Ne kemi nxjerrĂ« tĂ« gjitha cilĂ«simet e ambienteve jashtĂ«: gjithçka parametrizohet pĂ«rmes konfigurimit K8S dhe parametrave Helm. Kur Helm zhvillon montimin nĂ« ambientin e testimit, i aplikohen parametrat e testit, ndĂ«rsa nĂ« ambientin produktiv â parametrat produktiv.
Më e vështira ishte parametrizimi i të gjithë shërbimeve dhe variablave që varen nga ambienti dhe kalimi i tyre në variabla mjedisi dhe përshkrimin e parametrave të ambientit për Helm.
Në parametrat e aplikacionit përdoren variabla mjedisi. Vlerat e tyre caktohen në kontejnerë me anë të K8S configmap, e cila formohet duke përdorur shabllonet Go. Për shembull, caktimi i një variable mjedisi 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 ambientit (prod, stage, UAT).
.Values.app.properties.app_external_domain â nĂ« kĂ«tĂ« variabĂ«l ne nĂ« skedarin .Values.yaml caktuam domain-in e nevojshĂ«m.
Kur aplikacioni përditësohet, Helm krijon një skedar configmap.yaml nga shabllonet dhe plotëson vlerën e APP_EXTERNAL_DOMAIN me vlerën e duhur në varësi të ambientit, ku fillon përditësimi i aplikacionit. Kjo variabël vendoset tashmë në kontejner. Ajo është e aksesueshme nga aplikacioni, përkatësisht, në çdo ambient të aplikacionit do të ketë një vlerë të ndryshme të kësaj variabël.
Kohet e fundit, nĂ« Spring Cloud ka ardhur mbĂ«shtetje pĂ«r K8S, duke pĂ«rfshirĂ« punĂ«n me configMaps: . Deri tani projekti po zhvillohet aktivisht dhe ndryshon nĂ« mĂ«nyrĂ« drastike, nuk mund ta pĂ«rdorim nĂ« prodhim. Por ne e monitorojmĂ« aktivisht dhe e pĂ«rdorim nĂ« konfigurimet DEV. Sa herĂ« qĂ« tĂ« stabilizohet â do tĂ« kalojmĂ« nga pĂ«rdorimi i variablave mjedisi nĂ« tĂ«.
Në përfundim
Pra, Continuous Deployment është i vendosur dhe po funksionon. Të gjitha përditësimet ndodhin me një shtypje butoni. Dërgimi i ndryshimeve në ambientin produktiv është automatik. Dhe, çka është e rëndësishme, përditësimet nuk ndalojnë punën e sistemit.
Planet për të ardhmen: migrazione automatike e bazës
Ne kemi filluar të mendojmë për përmirësimin e bazës dhe mundësinë për të rikthyer këto ndryshime. Sepse dy versione të ndryshme të aplikacionit punojnë njëkohësisht: e vjetra punon, ndërsa e reja ngrihet. Dhe ne do ta mbyllim të vjetren vetëm kur të sigurohemi se versioni i ri funksionon. Migronimi i bazës duhet të lejojë punimin me të dy versionet e aplikacionit.
Prandaj, nuk mund ta ndryshojmë thjesht emrin e kolonës ose të dhëna të tjera. Por mund të krijojmë një kolonë të re, të kopjojmë në të dhënat nga kolona e vjetër dhe të shkruajmë trigger që do të kopjojnë dhe përditësojnë ato në kolonën tjetër gjatë përditësimit të të dhënave. Dhe pas një montimi të suksesshëm të versionit të ri të aplikacionit, pas një periudhe mbështetje pas lançimit, ne do të mund të fshijmë kolonën e vjetër dhe trigger-in e panevojshëm.
Nëse versioni i ri i aplikacionit nuk funksionon siç duhet, mund të rikthehemi në versionin e mëparshëm, përfshirë versionin e mëparshëm të bazës. Prandaj, ndryshimet tona do të mundësojnë punën në të njëjtën kohë me disa versione të aplikacionit.
Ne planifikojmë të bëjmë automatizimin e migracionit të bazës përmes K8S job, duke e integruar atë në procesin CD. Dhe do të ndajmë këtë përvojë në Habr.
Burimi: habr.com
