I dag vil vi tale om principperne og modellerne for GitOps, samt hvordan disse modeller implementeres på OpenShift-platformen. En interaktiv vejledning om dette emne er tilgængelig .
I en nøddeskal er GitOps et sæt praksisser for at bruge Git pull-anmodninger til at administrere infrastruktur og applikationskonfigurationer. Git-lageret i GitOps behandles som en enkelt kilde til information om systemets tilstand, og alle ændringer i denne tilstand er fuldt sporbare og kan auditeres.
Ideen om ændringssporing i GitOps er på ingen måde ny; denne tilgang har længe været brugt næsten universelt, når man arbejder med applikationskildekode. GitOps implementerer simpelthen lignende funktioner (anmeldelser, pull-anmodninger, tags osv.) i infrastruktur- og applikationskonfigurationsstyring og giver lignende fordele som i tilfældet med kildekodestyring.
Der er ingen akademisk definition eller godkendt sæt regler for GitOps, kun et sæt principper, som denne praksis er bygget på:
- Den deklarative beskrivelse af systemet er gemt i Git repository (konfigurationer, overvågning osv.).
- Statsændringer foretages gennem pull-anmodninger.
- Status for kørende systemer bringes i overensstemmelse med dataene i depotet ved hjælp af Git push-anmodninger.
GitOps principper
- Systemdefinitioner beskrives som kildekode
Systemkonfiguration behandles som kode, så den kan lagres og automatisk versioneres i et Git-lager, der fungerer som en enkelt kilde til sandhed. Denne tilgang gør det nemt at udrulle og tilbagerulle ændringer i systemer.
- Den ønskede tilstand og konfiguration af systemer er indstillet og versioneret i Git
Ved at gemme og versionere den ønskede tilstand af systemer i Git, er vi i stand til nemt at udrulle og rulle ændringer til systemer og applikationer tilbage. Vi kan også bruge Gits sikkerhedsmekanismer til at kontrollere kodeejerskab og verificere dens ægthed.
- Konfigurationsændringer kan anvendes automatisk via pull-anmodninger
Ved hjælp af Git pull-anmodninger kan vi nemt kontrollere, hvordan ændringer anvendes på konfigurationer i repository. For eksempel kan de gives til andre teammedlemmer til gennemgang eller køres gennem CI-tests osv.
Og på samme tid er der ingen grund til at fordele admin-beføjelser til venstre og højre. For at foretage konfigurationsændringer behøver brugere kun passende tilladelser i Git-lageret, hvor disse konfigurationer er gemt.
- Løsning af problemet med ukontrolleret drift af konfigurationer
Når først den ønskede tilstand af systemet er gemt i et Git-lager, er alt, hvad vi skal gøre, at finde software, der sikrer, at systemets aktuelle tilstand matcher dens ønskede tilstand. Hvis dette ikke er tilfældet, så bør denne software - afhængigt af indstillingerne - enten fjerne uoverensstemmelsen alene eller give os besked om konfigurationsdrift.
GitOps-modeller til OpenShift
On-Cluster Resource Reconciler
Ifølge denne model har klyngen en controller, der er ansvarlig for at sammenligne Kubernetes-ressourcer (YAML-filer) i Git-lageret med klyngens reelle ressourcer. Hvis der opdages uoverensstemmelser, sender controlleren meddelelser og træffer muligvis foranstaltninger for at rette uoverensstemmelserne. Denne GitOps-model bruges i Anthos Config Management og Weaveworks Flux.
Ekstern ressourceafstemning (push)
Denne model kan betragtes som en variation af den foregående, når vi har en eller flere controllere, der er ansvarlige for at synkronisere ressourcer i "Git-lageret - Kubernetes-klynge"-parrene. Forskellen her er, at hver administreret klynge ikke nødvendigvis har sin egen separate controller. Git - k8s klyngepar er ofte defineret som CRD'er (brugerdefinerede ressourcedefinitioner), som kan beskrive, hvordan controlleren skal udføre synkronisering. Inden for denne model sammenligner controllere Git-lageret specificeret i CRD'et med Kubernetes-klyngressourcerne, som også er specificeret i CRD'en, og udfører passende handlinger baseret på resultaterne af sammenligningen. Især denne GitOps-model bruges i ArgoCD.
GitOps på OpenShift-platformen
Administration af multi-cluster Kubernetes infrastruktur
Med udbredelsen af Kubernetes og den voksende popularitet af multi-cloud-strategier og edge computing, er det gennemsnitlige antal OpenShift-klynger pr. kunde også stigende.
For eksempel, når du bruger edge computing, kan én kundes klynger implementeres i hundredvis eller endda tusindvis. Som et resultat er han tvunget til at administrere flere uafhængige eller koordinerede OpenShift-klynger i den offentlige sky og på stedet.
I dette tilfælde skal en masse problemer løses, især:
- Kontroller, at klyngerne er i en identisk tilstand (konfigurationer, overvågning, lagring osv.)
- Genopret (eller gendan) klynger baseret på en kendt tilstand.
- Opret nye klynger baseret på en kendt tilstand.
- Udrul ændringer til flere OpenShift-klynger.
- Rul ændringer tilbage på tværs af flere OpenShift-klynger.
- Link skabelonkonfigurationer til forskellige miljøer.
Applikationskonfigurationer
I løbet af deres livscyklus passerer applikationer ofte gennem en kæde af klynger (dev, fase osv.), før de ender i en produktionsklynge. På grund af tilgængeligheds- og skalerbarhedskrav implementerer kunder desuden ofte applikationer på tværs af flere lokale klynger eller flere områder af en offentlig cloudplatform.
I dette tilfælde skal følgende opgaver løses:
- Sørg for bevægelse af applikationer (binære filer, konfigurationer osv.) mellem klynger (dev, scene osv.).
- Udrul ændringer til applikationer (binære filer, konfigurationer osv.) i flere OpenShift-klynger.
- Rul ændringer af applikationer tilbage til en tidligere kendt tilstand.
OpenShift GitOps Use Cases
1. Anvendelse af ændringer fra Git-lageret
En klyngeadministrator kan gemme OpenShift-klyngekonfigurationer i et Git-lager og automatisk anvende dem til ubesværet at skabe nye klynger og bringe dem i en tilstand, der er identisk med den kendte tilstand, der er gemt i Git-lageret.
2. Synkronisering med Secret Manager
Administratoren vil også drage fordel af muligheden for at synkronisere hemmelige OpenShift-objekter med passende software som Vault for at administrere dem ved hjælp af værktøjer, der er specielt skabt til dette.
3. Kontrol af driftkonfigurationer
Admin vil kun være for, hvis OpenShift GitOps selv identificerer og advarer om uoverensstemmelser mellem reelle konfigurationer og dem, der er specificeret i repository, så de hurtigt kan reagere på drift.
4. Meddelelser om konfigurationsdrift
De er nyttige i tilfælde, hvor administratoren hurtigt vil lære om tilfælde af konfigurationsdrift for hurtigt at kunne træffe passende foranstaltninger på egen hånd.
5. Manuel synkronisering af konfigurationer ved drift
Tillader administratoren at synkronisere OpenShift-klyngen med Git-lageret i tilfælde af konfigurationsdrift for hurtigt at returnere klyngen til en tidligere kendt tilstand.
6.Auto-synkronisering af konfigurationer ved drift
Administratoren kan også konfigurere OpenShift-klyngen til automatisk at synkronisere med depotet, når der detekteres en drift, så klyngekonfigurationen altid matcher konfigurationerne i Git.
7. Flere klynger - ét depot
Administratoren kan gemme konfigurationer af flere forskellige OpenShift-klynger i ét Git-lager og selektivt anvende dem efter behov.
8. Hierarki af klyngekonfigurationer (arv)
Administratoren kan indstille et hierarki af klyngekonfigurationer i lageret (stadie, prod, appportefølje osv. med arv). Med andre ord kan den bestemme, om konfigurationer skal anvendes på en eller flere klynger.
For eksempel, hvis en administrator indstiller hierarkiet "Produktionsklynger (prod) → System X-klynger → Produktionsklynger af system X" i Git-lageret, så anvendes en kombination af følgende konfigurationer på produktionsklyngerne i system X:
- Konfigurationer, der er fælles for alle produktionsklynger.
- Konfigurationer for System X-klyngen.
- Konfigurationer for X-systemproduktionsklyngen.
9. Skabeloner og konfigurationstilsidesættelser
Administratoren kan tilsidesætte et sæt nedarvede konfigurationer og deres værdier, for eksempel for at finjustere konfigurationen for specifikke klynger, som de vil blive anvendt på.
10. Selektiv inkludere og ekskludere for konfigurationer, applikationskonfigurationer
Administratoren kan indstille betingelserne for anvendelse eller ikke-anvendelse af visse konfigurationer til klynger med bestemte karakteristika.
11. Skabelonunderstøttelse
Udviklere vil drage fordel af muligheden for at vælge, hvordan applikationsressourcer vil blive defineret (Helm Chart, ren Kubernetes yaml osv.) for at bruge det mest passende format til hver specifik applikation.
GitOps-værktøjer på OpenShift-platformen
ArgoCD
ArgoCD implementerer External Resource Reconcile-modellen og tilbyder en centraliseret UI til at orkestrere en-til-mange-relationer mellem klynger og Git-lagre. Ulemperne ved dette program inkluderer manglende evne til at administrere applikationer, når ArgoCD ikke virker.
Flux
Flux implementerer en On-Cluster Resource Reconcile-model, og som følge heraf er der ingen centraliseret styring af definitionslageret, hvilket er et svagt punkt. På den anden side, netop på grund af manglen på centralisering, forbliver evnen til at administrere applikationer, selvom en klynge fejler.
Installation af ArgoCD på OpenShift
ArgoCD tilbyder en fremragende kommandolinjegrænseflade og webkonsol, så vi vil ikke dække Flux og andre alternativer her.
For at implementere ArgoCD på OpenShift 4-platformen skal du følge disse trin som klyngeadministrator:
Implementering af ArgoCD-komponenter på OpenShift-platformen
# 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 af ArgoCD Server, så den kan ses af 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=RedirectImplementering af 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/argocdÆndring af ArgoCD Server-administratoradgangskoden
# 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
Når du har gennemført disse trin, kan du arbejde med ArgoCD Server via ArgoCD WebUI-webkonsollen eller ArgoCD Cli-kommandolinjeværktøjet.
GitOps - Det er aldrig for sent
"Toget er gået" - det er, hvad de siger om en situation, hvor muligheden for at gøre noget forpasses. I tilfældet med OpenShift skaber ønsket om straks at tage denne seje nye platform i brug netop denne situation med styring og vedligeholdelse af ruter, udrulninger og andre OpenShift-objekter. Men er chancen altid helt tabt?
Fortsætter serien af artikler om , i dag viser vi dig, hvordan du transformerer en håndlavet applikation og dens ressourcer til en proces, hvor alt styres af GitOps-værktøjer. For at gøre dette vil vi først manuelt implementere httpd-applikationen. Skærmbilledet nedenfor viser, hvordan vi opretter et navneområde, implementering og service og derefter eksponerer denne tjeneste for at oprette 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åndlavet applikation. Nu skal det overføres under GitOps-administration uden tab af tilgængelighed. Kort sagt gør den dette:
- Opret et Git-lager til koden.
- Vi eksporterer vores nuværende objekter og uploader dem til Git-lageret.
- Valg og implementering af GitOps-værktøjer.
- Vi tilføjer vores lager til dette værktøjssæt.
- Vi definerer applikationen i vores GitOps-værktøjssæt.
- Vi udfører en testkørsel af applikationen ved hjælp af GitOps-værktøjssættet.
- Vi synkroniserer objekter ved hjælp af GitOps-værktøjssættet.
- Aktiver beskæring og automatisk synkronisering af objekter.
Som nævnt i det foregående , i GitOps er der én og kun én kilde til information om alle objekter i Kubernetes-klyngen(e) - Git-lageret. Dernæst går vi ud fra den forudsætning, at din organisation allerede bruger et Git-lager. Det kan være offentligt eller privat, men det skal være tilgængeligt for Kubernetes-klynger. Dette kan være det samme lager som for applikationskode eller et separat lager oprettet specifikt til implementeringer. Det anbefales at have strenge tilladelser i depotet, da hemmeligheder, ruter og andre sikkerhedsfølsomme ting vil blive gemt der.
I vores eksempel vil vi oprette et nyt offentligt lager på GitHub. Du kan kalde det hvad du vil, vi bruger navnet blogpost.
Hvis YAML-objektfilerne ikke blev gemt lokalt eller i Git, så bliver du nødt til at bruge oc eller kubectl binære filer. I skærmbilledet nedenfor anmoder vi om YAML for vores navneområde, implementering, service og rute. Før dette klonede vi det nyoprettede lager og cd ind 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.yamlLad os nu redigere filen deployment.yaml for at fjerne det felt, som Argo CD ikke kan synkronisere.
sed -i '/sgeneration: .*/d' deployment.yamlDesuden skal ruten ændres. Vi sætter først en multiline-variabel og erstatter derefter ingress: null med indholdet af den variabel.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlSå vi har sorteret filerne ud, det eneste, der er tilbage, er at gemme dem i Git-depotet. Hvorefter dette lager bliver den eneste informationskilde, og enhver manuell ændring af objekter bør være strengt forbudt.
git commit -am ‘initial commit of objects’
git push origin masterYderligere tager vi udgangspunkt i det faktum, at du allerede har installeret ArgoCD (hvordan man gør dette - se tidligere ). Derfor vil vi tilføje det lager, vi oprettede, til Argo-cd'en, der indeholder applikationskoden fra vores eksempel. Bare sørg for, at du angiver det nøjagtige lager, som du oprettede tidligere.
argocd repo add https://github.com/cooktheryan/blogpostLad os nu oprette applikationen. Applikationen sætter værdier, så GitOps-værktøjssættet forstår, hvilket lager og stier der skal bruges, hvilket OpenShift der er nødvendigt for at administrere objekter, hvilken specifik gren af lageret der er behov for, og om ressourcer skal auto-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 applikation er angivet i Argo-cd'en, begynder værktøjssættet at kontrollere allerede implementerede objekter i forhold til definitionerne i depotet. I vores eksempel er automatisk synkronisering og oprydning deaktiveret, så elementerne ændres ikke endnu. Bemærk venligst, at vores applikation i Argo CD-grænsefladen vil have status "Ude for synkronisering", fordi der ikke er nogen etiket, som ArgoCD leverer.
Det er derfor, når vi starter synkroniseringen lidt senere, vil objekterne ikke blive omplaceret.
Lad os nu lave en testkørsel for at sikre, at der ikke er fejl i vores filer.
argocd app sync simple-app --dry-runHvis der ikke er nogen fejl, kan du fortsætte til synkronisering.
argocd app sync simple-appEfter at have kørt kommandoen argocd get på vores applikation, skulle vi se, at applikationsstatussen er ændret til Sund eller Synkroniseret. Dette vil betyde, at alle ressourcer i Git-lageret nu svarer til de ressourcer, der allerede er blevet installeret.
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
... Nu kan du aktivere automatisk synkronisering og oprydning for at sikre, at intet oprettes manuelt, og at hver gang et objekt oprettes eller opdateres til lageret, vil der ske en implementering.
argocd app set simple-app --sync-policy automated --auto-prune
Så vi har med succes bragt en applikation under GitOps kontrol, som oprindeligt ikke brugte GitOps på nogen måde.
Kilde: www.habr.com