Sot do të flasim për parimet dhe modelet GitOps, si dhe për mënyrat se si këto modele realizohen në platformën OpenShift. Një udhëzues interaktiv mbi këtë temë është i disponueshëm. .
Nëse e thjeshtojmë, GitOps është një grup metodash praktike për të përdorur kërkesa tërheqëse (pull requests) në Git për të menaxhuar konfiguracionet e infrastrukturës dhe aplikacioneve. Repository Git në kuadër të GitOps konsiderohet si një burim i vetëm i informacionit për gjendjen e sistemit, dhe çdo ndryshim në këtë gjendje tregohet plotësisht dhe mund të auditohet.
Ideja e gjurmimit të ndryshimeve në GitOps nuk është në të vërtetë e re, ky qasje është përdorur për një kohë të gjatë dhe gjerë në punën me kodin burimor të aplikacioneve. GitOps thjesht implementon funksione të ngjashme (kontrolli i rishikimit, kërkesat e tërheqjes, etj.) në menaxhimin e konfiguracioneve të infrastrukturës dhe aplikacioneve dhe ofron avantazhe të ngjashme, ashtu si në rastin e menaxhimit të kodit burimor.
Për GitOps nuk ka ndonjë definicion akademik ose një grup rregullash të miratuara, por vetëm një grup parimesh mbi të cilat ndërtohet kjo praktikë:
- Përshkrimi deklarativ i sistemit ruhet në një repository Git (konfigurations, monitorimi, etj).
- Ndryshimet e gjendjes realizohen përmes kërkesave tërheqëse.
- Gjendja e sistemeve në punë i përputhet të dhënave në repository përmes kërkesave të shtytjes (push requests) në Git.
Parimet e GitOps
- Përkufizimet e sistemeve përshkruhen si kod burimor.
Konfigurimi i sistemeve konsiderohet si kod, prandaj mund të ruhet dhe të versionohet automatikisht në një repository Git, i cili shërben si burimi i vetëm i së vërtetës. Ky qasje lejon një kalim të lehtë (rollout) dhe rikthim (rollback) të ndryshimeve në sisteme.
- Gjendja e dëshiruar dhe konfigurimi i sistemeve përcaktohen dhe versionohen në Git.
Duke ruajtur dhe versionuar në Git gjendjen e dëshiruar të sistemeve, ne fitojmë mundësinë për të kaluara dhe rikthyer lehtësisht ndryshimet në sisteme dhe aplikacione. Gjithashtu, mund të përdorim mekanizmat e sigurisë së Git për të kontrolluar pronësinë e kodit dhe për të vërtetuar autentikën e tij.
- Ndryshimet në konfiguracione mund të aplikohen automatikisht përmes kërkesave tërheqëse.
Duke përdorimi i pull-request-eve të Git, ne mund të menaxhojmë lehtësisht se si zëvendësimet aplikohen në konfigurimet e repository-t. Për shembull, ato mund të dorëzohen për shqyrtim nga anëtarët e tjerë të ekipit ose të kalojnë përmes testeve CI.
Dhe në të njëjtën kohë, nuk ka nevojë të shpërndajmë privilegje administrarësh nga njëra anë në tjetrën. Për të kryer commit-in e ndryshimeve në konfigurim, përdoruesit kanë nevojë vetëm për privilegje përkatëse në repository-n Git ku ruhen këto konfigurime.
- Zgjidhja e problemit të driftit të pakontrolluar të konfigurimeve
Kur gjendja e dëshiruar e sistemit ruhet në repository-n Git, ne duhet vetëm të gjejmë softuerin që kontrollon nëse gjendja aktuale e sistemit përputhet me gjendjen e saj të dëshiruar. Nëse kjo nuk është e vërtetë, ky softuer duhet - në varësi të konfigurimeve - ose ta zgjidhë vetë mosmiratimin, ose të na njoftojë për driftin e konfigurimeve.
Modelet GitOps për OpenShift
Rikthyesi i Burimeve në Cluster
Sipas kësaj modeli, në cluster ka një kontrollues që është përgjegjës për krahasimin e burimeve Kubernetes (skedarëve YAML) në repository-n Git me burimet e vërteta të cluster-it. Kur konstatohen ndërprerje, kontrolluesi dërgon njoftimet dhe, ndoshta, merr masa për të eliminuar mosmiratimet. Ky model GitOps përdoret në Anthos Config Management dhe Weaveworks Flux.
Rikthyesi i Burimeve të Jashtme (Push)
Ky model mund tĂ« konsiderohet si njĂ« lloj i mĂ«parshĂ«m, kur kemi njĂ« ose mĂ« shumĂ« kontrollues qĂ« janĂ« pĂ«rgjegjĂ«s pĂ«r sinkronizimin e burimeve nĂ« çiftet "repository Git - cluster Kubernetes". Ndryshimi kĂ«tu Ă«shtĂ« se nĂ« çdo cluster tĂ« menaxhuar nuk ka nevojĂ« tĂ« ketĂ« njĂ« kontrollues tĂ« veçantĂ«. Ăiftet "Git - cluster k8s" shpesh pĂ«rshkruhen si pĂ«rshkrime CRD (custom resources definition), tĂ« cilat mund tĂ« pĂ«rshkruajnĂ« se si kontrolluesi duhet tĂ« kryejĂ« sinkronizimin. NĂ« kuadĂ«r tĂ« kĂ«tij modeli, kontrolluesit krahason repository-n Git tĂ« caktuar nĂ« CRD me burimet e cluster-it Kubernetes qĂ« gjithashtu janĂ« tĂ« pĂ«rcaktuara nĂ« CRD, dhe kryejnĂ« veprimet pĂ«rkatĂ«se sipas rezultateve tĂ« krahasimit. NĂ« veçanti, ky model GitOps pĂ«rdoret nĂ« ArgoCD.
GitOps në platformën OpenShift
Administrimi i Infrastrukturës Multi-cluster të Kubernetes
Me përhapjen e Kubernetes dhe rritjen e popullaritetit të strategjive multi-cloud dhe përpunimeve periferike (edge computing), rritet gjithashtu numri mesatar i klasterëve OpenShift për çdo klient.
Për shembull, gjatë përdorimit të kompjuterëve periferikë, klasterët e një klienti mund të implementohen me qindra dhe madje mijëra. Si rezultat, ai është i detyruar të menaxhojë disa klasterë OpenShift të pavarur ose të koordinuar në cloud-in publik dhe on-premise.
Në të njëjtën kohë, duhet të zgjidhen një sërë problemesh, përfshirë:
- Të kontrollohet që klasterët janë në gjendje identike (konfigurimet, monitorimi, ruajtjet etj.).
- Të rinovohet (ose të rikuperohet) klasteri sipas një gjendje të njohur.
- Të krijohen klasterë të rinj sipas një gjendje të njohur.
- Të aplikohet ndryshime në disa klasterë OpenShift.
- Të kthehen ndryshimet në disa klasterë OpenShift.
- Të lidheshin konfiguratat e modeluara me mjedise të ndryshme.
Konfigurimet e aplikacioneve.
Gjatë ciklit të jetës, aplikacionet shpesh kalojnë përmes një zinxhiri klasterësh (dev, stage etj.), para se të arrijnë në klasterin e prodhimit. Për më tepër, për shkak të kërkesave për disponueshmëri dhe shkallëzim, klientët shpesh implementojnë aplikacione në disa klasterë on-premise ose në disa rajone të platformës publike të cloud-it.
Në të njëjtën kohë, duhet të zgjidhen detyra të mëposhtme:
- Të sigurohet lëvizja e aplikacioneve (binarët, konfigurimet etj.) midis klasterëve (dev, stage etj.).
- Të aplikohen ndryshimet në aplikacione (binarët, konfigurimet etj.) në disa klasterë OpenShift.
- Të kthehen ndryshimet në aplikacione në nivelin e gjendjes së njohur të mëparshme.
Scenarët e përdorimit të OpenShift GitOps.
1. Aplikimi i ndryshimeve nga repo Git.
Administratori i klasterit mund tĂ« ruajĂ« konfigurimet e klasterit OpenShift nĂ« njĂ« repo Git dhe tâi aplikojĂ« ato automatikisht, pĂ«r tĂ« krijuar klasterĂ« tĂ« rinj dhe tâi sjellĂ« ata nĂ« njĂ« gjendje identike me atĂ« tĂ« njohur, qĂ« Ă«shtĂ« ruajtur nĂ« repo Git.
2. Sinkronizimi me Menaxherin e Sekreteve.
Administratori gjithashtu do tĂ« ketĂ« nevojĂ« pĂ«r mundĂ«sinĂ« e sinkronizimit tĂ« objektĂ«ve sekrete tĂ« OpenShift me programet pĂ«rkatĂ«se si Vault, pĂ«r tâi menaxhuar ato me mjete tĂ« specializuara pĂ«r kĂ«tĂ« qĂ«llim.
3. Kontrolli i ndryshimeve të konfigurimeve.
Administratori do tĂ« jetĂ« fort dakord, nĂ«se OpenShift GitOps do tĂ« zbulojĂ« dhe paralajmĂ«rojĂ« pĂ«r dallimet midis konfigurimeve reale dhe atyre qĂ« janĂ« caktuar nĂ« repo, qĂ« tĂ« pĂ«r tâu reaguar shpejt ndaj ndryshimeve.
4. Njoftimet për driftimin e konfigurimeve
Këto janë të dobishme kur administratori dëshiron të jetë në dijeni të shpejtë të rasteve të driftimit të konfigurimeve, për të marrë masa të shpejta vetë.
5. Sinkronizimi manual i konfigurimeve gjatë driftimit
Lejon administratorin të sinkronizojë klasterin OpenShift me repositorin Git në rast të driftimit të konfigurimeve, për të rikthyer shpejt klasterin në një gjendje të njohur më parë.
6. Sinkronizimi automatik i konfigurimeve gjatë driftimit
Administratori gjithashtu mund të konfiguronte klasterin OpenShift për sinkronizim automatik me repositorin kur detectohet drift, që konfigurimi i klasterit gjithmonë të përputhet me konfigurimet në Git.
7. Klastere tĂ« shumta â njĂ« repositor
Administratorët mund të ruajnë konfigurime të disa klastereve të ndryshme OpenShift në një repositor Git dhe t'i aplikojnë ato sipas nevojës.
8. Hierarkia e konfigurimeve të klasterëve (trashëgimia)
Administratori mund tĂ« pĂ«rcaktojĂ« njĂ« hierarki konfigurimesh klasteri nĂ« repositor (stage, prodhimi, portofoli i aplikacioneve, etj., me trashĂ«gim). Me fjalĂ« tĂ« tjera, ai mund tĂ« pĂ«rcaktojĂ« si duhet tĂ« aplikohen konfigurimet â nĂ« njĂ« ose nĂ« disa klastere.
PĂ«r shembull, nĂ«se administratori pĂ«rcakton nĂ« repositorin Git hierarkinĂ« "Klastere Prodhimi (prod) â Klasteret e SistemĂ«s X â Klastere Prodhimi tĂ« SistemĂ«s X", atĂ«herĂ« klastereve tĂ« prodhimit tĂ« sistemit X do t'u aplikohen pĂ«rzierja e konfigurimeve tĂ« mĂ«poshtme:
- Konfigurimet që janë të përbashkëta për të gjitha klasterët e prodhimit.
- Konfigurimet për klasterin e sistemit X.
- Konfigurimet për klasterin e prodhimit të sistemit X.
9. Ćambuj dhe ripĂ«rcaktimi i konfigurimeve
Administratori mund të ripërcaktojë një grup të konfigurimeve dhe vlerave të trashëguara, për shembull, për të bërë një konfigurim më të saktë për klastere të caktuara ku do të aplikohen.
10. Inkuadrime dhe përjashtime selektive për konfigurimet, konfigurimet e aplikacioneve
Administratori mund të përcaktojë kushte për aplikimin ose mosaplikimin e disa konfigurimeve në klastere me karakteristika të caktuara.
11. MbĂ«shtetje pĂ«r ĆablonĂ«t
Zhvilluesit do të kenë nevojë për mundësinë për të zgjedhur si do të përcaktohen burimet e aplikacionit (Helm Chart, yaml të pastër Kubernetes, etj.), për të përdorur formatin më të përshtatshëm për çdo aplikacion specifik.
Instrumentet GitOps në platformën OpenShift
ArgoCD
ArgoCD implementon modelin External Resource Reconcile dhe ofron një UI të centralizuar për orkestrimin e marrëdhënieve mes klasterëve dhe Git-repos në skemën "një ndaj shumë". Një nga disavantazhet e këtij programi është pamundësia për të menaxhuar aplikacionet kur ArgoCD nuk funksionon.
Flux
Flux implementon modelin On-Cluster Resource Reconcile, dhe, si pasojë, këtu nuk ka menaxhim të centralizuar të repositorit të definicioneve, që është pika e dobët. Nga ana tjetër, pikërisht për shkak të mungesës së centralizimit, mundësia për të menaxhuar aplikacionet ruhet edhe kur një klaster dështon.
Instalimi i ArgoCD në OpenShift
ArgoCD ofron një ndërfaqe të shkëlqyer të komandës dhe një konsolë në web, prandaj këtu nuk do të shqyrtojmë Flux dhe alternativa të tjera.
Për të shpërndarë ArgoCD në platformën OpenShift 4, ndiqni këto hapa si administrator klasteri:
Shpërndarja e komponenteve të ArgoCD në platformën OpenShift
# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')Modifikimi i ArgoCD Server, që të mund të shihet nga OpenShift Route
# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=RedirectShpërndarja e ArgoCD Cli Tool
# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocdNdryshimi i fjalëkalimit të administratorit të ArgoCD Server
# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password Pas përfundimit të këtyre hapave, mund të punoni me ArgoCD Server përmes konsolës në web ArgoCD WebUI ose mjetit të komandës ArgoCD Cli.
GitOps â k nunca nuk Ă«shtĂ« vonĂ«
"Treni iku" â kĂ«shtu thonĂ« pĂ«r situatĂ«n kur mundĂ«sia pĂ«r tĂ« bĂ«rĂ« diçka Ă«shtĂ« humbur. NĂ« rastin e OpenShift, dĂ«shira pĂ«r tĂ« filluar menjĂ«herĂ« tĂ« pĂ«rdorni kĂ«tĂ« platformĂ« tĂ« re tĂ« shkĂ«lqyer shpesh krijon njĂ« situatĂ« tĂ« tillĂ« me menaxhimin dhe mirĂ«mbajtjen e rrugĂ«ve, deploymenteve dhe objekteve tĂ« tjera tĂ« OpenShift. Por a Ă«shtĂ« shpeshherĂ« mundĂ«sia tĂ«rĂ«sisht e humbur?
Duke vazhduar serinë e artikujve rreth , sot do të tregojmë se si ta transformojmë një aplikacion të shpikur manual dhe burimet e tij në një proces, ku gjithçka menaxhohet nga mjeti GitOps. Për këtë, fillimisht do të shpërndajmë manualisht aplikacionin httpd. Në skenën më poshtë tregohet si krijojmë një hapësirë emri, një deployment dhe një shërbim, dhe pastaj e bëjmë expose për këtë shërbim për të krijuar një rrugë.
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-appKështu, kemi një aplikacion të krijuar manualisht. Tani duhet ta kalojmë nën menaxhimin e GitOps pa humbur disponueshmërinë. Në përmbledhje, kjo bën kështu:
- Krijojmë një Git-repository për kodin.
- Eksportojmë objektet tona aktuale dhe i ngarkojmë ato në depo Git.
- Zgjidhim dhe zbatojmë mjetin GitOps.
- Shtojmë repositorin tonë në këtë mjet.
- Përcaktojmë aplikacionin në mjetin tonë GitOps.
- Kryejmë një testim të aplikacionit, duke përdorur mjetin GitOps.
- Sinkronizojmë objektet duke përdorur mjetin GitOps.
- Aktivizojmë pastrimin dhe autosinkronizimin e objekteve.
Siç u theksua mĂ« parĂ«, nĂ« GitOps ka njĂ« dhe vetĂ«m njĂ« burim informacioni pĂ«r tĂ« gjitha objektet nĂ« (tĂ«) Kubernetes â repositori Git. MĂ« pas, ne dalim nga supozimi se organizata juaj tashmĂ« po pĂ«rdor njĂ« repositor Git. Ai mund tĂ« jetĂ« publik ose privat, por domosdoshmĂ«risht duhet tĂ« jetĂ« i aksesueshĂ«m pĂ«r klasterĂ«t Kubernetes. Ky mund tĂ« jetĂ« i njĂ«jti repositor si pĂ«r kodin e aplikacioneve, ose njĂ« repositor i veçantĂ« i krijuar posaçërisht pĂ«r deploymet. NĂ« repositorin Ă«shtĂ« e rekomandueshme tĂ« ketĂ« leje strikte, pasi aty do tĂ« ruhen objektet sekret, rrugĂ«t dhe gjĂ«ra tĂ« tjera tĂ« ndjeshme pĂ«r sigurinĂ«.
Në shembullin tonë do të krijojmë një repositor publik të ri në GitHub. Mund ta quajmë si të duam, ne e përdorim emrin blogpost.
Nëse skedarët YAML të objekteve nuk ishin ruajtur lokal ose në Git, do të duhet të përdorim binerët oc ose kubectl. Në screenshotin më poshtë, po kërkojmë YAML për hapësirën tonë të emrave, deployment, shërbimin dhe rrugën. Para kësaj, kemi klonuar repositorin e sapokrijuar dhe kaluam në të me komandën cd.
oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yamlTani e korrigjojmë skedarin deployment.yaml për të hequr nga ai fushën që Argo CD nuk mund ta sinkronizojë.
sed -i '/sgeneration: .*'/d' deployment.yamlPër më tepër, duhet të ndryshojmë rrugën. Së pari do të përcaktojmë një variabël shumë-rreshtëshe, dhe pastaj do ta zëvendësojmë ingress: null me përmbajtjen e kësaj variabël.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlKështu, me skedarët e kemi bërë, tani mbetet t'i ruajmë ato në repositorin Git. Pas kësaj, ky repositor bëhet burimi i vetëm i informacionit, dhe çdo ndryshim manual i objekteve duhet të jetë rigorozisht i ndaluar.
git commit -am 'initial commit of objects'
git push origin masterMë pas, ne do të supozojmë se ArgoCD është tashmë e instaluar (si ta bëni këtë - shihni të kaluarën ). Prandaj, do të shtojmë në Argo CD repo e krijuar nga ne, e cila përmban kodin e aplikacionit nga shembulli ynë. Thjesht sigurohuni që të tregoni pikërisht atë repo që e krijuat më parë.
argocd repo add https://github.com/cooktheryan/blogpostTani po krijojmë aplikacionin. Aplikacioni përcakton vlerat që mjetet GitOps të kuptojnë se cili repo dhe rrugët do të përdoren, cili OpenShift është i nevojshëm për të menaxhuar objektet, si dhe cili degë specifike e repo është e nevojshme, dhe nëse duhet të zbatohet automatikisht sinkronizimi i burimeve.
argocd app create --project default
--name simple-app --repo https://github.com/cooktheryan/blogpost.git
--path . --dest-server https://kubernetes.default.svc
--dest-namespace simple-app --revision master --sync-policy none Pasi aplikacioni është vendosur në Argo CD, ky mjet fillon të kontrollojë objektet e instaluara për përputhshmërinë me përkufizimet në repo. Në shembullin tonë, sinkronizimi automatik dhe pastrimi janë të çaktivizuara, prandaj elementët nuk do të ndryshojnë për momentin. Kini parasysh se në ndërfaqen e Argo CD aplikacioni ynë do të ketë statusin "Jashtë Sinkronizimit", pasi nuk ka label-etiketën që vendos ArgoCD.
Pikërisht për këtë arsye, kur pak më vonë të fillojmë sinkronizimin, riinstalimi i objekteve nuk do të bëhet.
Tani do të kryejmë një provë për të siguruar që në skedarët tanë nuk ka gabime.
argocd app sync simple-app --dry-runNëse nuk ka gabime, atëherë mund të kalojmë në sinkronizim.
argocd app sync simple-appPasi të ekzekutojmë komandën argocd get mbi aplikacionin tonë, ne duhet të shohim se statusi i aplikacionit ka ndryshuar në Shëndetshëm ose të Sinkronizuar. Kjo do të thotë se të gjitha burimet në repo Git tani përputhen me ato burime që janë tashmë të instaluara.
argocd app get simple-app
Name: simple-app
Project: default
Server: https://kubernetes.default.svc
Namespace: simple-app
URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo: https://github.com/cooktheryan/blogpost.git
Target: master
Path: .
Sync Policy:
Sync Status: Synced to master (60e1678)
Health Status: Healthy
... Tani, mund ta aktivizoni sinkronizimin automatik dhe pastrimin, për të garantuar që asgjë të mos krijohet manualisht dhe që çdo herë që një objekt krijohet ose azhurnohet në repo, do të bëhet instalimi.
argocd app set simple-app --sync-policy automated --auto-prune Pra ndaj, ne e kemi çuar me sukses aplikacionin nën menaxhimin e GitOps, i cili fillimisht nuk përdorte asnjëherë GitOps.
Burimi: habr.com
