🥇Enkonduko al GitOps por OpenShift

Hodiaŭ ni parolos pri la principoj kaj modeloj de GitOps, same kiel kiel ĉi tiuj modeloj estas efektivigitaj sur la OpenShift-platformo. Interaga gvidilo pri ĉi tiu temo estas havebla ligilo.

En resumo, GitOps estas aro de praktikoj por uzi Git-tirajn petojn por administri infrastrukturon kaj aplikaĵajn agordojn. La Git-deponejo en GitOps estas traktata kiel ununura fonto de informoj pri la stato de la sistemo, kaj ĉiuj ŝanĝoj al ĉi tiu stato estas plene spureblaj kaj kontroladeblaj.

La ideo de ŝanĝa spurado en GitOps tute ne estas nova; ĉi tiu aliro estis delonge uzata preskaŭ universale kiam oni laboras kun aplika fontkodo. GitOps simple efektivigas similajn funkciojn (recenzoj, tirpetoj, etikedoj, ktp.) en infrastrukturo kaj aplikaĵa agorda administrado kaj disponigas similajn avantaĝojn kiel en la kazo de fontkodadministrado.

Ne ekzistas akademia difino aŭ aprobita aro de reguloj por GitOps, nur aro de principoj sur kiuj ĉi tiu praktiko estas konstruita:

La deklara priskribo de la sistemo estas konservita en la Git-deponejo (agordoj, monitorado, ktp.).
Ŝtataj ŝanĝoj estas faritaj per tiraj petoj.
La stato de kurantaj sistemoj kongruas kun la datumoj en la deponejo uzante Git-puŝpetojn.

GitOps-Principoj

Sistemdifinoj estas priskribitaj kiel fontkodo

Sistema agordo estas traktata kiel kodo, tiel ke ĝi povas esti stokita kaj aŭtomate versionita en Git-deponejo, kiu funkcias kiel ununura fonto de vero. Ĉi tiu aliro faciligas lanĉi kaj restarigi ŝanĝojn en sistemoj.

La dezirata stato kaj agordo de sistemoj estas fiksitaj kaj versionitaj en Git

Stokante kaj versionante la deziratan staton de sistemoj en Git, ni povas facile ruliĝi kaj refari ŝanĝojn al sistemoj kaj aplikoj. Ni ankaŭ povas uzi la sekurecajn mekanismojn de Git por kontroli kodposedon kaj kontroli ĝian aŭtentikecon.

Ŝanĝoj de agordo povas esti aŭtomate aplikitaj per tiraj petoj

Uzante Git-tiri petojn, ni povas facile kontroli kiel ŝanĝoj estas aplikataj al agordoj en la deponejo. Ekzemple, ili povas esti donitaj al aliaj grupanoj por revizio aŭ prizorgi CI-testojn, ktp.

Kaj samtempe, ne necesas distribui administrajn povojn maldekstre kaj dekstre. Por fari agordajn ŝanĝojn, uzantoj nur bezonas taŭgajn permesojn en la Git-deponejo kie tiuj agordoj estas stokitaj.

Ripari la problemon de nekontrolita drivo de agordoj

Post kiam la dezirata stato de la sistemo estas konservita en Git-deponejo, ĉio, kion ni devas fari, estas trovi programaron, kiu certigos, ke la nuna stato de la sistemo kongruas kun sia dezirata stato. Se ĉi tio ne estas la kazo, tiam ĉi tiu programaro devus - depende de la agordoj - aŭ forigi la diferencon memstare, aŭ sciigi nin pri agordo drivo.

GitOps-Modeloj por OpenShift

Sur-Cluster Resource Reconcilier

Laŭ ĉi tiu modelo, la areto havas regilon, kiu respondecas pri kompari Kubernetes-resursojn (YAML-dosieroj) en la Git-deponejo kun la realaj rimedoj de la areto. Se malkongruoj estas detektitaj, la regilo sendas sciigojn kaj eventuale faras agojn por korekti la diferencojn. Ĉi tiu GitOps-modelo estas uzata en Anthos Config Management kaj Weaveworks Flux.

Ekstera Rimeda Repacilo (Puŝo)

