ProHoster > Blog > Administrazioa > OpenShift-erako GitOps-en sarrera

OpenShift-erako GitOps-en sarrera

Gaur GitOps-en printzipioei eta ereduei buruz hitz egingo dugu, baita eredu hauek OpenShift plataforman nola inplementatzen diren ere. Gai honi buruzko gida interaktibo bat dago eskuragarri по ссылке.

OpenShift-erako GitOps-en sarrera

Laburbilduz, GitOps Git pull eskaerak azpiegiturak eta aplikazioen konfigurazioak kudeatzeko praktika multzo bat da. GitOps-en Git biltegia sistemaren egoerari buruzko informazio iturri bakar gisa tratatzen da, eta egoera horretan egiten diren aldaketak guztiz trazagarriak eta ikuskagarriak dira.

GitOps-en aldaketen jarraipenaren ideia ez da inola ere berria; ikuspegi hau aspalditik ia unibertsalki erabiltzen da aplikazioen iturburu-kodearekin lan egiten denean. GitOps-ek antzeko ezaugarriak (berrikuspenak, tira-eskaerak, etiketak, etab.) ezartzen ditu azpiegituren eta aplikazioen konfigurazioen kudeaketan eta iturburu-kodearen kudeaketaren kasuan bezalako abantailak eskaintzen ditu.

Ez dago GitOps-en definizio akademikorik edo arau-multzo onarturik, praktika hau eraikitzen den printzipio multzo bat baizik:

  • Sistemaren deskribapen deklaratiboa Git biltegian gordetzen da (konfigurazioak, jarraipena, etab.).
  • Estatu-aldaketak pull-eskaeren bidez egiten dira.
  • Exekutatzen diren sistemen egoera biltegiko datuekin bat egiten da Git push eskaerak erabiliz.

GitOps printzipioak

  • Sistemaren definizioak iturburu-kode gisa deskribatzen dira

Sistemen konfigurazioa kode gisa tratatzen da, beraz, Git biltegi batean gorde eta automatikoki bertsionatu daiteke, egiaren iturri bakar gisa balio duena. Planteamendu honek errazten du sisteman aldaketak zabaltzea eta atzera botatzea.

  • Sistemen egoera eta konfigurazioa Git-en ezarri eta bertsionatu egiten dira

Git-en nahi den sistemen egoera gordez eta bertsioatuz, sistema eta aplikazioetako aldaketak erraz zabaldu eta atzera bota ditzakegu. Git-en segurtasun-mekanismoak ere erabil ditzakegu kodearen jabetza kontrolatzeko eta bere benetakotasuna egiaztatzeko.

  • Konfigurazio-aldaketak automatikoki aplika daitezke pull-eskaeren bidez

Git pull eskaerak erabiliz, erraz kontrola dezakegu aldaketak biltegiko konfigurazioetan nola aplikatzen diren. Adibidez, beste taldekide batzuei eman diezaiekete berrikusteko edo CI proben bidez, etab.

Eta, aldi berean, ez dago administrazio-eskumenak ezkerretik eta eskuinera banatu beharrik. Konfigurazio-aldaketak egiteko, erabiltzaileek baimen egokiak soilik behar dituzte konfigurazio horiek gordetzen diren Git biltegian.

  • Konfigurazioen kontrolik gabeko noraezaren arazoa konpontzea

Sistemaren nahi den egoera Git biltegi batean gordeta dagoenean, sistemaren uneko egoera bere nahi den egoera bat datorrela bermatuko duen softwarea aurkitzea besterik ez dugu egin behar. Hori horrela ez bada, software honek, ezarpenen arabera, desadostasuna bere kabuz desagerrarazi beharko luke, edo konfigurazio-noraezaz jakinarazi beharko liguke.

OpenShift-erako GitOps ereduak

Kluster-eko baliabideen berreziklatzailea

Eredu honen arabera, klusterrak Git biltegiko Kubernetes baliabideak (YAML fitxategiak) klusterreko baliabide errealekin alderatzeaz arduratzen den kontroladore bat du. Desadostasunak hautematen badira, kontrolatzaileak jakinarazpenak bidaltzen ditu eta agian neurriak hartuko ditu desadostasunak zuzentzeko. GitOps eredu hau Anthos Config Management eta Weaveworks Flux-en erabiltzen da.

OpenShift-erako GitOps-en sarrera

Kanpoko baliabideen berreziklatzailea (Push)

