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 .
Kort sagt er GitOps et sæt praksisser til at bruge Git pull-anmodninger til at administrere infrastruktur og applikationskonfigurationer. Inden for GitOps behandles et Git-lager som en enkelt kilde til information om systemets tilstand, og alle ændringer i denne tilstand spores fuldt ud og kan revideres.
Ideen om at spore ændringer i GitOps er slet ikke ny; denne tilgang har længe været brugt næsten overalt, når man arbejder med kildekoden til applikationer. GitOps implementerer simpelthen lignende funktioner (anmeldelser, pull-anmodninger, tags osv.) til administration af infrastruktur og applikationskonfiguration og giver lignende fordele som kildekodestyring.
Der er ingen akademisk definition eller sæt regler for GitOps, kun et sæt principper, der styrer praksis:
- Den deklarative beskrivelse af systemet er gemt i Git repository (konfigurationer, overvågning osv.).
- Tilstandsændringer foretages via 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 gemmes 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 til systemer.
- Den ønskede tilstand og konfiguration af systemer er defineret og versioneret i Git
Ved at gemme og versionere den ønskede tilstand af systemer i Git, kan vi nemt rulle frem og tilbage ændringer af systemer og applikationer. Vi kan også bruge Gits sikkerhedsmekanismer til at kontrollere kodeejerskab og verificere dens ægthed.
- Konfigurationsændringer kan anvendes automatisk ved hjælp af pull-anmodninger
Ved at bruge 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 der er ingen grund til at uddele administratorbeføjelser til venstre og højre. For at foretage ændringer til en konfiguration behøver brugere kun de relevante tilladelser i Git-lageret, hvor disse konfigurationer er gemt.
- Løsning af ukontrolleret konfigurationsdriftsproblem
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 rette uoverensstemmelsen på egen hånd eller give os besked om konfigurationsdriften.
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 de faktiske klyngressourcer. Hvis der opdages uoverensstemmelser, sender controlleren meddelelser og kan tage skridt til 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, hvor vi har en eller flere controllere, der er ansvarlige for at synkronisere ressourcer i par “Git repository – Kubernetes cluster”. Forskellen her er, at hver administreret klynge ikke nødvendigvis behøver at have sin egen separate controller. Git - k8s klyngepar er ofte defineret som brugerdefinerede ressourcedefinitioner (CRD'er), der kan beskrive, hvordan controlleren skal udføre synkronisering. I denne model sammenligner controllere Git-lageret specificeret i CRD'en med Kubernetes-klyngressourcerne, der også er specificeret i CRD'en, og udfører passende handlinger baseret på sammenligningsresultaterne. Især en sådan GitOps-model bruges i ArgoCD.
GitOps på OpenShift-platformen
Administration af multi-cluster Kubernetes infrastruktur
Med vedtagelsen 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, med edge computing, kan en enkelt 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.
Samtidig skal en masse problemer løses, især:
- Sørg for, at klynger er i identisk tilstand (konfigurationer, overvågning, lagring osv.)
- Genskab (eller gendan) klynger fra en kendt tilstand.
- Opret nye klynger baseret på 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 når produktionsklyngen. På grund af tilgængeligheds- og skalerbarhedskrav implementerer kunder desuden ofte applikationer på tværs af flere on-premise-klynger eller offentlige cloud-platformsregioner.
I dette tilfælde skal følgende opgaver løses:
- Giver bevægelse af applikationer (binære filer, konfigurationer osv.) mellem klynger (dev, scene osv.).
- Udrul ændringer til applikationer (binære filer, konfigurationer osv.) på tværs af flere OpenShift-klynger.
- Rul ændringer i applikationer tilbage til en tidligere kendt tilstand.
OpenShift GitOps Use Cases
1. Anvendelse af ændringer fra et Git-lager
En klyngeadministrator kan gemme OpenShift-klyngekonfigurationer i et Git-lager og automatisk anvende dem til ubesværet at skabe nye klynger og bringe dem til en tilstand, der er identisk med en kendt tilstand, der er gemt i et Git-lager.
2. Synkronisering med Secret Manager
En administrator vil også drage fordel af muligheden for at synkronisere OpenShift-hemmeligheder med passende software som Vault for at administrere dem ved hjælp af værktøjer, der er specielt designet til dette formål.
3. Konfiguration afdriftskontrol
Administratoren vil være alt for det, hvis OpenShift GitOps selv vil opdage og advare om uoverensstemmelser mellem reelle konfigurationer og dem, der er specificeret i repository, så det vil være muligt at reagere med det samme på drift.
4. Konfigurationsdriftsmeddelelser
De er nyttige, når administratoren hurtigt vil lære om tilfælde af konfigurationsdrift for hurtigt at træffe passende foranstaltninger uafhængigt.
5. Manuel synkronisering af konfigurationer under drifting
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 under drifting
Administratoren kan også konfigurere OpenShift-klyngen til automatisk at synkronisere med repository, når drift detekteres, så klyngekonfigurationen altid matcher konfigurationerne i Git.
7. Flere klynger – ét lager
En administrator kan gemme konfigurationer af flere forskellige OpenShift-klynger i et enkelt Git-lager og selektivt anvende dem efter behov.
8. Hierarki af klyngekonfigurationer (arv)
Administratoren kan definere 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 definerer et hierarki i et Git-lager: "Produktionsklynger (prod) → Klynger af system X → Produktionsklynger af system X", så kombineres følgende konfigurationer for produktionsklynger i system X:
- Konfigurationer, der er fælles for alle produktionsklynger.
- Konfigurationer for X-systemklyngen.
- Konfigurationer for produktionsklyngen i X-systemet.
9. Skabeloner og tilsidesættende konfigurationer
Administratoren kan tilsidesætte sættet af nedarvede konfigurationer og deres værdier, for eksempel for at finjustere konfigurationen for specifikke klynger, som de vil blive anvendt på.
10. Selektiv inkluderer og udelukker for konfigurationer, applikationskonfigurationer
Administratoren kan indstille betingelser for at anvende eller ikke anvende bestemte konfigurationer på klynger med bestemte karakteristika.
11. Skabelonunderstøttelse
Udviklere vil drage fordel af muligheden for at vælge, hvordan applikationsressourcer defineres (Helm Chart, almindelig Kubernetes yaml osv.) for at bruge det mest passende format til hver specifik applikation.
GitOps-værktøjer på OpenShift
ArgoCD
ArgoCD implementerer External Resource Reconcile-modellen og giver 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 kører.
Flux
Flux implementerer On-Cluster Resource Reconcile-modellen, og som følge heraf er der ingen centraliseret styring af definitionslageret, hvilket er en svaghed. På den anden side er det netop på grund af den manglende centralisering, at muligheden for at administrere applikationer opretholdes, selvom én klynge svigter.
Installation af ArgoCD på OpenShift
ArgoCD tilbyder en fantastisk kommandolinjegrænseflade og webkonsol, så vi vil ikke dække Flux og andre alternativer her.
For at implementere ArgoCD på OpenShift 4 skal du udføre følgende trin som klyngeadministrator:
Implementering af ArgoCD-komponenter på 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}')Ændring 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 Admin Password
# 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" er, hvad de siger om en situation, hvor muligheden for at gøre noget er gået glip af. I tilfældet med OpenShift skaber ønsket om straks at begynde at bruge denne nye seje platform ofte netop denne situation med styring og vedligeholdelse af ruter, implementeringer og andre OpenShift-objekter. Men er chancen altid endelig 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 bringes under GitOps-administration uden at miste 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.
- Lad os tilføje vores lager til dette værktøjssæt.
- Vi definerer en applikation i vores GitOps-værktøjssæt.
- Vi udfører en testkørsel af applikationen ved hjælp af GitOps-værktøjssættet.
- Synkroniser objekter ved hjælp af GitOps-værktøjer.
- Vi muliggør beskæring og autosynkronisering af objekter.
Som allerede 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 antager vi, 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 applikationskoden eller et separat lager oprettet specifikt til implementeringer. Det anbefales at have strenge tilladelser på depotet, da det vil gemme hemmeligheder, ruter og andre sikkerhedsfølsomme ting.
I vores eksempel vil vi oprette et nyt offentligt lager på GitHub. Du kan kalde det hvad du vil, vi bruger navnet blogpost.
Hvis objektet YAML-filer ikke blev gemt lokalt eller i Git, bliver du nødt til at bruge oc eller kubectl binære filer. På skærmbilledet nedenfor anmoder vi om YAML for vores navneområde, implementering, service og rute. Før det 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. Først definerer vi en multi-line 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 fra, alt der er tilbage er at gemme dem i Git-lageret. 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 går vi ud fra det faktum, at du allerede har ArgoCD installeret (hvordan man gør dette – se forrige ). Lad os derfor tilføje det lager, vi oprettede, der indeholder applikationskoden fra vores eksempel til Argo CD. Bare sørg for at angive det nøjagtige lager, du oprettede tidligere.
argocd repo add https://github.com/cooktheryan/blogpostLad os nu oprette applikationen. Applikationen sætter værdier, så GitOps-værktøjet forstår, hvilket depot og stier, der skal bruges, hvilket OpenShift der er nødvendigt for at administrere objekter, hvilken specifik depotgren er nødvendig, og om auto-synkronisering af ressourcer skal udføres.
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 defineret i Argo CD, begynder værktøjet at kontrollere de installerede 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 i Argo CD-grænsefladen vil vores applikation have status "Ude for synkronisering", fordi der ikke er nogen etiket, som ArgoCD leverer.
Det er derfor, når vi kører synkronisering 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 matcher de ressourcer, der allerede er 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 i lageret, udføres en implementering.
argocd app set simple-app --sync-policy automated --auto-prune Så vi har migreret en applikation, der ikke oprindeligt brugte GitOps, til GitOps-administration.
Kilde: www.habr.com