Ĉi tiu modelo povas esti konsiderata kiel variaĵo de la antaŭa, kiam ni havas unu aŭ plurajn regilojn respondecajn pri sinkronigado de rimedoj en la paroj "Git-deponejo - Kubernetes-grupo". La diferenco ĉi tie estas, ke ĉiu administrita areto ne nepre havas sian propran apartan regilon. Git - k8s-aretparoj ofte estas difinitaj kiel CRDoj (personaj rimeddifinoj), kiuj povas priskribi kiel la regilo devus plenumi sinkronigon. Ene de ĉi tiu modelo, regiloj komparas la Git-deponejon specifitan en la CRD kun la Kubernetes-grupo-resursoj, kiuj ankaŭ estas specifitaj en la CRD, kaj faras taŭgajn agojn bazitajn sur la rezultoj de la komparo. Aparte, ĉi tiu GitOps-modelo estas uzata en ArgoCD.

GitOps sur la platformo OpenShift

Administrado de plurgrupo Kubernetes-infrastrukturo

Kun la disvastiĝo de Kubernetes kaj la kreskanta populareco de multnubaj strategioj kaj randa komputado, la averaĝa nombro de OpenShift-aretoj por kliento ankaŭ pliiĝas.

Ekzemple, dum uzado de randa komputado, la aretoj de unu kliento povas esti deplojitaj en centoj aŭ eĉ miloj. Kiel rezulto, li estas devigita administri plurajn sendependajn aŭ kunordigitajn OpenShift-aretojn en la publika nubo kaj surloke.

En ĉi tiu kazo, multaj problemoj devas esti solvitaj, precipe:

Kontrolu ke la aretoj estas en identa stato (agordoj, monitorado, stokado, ktp.)
Rekrei (aŭ restarigi) aretojn bazitajn sur konata stato.
Kreu novajn aretojn bazitajn sur konata stato.
Lanĉi ŝanĝojn al pluraj OpenShift-aretoj.
Revu la ŝanĝojn tra pluraj OpenShift-aretoj.
Ligu ŝablonajn agordojn al malsamaj medioj.

Aplikaj Agordoj

Dum ilia vivociklo, aplikoj ofte pasas tra ĉeno de aretoj (dev, scenejo, ktp.) antaŭ ol finiĝi en produktadgrupo. Krome, pro havebleco kaj skaleblo postuloj, klientoj ofte deplojas aplikojn tra pluraj surlokaj aretoj aŭ pluraj regionoj de publika nuba platformo.

En ĉi tiu kazo, la sekvaj taskoj devas esti solvitaj:

Certigu la movadon de aplikoj (binaroj, agordoj, ktp.) inter aretoj (dev, scenejo, ktp.).
Disvolvu ŝanĝojn al aplikaĵoj (duumaj, agordoj, ktp.) en pluraj OpenShift-aretoj.
Revenu ŝanĝojn al aplikoj al antaŭa konata stato.

OpenShift GitOps Uzokazoj

1. Aplikante ŝanĝojn de la Git-deponejo

Administranto de grapoloj povas stoki OpenShift-agordojn en Git-deponejo kaj aŭtomate apliki ilin por senpene krei novajn aretojn kaj alporti ilin en staton identan al la konata stato stokita en la Git-deponejo.

2. Sinkronigo kun Sekreta Administranto

La administranto ankaŭ profitos de la kapablo sinkronigi OpenShift sekretajn objektojn kun taŭga programaro kiel Vault por administri ilin uzante ilojn speciale kreitajn por tio.

3. Kontrolo de drivaj agordoj

La administranto estos favora nur se OpenShift GitOps mem identigas kaj avertas pri diferencoj inter realaj agordoj kaj tiuj specifitaj en la deponejo, por ke ili rapide respondu al drivo.

4. Sciigoj pri agorda drivo

Ili estas utilaj en la kazo kiam la administranto volas rapide lerni pri kazoj de agorda drivo por rapide preni taŭgajn rimedojn memstare.

5. Mana sinkronigo de agordoj dum drivado

Permesas al la administranto sinkronigi la OpenShift-areton kun la Git-deponejo en la okazo de agorda drivo, por rapide resendi la areton al antaŭa konata stato.

6.Aŭtomata sinkronigo de agordoj dum drivado

La administranto ankaŭ povas agordi la OpenShift-grupon por aŭtomate sinkronigi kun la deponejo kiam drivo estas detektita, tiel ke la grapo-agordo ĉiam kongruas kun la agordoj en Git.

7. Pluraj aretoj - unu deponejo

La administranto povas stoki agordojn de pluraj malsamaj OpenShift-aretoj en unu Git-deponejo kaj selekteme apliki ilin laŭbezone.

8. Hierarkio de agordoj (heredaĵo)