Eredu hau aurrekoaren aldakuntzatzat har daiteke, “Git biltegia - Kubernetes kluster” bikoteetan baliabideak sinkronizatzeko ardura duten kontrolatzaile bat edo gehiago ditugunean. Hemen dagoen aldea da kudeatutako kluster bakoitzak ez duela zertan bere kontrolatzaile bereizia izan. Git - k8s kluster bikoteak CRD (baliabideen definizio pertsonalizatuak) gisa definitu ohi dira, kontrolagailuak sinkronizazioa nola egin behar duen deskriba dezake. Eredu honen barruan, kontrolatzaileek CRDn zehaztutako Git biltegia konparatzen dute Kubernetes klusterreko baliabideekin, CRDn ere zehaztuta daudenak, eta konparazioaren emaitzetan oinarritutako ekintza egokiak egiten dituzte. Bereziki, GitOps eredu hau ArgoCD-n erabiltzen da.

OpenShift-erako GitOps-en sarrera

GitOps OpenShift plataforman

Kubernetes kluster anitzeko azpiegituraren administrazioa

Kubernetes-en hedapenarekin eta hodei anitzeko estrategien eta edge computing-en ospe handiagoarekin, bezero bakoitzeko OpenShift klusterren batez besteko kopurua ere handitzen ari da.

Adibidez, edge computing erabiltzean, bezero baten klusterrak ehunka edo are milaka inplementa daitezke. Ondorioz, hainbat OpenShift kluster independente edo koordinatu kudeatzera behartuta dago hodei publikoan eta lokalean.

Kasu honetan, arazo asko konpondu behar dira, bereziki:

  • Kontrolatu klusterrak egoera berdinean daudela (konfigurazioak, monitorizazioa, biltegiratzea, etab.)
  • Birsortu (edo leheneratu) klusterrak egoera ezagun batean oinarrituta.
  • Sortu kluster berriak egoera ezagun batean oinarrituta.
  • Egin aldaketak OpenShift kluster anitzetan.
  • Atzera egin aldaketak OpenShift kluster anitzetan.
  • Lotu txantiloietako konfigurazioak ingurune desberdinetara.

Aplikazioen konfigurazioak

Bizi-zikloan zehar, aplikazioak sarritan kluster kate batetik igarotzen dira (garapena, etapa, etab.) produkzio-kluster batean amaitu aurretik. Horrez gain, erabilgarritasun- eta eskalagarritasun-eskakizunak direla eta, bezeroek sarritan zabaltzen dituzte aplikazioak hainbat kluster lokaletan edo hodei publikoko plataforma bateko hainbat eskualdetan.

Kasu honetan, honako zeregin hauek konpondu behar dira:

  • Ziurtatu aplikazioen mugimendua (bitarrak, konfigurazioak, etab.) klusterren artean (dev, stage, etab.).
  • Aplikatu aldaketak aplikazioetan (bitarrak, konfigurazioak, etab.) OpenShift hainbat klusteretan.
  • Atzera itzuli aplikazioetan egindako aldaketak aurreko egoera ezagun batera.

OpenShift GitOps erabilera kasuak

1. Git biltegitik aldaketak aplikatzea

Kluster-administratzaile batek OpenShift kluster konfigurazioak Git biltegi batean gorde ditzake eta automatikoki aplika ditzake kluster berriak esfortzurik gabe sortzeko eta Git biltegian gordetako egoera ezagunaren egoera berdinera eramateko.

2. Secret Manager-ekin sinkronizatzea

Administratzaileak OpenShift objektu sekretuak Vault bezalako software egokiarekin sinkronizatzeko aukeraz ere baliatuko du, horretarako bereziki sortutako tresnak erabiliz kudeatzeko.

3. Derivaren konfigurazioen kontrola

Administratzaileak aldekoa izango da OpenShift GitOps-ek berak konfigurazio errealen eta biltegian zehaztutakoen arteko desadostasunak identifikatzen eta ohartarazten baditu, noraeza azkar erantzuteko.

4. Konfigurazioaren noraezari buruzko jakinarazpenak

Erabilgarriak dira administratzaileak konfigurazio-noraeza kasuak azkar ezagutu nahi dituenean, bere kabuz neurri egokiak azkar hartzeko.

5. Konfigurazioen eskuz sinkronizatzea noraezean

Administratzaileari OpenShift klusterra Git biltegiarekin sinkronizatzeko aukera ematen dio konfigurazio-noraeza gertatuz gero, klusterra lehengo egoera ezagun batera azkar itzultzeko.

6.Konfigurazioen auto-sinkronizazioa noraezean

Administratzaileak OpenShift klusterra ere konfigura dezake biltegiarekin automatikoki sinkronizatzeko desbideratze bat hautematen denean, kluster konfigurazioa beti Git-eko konfigurazioekin bat etor dadin.

7. Hainbat kluster - biltegi bat

Administratzaileak hainbat OpenShift klusterren konfigurazioak gorde ditzake Git biltegi batean eta behar bezala aplika ditzake.

8. Kluster-konfigurazioen hierarkia (herentzia)

