I dag skal vi snakke om prinsippene og modellene til GitOps, samt hvordan disse modellene implementeres på OpenShift-plattformen. En interaktiv guide om dette emnet er tilgjengelig .
I et nøtteskall er GitOps et sett med praksiser for å bruke Git pull-forespørsler for å administrere infrastruktur og applikasjonskonfigurasjoner. Git-depotet i GitOps behandles som en enkelt kilde til informasjon om tilstanden til systemet, og eventuelle endringer i denne tilstanden er fullt sporbare og kontrollerbare.
Ideen om endringssporing i GitOps er på ingen måte ny; denne tilnærmingen har lenge vært brukt nesten universelt når man jobber med applikasjonskildekode. GitOps implementerer ganske enkelt lignende funksjoner (anmeldelser, pull-forespørsler, tagger osv.) i administrasjon av infrastruktur og applikasjonskonfigurasjon og gir lignende fordeler som i tilfellet med kildekodeadministrasjon.
Det er ingen akademisk definisjon eller godkjent sett med regler for GitOps, bare et sett med prinsipper som denne praksisen er bygget på:
- Den deklarative beskrivelsen av systemet lagres i Git-depotet (konfigurasjoner, overvåking, etc.).
- Statsendringer gjøres gjennom pull-forespørsler.
- Tilstanden til kjørende systemer bringes i tråd med dataene i depotet ved å bruke Git push-forespørsler.
GitOps-prinsipper
- Systemdefinisjoner er beskrevet som kildekode
Systemkonfigurasjon behandles som kode, slik at den kan lagres og automatisk versjoneres i et Git-depot, som fungerer som en enkelt kilde til sannhet. Denne tilnærmingen gjør det enkelt å rulle ut og tilbakestille endringer i systemer.
- Ønsket tilstand og konfigurasjon av systemer er satt og versjonert i Git
Ved å lagre og versjonere ønsket systemstatus i Git, kan vi enkelt rulle ut og tilbakestille endringer i systemer og applikasjoner. Vi kan også bruke Gits sikkerhetsmekanismer for å kontrollere kodeeierskap og verifisere ektheten.
- Konfigurasjonsendringer kan brukes automatisk via pull-forespørsler
Ved å bruke Git pull-forespørsler kan vi enkelt kontrollere hvordan endringer brukes på konfigurasjoner i depotet. For eksempel kan de gis til andre teammedlemmer for gjennomgang eller gjennom CI-tester osv.
Og samtidig er det ikke nødvendig å distribuere administratorrettigheter til venstre og høyre. For å foreta konfigurasjonsendringer trenger brukere bare passende tillatelser i Git-depotet der disse konfigurasjonene er lagret.
- Løser problemet med ukontrollert drift av konfigurasjoner
Når den ønskede tilstanden til systemet er lagret i et Git-depot, er alt vi trenger å gjøre å finne programvare som vil sikre at den nåværende tilstanden til systemet samsvarer med ønsket tilstand. Hvis dette ikke er tilfelle, bør denne programvaren - avhengig av innstillingene - enten eliminere avviket på egen hånd, eller varsle oss om konfigurasjonsdrift.
GitOps-modeller for OpenShift
On-Cluster Resource Reconciler
I følge denne modellen har klyngen en kontroller som er ansvarlig for å sammenligne Kubernetes-ressurser (YAML-filer) i Git-depotet med de virkelige ressursene til klyngen. Hvis det oppdages avvik, sender kontrolløren varsler og iverksetter muligens tiltak for å rette opp avvikene. Denne GitOps-modellen brukes i Anthos Config Management og Weaveworks Flux.
Ekstern ressursavstemming (Push)
Denne modellen kan betraktes som en variant av den forrige, når vi har en eller flere kontroller som er ansvarlige for å synkronisere ressurser i "Git-repository - Kubernetes-klyngen"-parene. Forskjellen her er at hver administrert klynge ikke nødvendigvis har sin egen separate kontroller. Git - k8s klyngepar er ofte definert som CRD-er (tilpassede ressursdefinisjoner), som kan beskrive hvordan kontrolleren skal utføre synkronisering. Innenfor denne modellen sammenligner kontrollere Git-depotet spesifisert i CRD med Kubernetes klyngressursene, som også er spesifisert i CRD, og utfører passende handlinger basert på resultatene av sammenligningen. Spesielt denne GitOps-modellen brukes i ArgoCD.
GitOps på OpenShift-plattformen
Administrasjon av multi-cluster Kubernetes-infrastruktur
Med spredningen av Kubernetes og den økende populariteten til multi-cloud-strategier og edge computing, øker også gjennomsnittlig antall OpenShift-klynger per kunde.
For eksempel, når du bruker edge computing, kan én kundes klynger distribueres i hundrevis eller til og med tusenvis. Som et resultat blir han tvunget til å administrere flere uavhengige eller koordinerte OpenShift-klynger i den offentlige skyen og på stedet.
I dette tilfellet må mange problemer løses, spesielt:
- Kontroller at klyngene er i identisk tilstand (konfigurasjoner, overvåking, lagring, etc.)
- Gjenopprett (eller gjenopprett) klynger basert på en kjent tilstand.
- Opprett nye klynger basert på en kjent tilstand.
- Rull ut endringer til flere OpenShift-klynger.
- Tilbakestill endringer på tvers av flere OpenShift-klynger.
- Koble malkonfigurasjoner til forskjellige miljøer.
Applikasjonskonfigurasjoner
I løpet av livssyklusen går applikasjoner ofte gjennom en kjede av klynger (utvikler, stadium, etc.) før de havner i en produksjonsklynge. I tillegg, på grunn av krav til tilgjengelighet og skalerbarhet, distribuerer kunder ofte applikasjoner på tvers av flere lokale klynger eller flere regioner i en offentlig skyplattform.
I dette tilfellet må følgende oppgaver løses:
- Sørg for bevegelse av applikasjoner (binærfiler, konfigurasjoner, etc.) mellom klynger (dev, scene, etc.).
- Rull ut endringer i applikasjoner (binærfiler, konfigurasjoner, etc.) i flere OpenShift-klynger.
- Tilbakestill endringer i applikasjoner til en tidligere kjent tilstand.
OpenShift GitOps-brukstilfeller
1. Bruk av endringer fra Git-depotet
En klyngeadministrator kan lagre OpenShift-klyngekonfigurasjoner i et Git-repository og automatisk bruke dem for å enkelt lage nye klynger og bringe dem inn i en tilstand som er identisk med den kjente tilstanden som er lagret i Git-depotet.
2. Synkronisering med Secret Manager
Administratoren vil også dra nytte av muligheten til å synkronisere hemmelige OpenShift-objekter med passende programvare som Vault for å administrere dem ved å bruke verktøy spesielt laget for dette.
3. Kontroll av driftkonfigurasjoner
Administratoren vil kun være for hvis OpenShift GitOps selv identifiserer og advarer om avvik mellom reelle konfigurasjoner og de som er spesifisert i depotet, slik at de raskt kan reagere på drift.
4. Varsler om konfigurasjonsdrift
De er nyttige i tilfeller der administratoren raskt ønsker å lære om tilfeller av konfigurasjonsavvik for raskt å kunne ta passende tiltak på egen hånd.
5. Manuell synkronisering av konfigurasjoner ved drifting
Lar administratoren synkronisere OpenShift-klyngen med Git-repositoriet i tilfelle konfigurasjonsdrift, for raskt å returnere klyngen til en tidligere kjent tilstand.
6.Auto-synkronisering av konfigurasjoner ved drifting
Administratoren kan også konfigurere OpenShift-klyngen til å automatisk synkronisere med depotet når en drift oppdages, slik at klyngekonfigurasjonen alltid samsvarer med konfigurasjonene i Git.
7. Flere klynger - ett depot
Administratoren kan lagre konfigurasjoner av flere forskjellige OpenShift-klynger i ett Git-depot og selektivt bruke dem etter behov.
8. Hierarki av klyngekonfigurasjoner (arv)
Administratoren kan sette et hierarki av klyngekonfigurasjoner i depotet (stage, prod, appportefølje, etc. med arv). Med andre ord kan den bestemme om konfigurasjoner skal brukes på en eller flere klynger.
For eksempel, hvis en administrator setter hierarkiet "Produksjonsklynger (prod) → System X-klynger → Produksjonsklynger av system X" i Git-depotet, blir en kombinasjon av følgende konfigurasjoner brukt på produksjonsklyngene til system X:
- Konfigurasjoner som er felles for alle produksjonsklynger.
- Konfigurasjoner for System X-klyngen.
- Konfigurasjoner for X-systemproduksjonsklyngen.
9. Maler og konfigurasjonsoverstyringer
Administratoren kan overstyre et sett med arvede konfigurasjoner og deres verdier, for eksempel for å finjustere konfigurasjonen for spesifikke klynger de skal brukes på.
10. Selektiv inkludere og ekskludere for konfigurasjoner, applikasjonskonfigurasjoner
Administratoren kan sette betingelsene for applikasjon eller ikke-applikasjon av visse konfigurasjoner til klynger med visse egenskaper.
11. Malstøtte
Utviklere vil dra nytte av muligheten til å velge hvordan applikasjonsressurser skal defineres (Helm Chart, ren Kubernetes yaml, etc.) for å bruke det mest passende formatet for hver spesifikk applikasjon.
GitOps-verktøy på OpenShift-plattformen
ArgoCD
ArgoCD implementerer External Resource Reconcile-modellen og tilbyr et sentralisert brukergrensesnitt for orkestrering av en-til-mange-relasjoner mellom klynger og Git-repositories. Ulempene med dette programmet inkluderer manglende evne til å administrere applikasjoner når ArgoCD ikke fungerer.
Flux
Flux implementerer en On-Cluster Resource Reconcile-modell, og som et resultat er det ingen sentralisert styring av definisjonslageret, som er et svakt punkt. På den annen side, nettopp på grunn av mangelen på sentralisering, forblir muligheten til å administrere applikasjoner selv om en klynge svikter.
Installerer ArgoCD på OpenShift
ArgoCD tilbyr et utmerket kommandolinjegrensesnitt og nettkonsoll, så vi vil ikke dekke Flux og andre alternativer her.
For å distribuere ArgoCD på OpenShift 4-plattformen, følg disse trinnene som klyngeadministrator:
Distribuere ArgoCD-komponenter på OpenShift-plattformen
# 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}')Forbedring av ArgoCD Server slik at den kan sees av 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=RedirectDistribuerer 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/argocdEndring av ArgoCD Server-administratorpassordet
# 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
Etter å ha fullført disse trinnene, kan du jobbe med ArgoCD Server gjennom ArgoCD WebUI-nettkonsollen eller ArgoCD Cli-kommandolinjeverktøyet.
GitOps - Det er aldri for sent
"Toget har gått" - dette er hva de sier om en situasjon når muligheten til å gjøre noe blir savnet. Når det gjelder OpenShift, skaper ofte ønsket om å begynne å bruke denne kule nye plattformen akkurat denne situasjonen med administrasjon og vedlikehold av ruter, utplasseringer og andre OpenShift-objekter. Men er sjansen alltid helt tapt?
Fortsetter artikkelserien om , i dag viser vi deg hvordan du forvandler en håndlaget applikasjon og dens ressurser til en prosess der alt administreres av GitOps-verktøy. For å gjøre dette, vil vi først manuelt distribuere httpd-applikasjonen. Skjermbildet nedenfor viser hvordan vi oppretter et navneområde, distribusjon og tjeneste, og deretter eksponerer denne tjenesten for å lage en rute.
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-appSå vi har en håndlaget applikasjon. Nå må den overføres under GitOps-administrasjon uten tap av tilgjengelighet. Kort sagt, det gjør dette:
- Opprett et Git-lager for koden.
- Vi eksporterer våre nåværende objekter og laster dem opp til Git-depotet.
- Velge og distribuere GitOps-verktøy.
- Vi legger til vårt depot til dette verktøysettet.
- Vi definerer applikasjonen i vårt GitOps-verktøysett.
- Vi utfører en testkjøring av applikasjonen ved hjelp av GitOps-verktøysettet.
- Vi synkroniserer objekter ved hjelp av GitOps-verktøysettet.
- Aktiver beskjæring og automatisk synkronisering av objekter.
Som nevnt i forrige , i GitOps er det én og bare én kilde til informasjon om alle objekter i Kubernetes-klyngen(e) - Git-depotet. Deretter går vi ut fra premisset om at organisasjonen din allerede bruker et Git-depot. Den kan være offentlig eller privat, men den må være tilgjengelig for Kubernetes-klynger. Dette kan være det samme depotet som for applikasjonskode, eller et separat depot opprettet spesielt for distribusjoner. Det anbefales å ha strenge tillatelser i depotet siden hemmeligheter, ruter og andre sikkerhetssensitive ting vil bli lagret der.
I vårt eksempel vil vi opprette et nytt offentlig depot på GitHub. Du kan kalle det hva du vil, vi bruker navnet blogginnlegg.
Hvis YAML-objektfilene ikke ble lagret lokalt eller i Git, må du bruke binærfilene oc eller kubectl. I skjermbildet nedenfor ber vi om YAML for vårt navneområde, distribusjon, service og rute. Før dette klonet vi det nyopprettede depotet og cd inn i det.
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.yamlLa oss nå redigere filen deployment.yaml for å fjerne feltet som Argo CD ikke kan synkronisere.
sed -i '/sgeneration: .*/d' deployment.yamlI tillegg må traseen endres. Vi setter først en flerlinjevariabel og erstatter deretter ingress: null med innholdet i den variabelen.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlSå vi har sortert ut filene, alt som gjenstår er å lagre dem i Git-depotet. Deretter blir dette depotet den eneste informasjonskilden, og enhver manuell endring av objekter bør være strengt forbudt.
git commit -am ‘initial commit of objects’
git push origin masterVidere går vi ut fra det faktum at du allerede har distribuert ArgoCD (hvordan du gjør dette - se forrige ). Derfor vil vi legge til Argo-CDen depotet vi opprettet, som inneholder applikasjonskoden fra vårt eksempel. Bare sørg for at du spesifiserer det eksakte depotet du opprettet tidligere.
argocd repo add https://github.com/cooktheryan/blogpostLa oss nå lage applikasjonen. Applikasjonen setter verdier slik at GitOps-verktøysettet forstår hvilket depot og stier som skal brukes, hvilken OpenShift som trengs for å administrere objekter, hvilken spesifikk gren av depotet som er nødvendig, og om ressurser skal automatisk synkroniseres.
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
Når en applikasjon er spesifisert i Argo-CDen, begynner verktøysettet å sjekke allerede utplasserte objekter mot definisjonene i depotet. I vårt eksempel er automatisk synkronisering og opprydding deaktivert, så elementene endres ikke ennå. Vær oppmerksom på at i Argo CD-grensesnittet vil applikasjonen vår ha statusen "Ut synkronisert" fordi det ikke er noen etikett som ArgoCD gir.
Dette er grunnen til at når vi starter synkroniseringen litt senere, vil ikke objektene bli omplassert.
La oss nå gjøre en testkjøring for å sikre at det ikke er noen feil i filene våre.
argocd app sync simple-app --dry-runHvis det ikke er noen feil, kan du fortsette til synkronisering.
argocd app sync simple-appEtter å ha kjørt argocd get-kommandoen på applikasjonen vår, bør vi se at applikasjonsstatusen har endret seg til Sunn eller Synkronisert. Dette vil bety at alle ressursene i Git-depotet nå tilsvarer de ressursene som allerede har blitt distribuert.
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
... Nå kan du aktivere automatisk synkronisering og opprydding for å sikre at ingenting opprettes manuelt, og at det vil skje en distribusjon hver gang et objekt opprettes eller oppdateres til depotet.
argocd app set simple-app --sync-policy automated --auto-prune
Så vi har brakt en applikasjon under GitOps-kontroll som i utgangspunktet ikke brukte GitOps på noen måte.
Kilde: www.habr.com