La administranto povas agordi hierarkion de cluster-agordoj en la deponejo (stadio, prod, aplikaĵa biletujo, ktp. kun heredo). Alivorte, ĝi povas determini ĉu konfiguracioj devus esti aplikitaj al unu aŭ pluraj aretoj.

Ekzemple, se administranto fiksas la hierarkion "Produktado-grupoj (prod) → Sistemo X-aretoj → Produktado-aretoj de sistemo X" en la Git-deponejo, tiam kombinaĵo de la sekvaj agordoj estas aplikata al la produktadaro de sistemo X:

Agordoj komunaj al ĉiuj produktadgrupoj.
Agordoj por la System X-areto.
Agordoj por la X-sistema produktadgrupo.

9. Ŝablonoj kaj agordo anstataŭigas

La administranto povas superregi aron de hereditaj agordoj kaj iliaj valoroj, ekzemple, por fajnagordi la agordon por specifaj aretoj al kiuj ili estos aplikitaj.

10. Selektema inkluzivi kaj ekskludi por agordoj, aplikaj agordoj

La administranto povas agordi la kondiĉojn por la aplikado aŭ neapliko de iuj agordoj al aretoj kun certaj trajtoj.

11. Ŝablona subteno

Programistoj profitos de la kapablo elekti kiel aplikrimedoj estos difinitaj (Helm Chart, pura Kubernetes yaml, ktp.) por uzi la plej taŭgan formaton por ĉiu specifa aplikaĵo.

GitOps-iloj sur la OpenShift-platformo

ArgoCD

ArgoCD efektivigas la modelon External Resource Reconcile kaj ofertas centralizitan UI por reĝisori unu-al-multajn rilatojn inter aretoj kaj Git-deponejoj. La malavantaĝoj de ĉi tiu programo inkluzivas la malkapablon administri aplikojn kiam ArgoCD ne funkcias.

Oficiala retejo

fluo

Flux efektivigas On-Cluster Resource Reconcile modelon kaj, kiel rezulto, ekzistas neniu centralizita administrado de la difina deponejo, kio estas malforta punkto. Aliflanke, ĝuste pro la manko de centralizo, la kapablo administri aplikojn restas eĉ se unu grapolo malsukcesas.

Oficiala retejo

Instalante ArgoCD sur OpenShift

ArgoCD ofertas bonegan komandlinian interfacon kaj retkonzolon, do ni ne kovros Flux kaj aliajn alternativojn ĉi tie.

Por deploji ArgoCD sur la OpenShift 4-platformo, sekvu ĉi tiujn paŝojn kiel administranto de cluster:

Deplojante ArgoCD-komponentojn sur la OpenShift-platformo

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

Plibonigo de ArgoCD Server tiel ke ĝi povas esti vidita per 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=Redirect

Deplojante ArgoCD Cli Ilon

# 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

Ŝanĝi la administran pasvorton de 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

Post plenumi ĉi tiujn paŝojn, vi povas labori kun ArgoCD-Servilo per la interreta konzolo ArgoCD WebUI aŭ la ilo de komandlinio ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Neniam Estas Tro malfrue

"La trajno foriris" - jen kion oni diras pri situacio, kiam la ŝanco fari ion estas maltrafita. En la kazo de OpenShift, la deziro tuj ekuzi ĉi tiun bonegan novan platformon ofte kreas ĝuste ĉi tiun situacion kun la administrado kaj prizorgado de itineroj, deplojoj kaj aliaj OpenShift-objektoj. Sed ĉu la ŝanco ĉiam estas tute perdita?

Daŭrigante la serion de artikoloj pri GitOps, hodiaŭ ni montros al vi kiel transformi manfaritan aplikaĵon kaj ĝiajn rimedojn en procezon, kie ĉio estas administrita de GitOps-iloj. Por fari tion, ni unue deplojos mane la httpd-aplikaĵon. La ekrankopio sube montras kiel ni kreas nomspacon, disfaldiĝon kaj servon, kaj poste elmontras ĉi tiun servon por krei itineron.

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

Do ni havas manfaritan aplikaĵon. Nun ĝi devas esti transdonita sub GitOps-administrado sen perdo de havebleco. Mallonge, ĝi faras ĉi tion:

Kreu Git-deponejon por la kodo.
Ni eksportas niajn nunajn objektojn kaj alŝutas ilin al la Git-deponejo.
Elektado kaj deplojado de GitOps-iloj.
Ni aldonas nian deponejon al ĉi tiu ilaro.
Ni difinas la aplikaĵon en nia ilaro GitOps.
Ni provas la aplikaĵon per la ilaro GitOps.
Ni sinkronigas objektojn per la ilaro GitOps.
Ebligu pritondado kaj aŭtomata sinkronigo de objektoj.