Administratzaileak kluster konfigurazioen hierarkia ezar dezake biltegian (etapa, produktua, aplikazioen zorroa, etab. herentziarekin). Beste era batera esanda, konfigurazioak kluster bati edo gehiagori aplikatu behar zaizkion zehaztu dezake.

Adibidez, administratzaile batek Git biltegian "Produkzio klusterrak (produkzioa) → Sistema X klusterrak → X sistemaren ekoizpen-klusterrak" hierarkia ezartzen badu, konfigurazio hauen konbinazio bat aplikatuko da X sistemaren ekoizpen-klusteri:

  • Produkzio-kluster guztietan komunak diren konfigurazioak.
  • System X klusterraren konfigurazioak.
  • X sistemaren ekoizpen-klusterrako konfigurazioak.

9. Txantiloiak eta konfigurazio gainidatziak

Administratzaileak heredatutako konfigurazio multzo bat eta haien balioak gainidatzi ditzake, adibidez, aplikatuko zaizkien kluster zehatzetarako konfigurazioa doitzeko.

10. Sartu eta baztertu selektiboa konfigurazioetarako, aplikazioen konfigurazioetarako

Administratzaileak ezaugarri jakin batzuk dituzten klusterrei konfigurazio batzuk aplikatzeko edo ez aplikatzeko baldintzak ezar ditzake.

11. Txantiloiaren euskarria

Garatzaileek aplikazioen baliabideak nola definituko diren aukeratzeko aukera izango dute (Helm Chart, Kubernetes yaml hutsa, etab.), aplikazio zehatz bakoitzerako formatu egokiena erabiltzeko.

GitOps tresnak OpenShift plataforman

ArgoCD

ArgoCDk External Resource Reconcile eredua inplementatzen du eta klusterren eta Git biltegien arteko bat-bateko harremanak orkestratzeko UI zentralizatu bat eskaintzen du. Programa honen desabantailen artean ArgoCD funtzionatzen ez denean aplikazioak kudeatzeko ezintasuna daude.

Webgune ofiziala

Flux

Flux-ek On-Cluster Resource Reconcile eredua inplementatzen du eta, ondorioz, ez dago definizio-biltegiaren kudeaketa zentralizaturik, puntu ahula baita. Bestalde, hain zuzen ere, zentralizazio faltagatik, aplikazioak kudeatzeko gaitasuna mantentzen da kluster batek huts egiten badu ere.

Webgune ofiziala

ArgoCD instalatzen OpenShift-en

ArgoCD-k komando lerroko interfaze eta web kontsola bikaina eskaintzen du, beraz, ez ditugu Flux eta beste alternatiba batzuk landuko hemen.

ArgoCD OpenShift 4 plataforman zabaltzeko, jarraitu urrats hauek kluster administratzaile gisa:

ArgoCD osagaiak OpenShift plataforman zabaltzea

# 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}')

ArgoCD zerbitzariaren hobekuntza, OpenShift Route-k ikusi ahal izateko

# 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=Redirect

ArgoCD Cli tresna zabaltzea

# 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/argocd

ArgoCD zerbitzariaren administratzailearen pasahitza aldatzea

# 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

Urrats hauek amaitu ondoren, ArgoCD Server-ekin lan egin dezakezu ArgoCD WebUI web kontsolaren edo ArgoCD Cli komando lerroko tresnaren bidez.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Inoiz ez da berandu

"Trena joan da" - hau da zerbait egiteko aukera galtzen den egoera bati buruz esaten dutena. OpenShift-en kasuan, plataforma berri polit hau berehala erabiltzen hasteko nahiak egoera hori sortzen du askotan ibilbideak, inplementazioak eta OpenShift-eko beste objektu batzuk kudeatu eta mantentzearekin. Baina aukera beti erabat galtzen al da?

Honi buruzko artikulu sortarekin jarraitzen GitOps, gaur eskuz egindako aplikazio bat eta bere baliabideak nola transformatu erakutsiko dizugu GitOps tresnek dena kudeatzen duten prozesu batean. Horretarako, lehenik eskuz zabalduko dugu httpd aplikazioa. Beheko pantaila-argazkiak izen-espazioa, hedapena eta zerbitzua nola sortzen ditugun erakusten du, eta, ondoren, zerbitzu hau nola erakusten dugun ibilbide bat sortzeko.

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-app

Beraz, eskuz egindako aplikazio bat dugu. Orain GitOps kudeaketapean transferitu behar da erabilgarritasuna galdu gabe. Laburbilduz, hau egiten du:

  • Sortu Git biltegi bat kodearentzat.
  • Egungo objektuak esportatzen ditugu eta Git biltegira igotzen ditugu.
  • GitOps tresnak hautatzea eta zabaltzea.
  • Gure biltegia gehitzen dugu tresna-kit honetara.
  • Aplikazioa gure GitOps tresna-kutxan definitzen dugu.
  • Aplikazioaren proba proba bat egiten dugu GitOps tresna-kit erabiliz.
  • Objektuak GitOps tresna-kit erabiliz sinkronizatzen ditugu.
  • Gaitu objektuen inausketa eta sinkronizazio automatikoa.