Kiel menciite en la antaŭa artikolo, en GitOps estas unu kaj nur unu fonto de informoj pri ĉiuj objektoj en la Kubernetes-grupo(j) - la Git-deponejo. Poste, ni procedas de la premiso, ke via organizo jam uzas Git-deponejon. Ĝi povas esti publika aŭ privata, sed ĝi devas esti alirebla por Kubernetes-grupoj. Ĉi tio povas esti la sama deponejo kiel por aplika kodo, aŭ aparta deponejo kreita specife por deplojoj. Oni rekomendas havi striktajn permesojn en la deponejo ĉar sekretoj, itineroj kaj aliaj sekurec-sentemaj aferoj estos konservitaj tie.

En nia ekzemplo, ni kreos novan publikan deponejon sur GitHub. Vi povas nomi ĝin kiel ajn vi volas, ni uzas la nomon blogafiŝo.

Se la YAML-objektaj dosieroj ne estis konservitaj loke aŭ en Git, tiam vi devos uzi la binarojn oc aŭ kubectl. En la suba ekrankopio ni petas YAML por nia nomspaco, deplojo, servo kaj itinero. Antaŭ tio, ni klonis la lastatempe kreitan deponejon kaj diskon en ĝi.

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

Nun ni redaktu la dosieron deployment.yaml por forigi la kampon, kiun Argo KD ne povas sinkronigi.

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

Krome, la itinero devas esti ŝanĝita. Ni unue starigos multlinian variablon kaj poste anstataŭigos eniron: nulo kun la enhavo de tiu variablo.

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

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

Do, ni ordigis la dosierojn, restas nur konservi ilin al la Git-deponejo. Post tio ĉi tiu deponejo iĝas la sola fonto de informoj, kaj ajnaj manaj ŝanĝoj al objektoj estu strikte malpermesitaj.

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

Plue ni procedas de la fakto, ke vi jam deplojis ArgoCD (kiel fari tion - vidu antaŭe afiŝo). Tial ni aldonos al la Argo-KD la deponejon, kiun ni kreis, enhavanta la aplikan kodon el nia ekzemplo. Nur certigu, ke vi specifu la ĝustan deponejon, kiun vi kreis pli frue.

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

Nun ni kreu la aplikaĵon. La aplikaĵo fiksas valorojn por ke la ilaro de GitOps komprenu kiajn deponejon kaj vojojn uzi, kiun OpenShift necesas por administri objektojn, kiu specifa branĉo de la deponejo bezonas, kaj ĉu rimedoj devas aŭtomate sinkronigi.

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

Post kiam aplikaĵo estas specifita en la Argo KD, la ilaro komencas kontroli jam deplojitajn objektojn kontraŭ la difinoj en la deponejo. En nia ekzemplo, aŭtomata sinkronigo kaj purigado estas malŝaltitaj, do la elementoj ankoraŭ ne ŝanĝiĝas. Bonvolu noti, ke en la interfaco de Argo CD nia aplikaĵo havos la statuson "Elsinkronigita" ĉar ne ekzistas etikedo, kiun ArgoCD provizas.
Jen kial kiam ni komencas sinkronigon iom poste, la objektoj ne estos redeplojitaj.

Nun ni provu por certigi, ke ne estas eraroj en niaj dosieroj.

argocd app sync simple-app --dry-run

Se ne estas eraroj, tiam vi povas daŭrigi sinkronigon.

argocd app sync simple-app

Post rulado de la argocd get komando en nia aplikaĵo, ni devus vidi, ke la aplika statuso ŝanĝiĝis al Sana aŭ Sinkronigita. Ĉi tio signifos, ke ĉiuj rimedoj en la Git-deponejo nun respondas al tiuj rimedoj, kiuj jam estis deplojitaj.

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

Nun vi povas ebligi aŭtomatan sinkronigon kaj purigadon por certigi, ke nenio estas kreita permane kaj ke ĉiufoje kiam objekto estas kreita aŭ ĝisdatigita al la deponejo, deplojo okazos.

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

Do, ni sukcese alportis aplikaĵon sub GitOps-kontrolon, kiu komence neniel uzis GitOps.

fonto: www.habr.com

Enkonduko al GitOps por OpenShift