Aurrekoan esan bezala Artikulu, GitOps-en Kubernetes klusterreko objektu guztiei buruzko informazio iturri bakarra eta bakarra dago: Git biltegia. Ondoren, zure erakundeak Git biltegi bat erabiltzen duelako premisatik abiatuko gara. Publikoa edo pribatua izan daiteke, baina Kubernetes klusterrak eskuragarri egon behar du. Hau aplikazioaren kodearen biltegi bera izan daiteke, edo inplementazioetarako bereziki sortutako biltegi bereizia. Biltegian baimen zorrotzak izatea gomendatzen da, sekretuak, ibilbideak eta segurtasunarekiko sentikorrak diren beste gauza batzuk gordeko baitira bertan.

Gure adibidean, GitHub-en biltegi publiko berri bat sortuko dugu. Nahi duzun moduan deitu dezakezu, blogpost izena erabiltzen dugu.

YAML objektu-fitxategiak lokalean edo Git-en gordetzen ez baziren, oc edo kubectl bitarrak erabili beharko dituzu. Beheko pantaila-argazkian YAML eskatzen ari gara gure izen-espaziorako, inplementaziorako, zerbitzurako eta ibilbiderako. Honen aurretik, sortu berria den biltegia eta cd-a klonatu genuen bertan.

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.yaml

Orain edita dezagun deployment.yaml fitxategia Argo CD-ak sinkronizatu ezin duen eremua kentzeko.

sed -i '/sgeneration: .*/d' deployment.yaml

Gainera, ibilbidea aldatu beharra dago. Lehenik eta behin lerro anitzeko aldagai bat ezarriko dugu eta, ondoren, sarrera ordezkatuko dugu: null aldagai horren edukiarekin.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

Beraz, fitxategiak ordenatu ditugu, Git biltegian gordetzea besterik ez da geratzen. Horren ondoren, biltegi hau informazio-iturri bakarra bihurtzen da, eta objektuetan eskuzko aldaketa guztiak erabat debekatuta egon behar dira.

git commit -am ‘initial commit of objects’
git push origin master

Gainera, dagoeneko ArgoCD zabaldu duzulatik abiatuko gara (nola egin - ikusi aurreko post). Hori dela eta, Argo CDari gehituko diogu guk sortutako biltegia, gure adibideko aplikazio-kodea duena. Ziurtatu lehenago sortu duzun biltegi zehatza zehazten duzula.

argocd repo add https://github.com/cooktheryan/blogpost

Orain sortu dezagun aplikazioa. Aplikazioak balioak ezartzen ditu GitOps tresna-kitak uler ditzan zein biltegi eta bideak erabili, zein OpenShift behar den objektuak kudeatzeko, zein adar zehatz behar den biltegiaren eta baliabideak automatikoki sinkronizatu behar diren ala ez.

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

Aplikazio bat Argo CDan zehaztutakoan, tresna-kudea hasten da jada zabaldutako objektuak biltegiko definizioekin egiaztatzen. Gure adibidean, sinkronizazio automatikoa eta garbiketa desgaituta daude, beraz, elementuak ez dira oraindik aldatzen. Kontuan izan Argo CD interfazean gure aplikazioak "Sinkronizatu gabe" egoera izango duela, ez dagoelako ArgoCD-k eskaintzen duen etiketarik.
Horregatik, sinkronizazioa pixka bat beranduago hasten dugunean, objektuak ez dira berriro zabalduko.

Orain egin dezagun proba bat gure fitxategietan akatsik ez dagoela ziurtatzeko.

argocd app sync simple-app --dry-run

Akatsik ez badago, sinkronizazioarekin jarrai dezakezu.

argocd app sync simple-app

Gure aplikazioan argocd get komandoa exekutatu ondoren, aplikazioaren egoera Osasuntsu edo Sinkronizatuta aldatu dela ikusi beharko genuke. Horrek esan nahi du Git biltegiko baliabide guztiak jada zabalduta dauden baliabideekin bat datozela.

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:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Orain, sinkronizazioa eta garbiketa automatikoa gaitu ditzakezu eskuz ezer sortzen ez dela ziurtatzeko eta objektu bat biltegira sortzen edo eguneratzen den bakoitzean inplementazio bat gertatuko dela ziurtatzeko.

argocd app set simple-app --sync-policy automated --auto-prune

Beraz, hasiera batean GitOps inola ere erabiltzen ez zuen aplikazio bat arrakastaz eraman dugu GitOps kontrolpean.

Iturria: www.habr.com

Gehitu iruzkin berria