Introduktion till GitOps för OpenShift

Idag kommer vi att prata om grunderna och modellerna för GitOps, samt hur dessa modeller implementeras på plattformen OpenShift. En interaktiv guide om detta ämne är tillgänglig. via länken.

Kort sagt, GitOps är en uppsättning praktiska metoder för att använda Git pull-requests för att hantera konfigurationer av infrastruktur och applikationer. Git-förvaret inom GitOps betraktas som den enda källan till information om systemets tillstånd, och alla förändringar av detta tillstånd spåras fullständigt och kan auditeras.

Idén om att spåra ändringar i GitOps är inte ny, denna metod har länge och nästan överallt tillämpats vid arbete med källkod för applikationer. GitOps implementerar helt enkelt liknande funktioner (granskningar, pull-requests, taggar etc.) vid hantering av konfigurationer för infrastruktur och applikationer och ger liknande fördelar som vid hantering av källkod.

Det finns ingen akademisk definition eller en uppsättning godkända regler för GitOps, endast en uppsättning principer som denna praxis bygger på:

• Systemets deklarativa beskrivning lagras i Git-förvaret (konfigurationer, övervakning etc.).
• Ändringar i tillståndet genomförs via pull-requests.
• Tillståndet av de fungerande systemen anpassas efter uppgifterna i förvaret med hjälp av Git push-requests.

Principer för GitOps

• Definitioner av system beskrivs som källkod.

Systemkonfiguration betraktas som kod, vilket gör att den kan lagras och automatiskt versioneras i Git-förvaret, som fungerar som den enda sanna källan. Denna metod möjliggör enkel utrullning (rollout) och återställning (rollback) av förändringar i systemen.

• Det önskade tillståndet och konfigurationerna för systemen definieras och versioneras i Git.

Genom att lagra och versionera det önskade tillståndet för systemen i Git, får vi möjlighet att enkelt rulla ut och återställa förändringar i systemen och applikationerna. Vi kan också använda Gits säkerhetsmekanismer för att kontrollera ägarskap av koden och bekräfta dess äkthet.

• Ändringar i konfigurationerna kan automatiskt tillämpas via pull-requests.

Genom att använda Git-pullförfrågningar kan vi enkelt hantera hur ändringar tillämpas på konfigurationer i repon. Till exempel kan de överlämnas för granskning till andra teammedlemmar eller köras genom CI-tester.

Och det behövs inte ge administrativa rättigheter hit och dit. För att genomföra commit förändringar i konfigurationen räcker det med att användarna har de nödvändiga rättigheterna i Git-repon där dessa konfigurationer lagras.

• Att åtgärda problemet med okontrollerad konfigurationsdrift

När det önskade tillståndet av systemet lagras i ett Git-repo, återstår det bara att hitta mjukvara som kontrollerar att det aktuella tillståndet av systemet överensstämmer med dess önskade tillstånd. Om det inte gör det, ska denna mjukvara - beroende på inställningarna - antingen själv åtgärda avvikelsen eller meddela oss om konfigurationsdriften.

GitOps-modeller för OpenShift

On-Cluster Resource Reconciller

Enligt denna modell finns det en kontrollör i klustret som ansvarar för att jämföra Kubernetes-resurser (YAML-filer) i Git-repo med de verkliga resurserna i klustret. Vid upptäckta avvikelser skickar kontrollören meddelanden och kan eventuellt vidta åtgärder för att åtgärda avvikelserna. Denna GitOps-modell används i Anthos Config Management och Weaveworks Flux.

External Resource Reconciler (Push)

Denna modell kan ses som en variant av den föregående, där vi har en eller flera kontrollörer ansvariga för att synkronisera resurser i paren "Git-repo - Kubernetes-kluster". Skillnaden här är att det i varje hanterat kluster inte nödvändigtvis måste finnas en egen kontrollör. Paren "Git - k8s-kluster" definieras ofta som CRD-beskrivningar (custom resources definition), där man kan beskriva hur kontrollören ska utföra synkronisering. Inom ramen för denna modell jämför kontrollörerna Git-repo, angivet i CRD, med de resurser i Kubernetes-klustret som också anges i CRD, och utför lämpliga åtgärder baserat på jämförelsens resultat. Särskilt används en sådan GitOps-modell i ArgoCD.

GitOps på OpenShift-plattformen

Administration av multiklustern Kubernetes-infrastruktur

Med spridningen av Kubernetes och den växande populariteten för multi-molnstrategier och edge computing ökar också det genomsnittliga antalet OpenShift-kluster per kund.

Till exempel, vid användning av edge computing kan en kunds kluster distribueras i hundratal eller till och med tusental. Som ett resultat tvingas kunden att hantera flera oberoende eller samordnade OpenShift-kluster i både offentliga moln och lokalt.

I detta sammanhang måste många problem lösas, bland annat:

• Övervaka att klustren är i identiskt tillstånd (konfigurationer, övervakning, lagring etc.).
• Återskapa (eller återställa) kluster till ett känt tillstånd.
• Skapa nya kluster utifrån ett känt tillstånd.
• Applicera förändringar på flera OpenShift-kluster.
• Återställa förändringar på flera OpenShift-kluster.
• Koppla samman malldefinierade konfigurationer med olika miljöer.

Applikationskonfigurationer

Under sin livscykel går applikationer ofta igenom en kedja av kluster (dev, staging osv.) innan de når produktionsklustret. Dessutom, på grund av tillgänglighets- och skalbarhetskrav, distribuerar kunder ofta applikationer direkt till flera kluster on-premise eller i flera regioner av en offentlig molnplattform.

Därför måste följande uppgifter lösas:

• Säkerställa att applikationer (binarier, konfigurationer etc.) rör sig mellan kluster (dev, staging osv.).
• Applicera förändringar i applikationer (binarier, konfigurationer osv.) i flera OpenShift-kluster.
• Återställa förändringar i applikationer till det tidigare kända tillståndet.

Användningsscenarier för OpenShift GitOps

1. Tillämpning av förändringar från Git-repository

Klusteradministratören kan lagra OpenShift-klusterkonfigurationer i ett Git-repository och automatiskt tillämpa dem för att utan problem skapa nya kluster och återskapa dem till ett tillstånd som är identiskt med det kända tillståndet som lagras i Git-repository.

2. Synkronisering med Secret Manager

Administratören kan också ha nytta av möjligheten att synkronisera secret-objekt i OpenShift med motsvarande programvara som Vault, för att hantera dem med speciellt utformade verktyg.

3. Kontroll av konfigurationsdrift

Administratören skulle bara vara positiv till att OpenShift GitOps själv identifierar och varnar om avvikelser mellan de aktuella konfigurationerna och de som anges i repositoryt, så att det snabbt kan reageras på drift.

4. Meddelanden om konfigurationsdrift

De är användbara när administratören vill få snabb information om driftfall av konfigurationer för att kunna vidta lämpliga åtgärder omedelbart.

5. Manuell synkronisering av konfigurationer vid drift

Möjliggör för administratören att synkronisera OpenShift-klustret med Git-repositoriet vid drift av konfigurationer för att snabbt återställa klustret till ett tidigare känt tillstånd.

6. Autosynkronisering av konfigurationer vid drift

Administratören kan också ställa in OpenShift-klustret för automatisk synkronisering med repositoriet vid upptäckte driftfall, så att klusterkonfigurationen alltid motsvarar konfigurationerna i Git.

7. Flera kluster – ett repository

Administratören kan lagra konfigurationer för flera olika OpenShift-kluster i ett och samma Git-repository och selektivt tillämpa dem vid behov.

8. Hierarki av klusterkonfigurationer (ärvande)

Administratören kan definiera en hierarki av klusterkonfigurationer i repositoriet (staging, produktion, appportfölj osv. med ärvande). Med andra ord kan han eller hon bestämma hur konfigurationer ska tillämpas – på ett eller flera kluster.

Till exempel, om administratören definierar en hierarki i Git-repositoriet som 'Produktionskluster (prod) → System X-kluster → Produktionskluster för system X', kommer följande konfigurationer att tillämpas på produktionskluster för system X:

• Konfigurationer gemensamma för alla produktionskluster.
• Konfigurationer för system X-klustret.
• Konfigurationer för produktionsklustret för system X.

9. Mallar och överskrivning av konfigurationer

Administratören kan överskrida uppsättningen av ärvda konfigurationer och deras värden för att mer noggrant anpassa konfigurationen för specifika kluster som de ska tillämpas på.

10. Selektiva inkluderingar och exkluderingar av konfigurationer, applikationskonfigurationer

Administratören kan ställa in villkor för tillämpning eller uteblivande av vissa konfigurationer på kluster med specifika egenskaper.

11. Stöd för mallar

Utvecklare kommer att ha nytta av möjligheten att välja hur applikationsresurser ska definieras (Helm Chart, ren Kubernetes YAML osv.) för att använda det mest lämpliga formatet för varje specifik applikation.

GitOps-verktyg på OpenShift-plattformen

ArgoCD

ArgoCD implementerar modellen External Resource Reconcile och erbjuder ett centraliserat gränssnitt för orkestrering av relationer mellan kluster och Git-repositorier enligt en "en till många"-modell. En nackdel med detta program är oförmågan att hantera applikationer när ArgoCD inte fungerar.

Officiell webbplats

Flux

Flux implementerar modellen On-Cluster Resource Reconcile, och som en följd av detta finns det ingen centraliserad hantering av definitionsrepositoriet, vilket är en svag punkt. Å andra sidan, just på grund av avsaknaden av centralisering, kan möjligheten att hantera applikationer bibehållas även när ett kluster går ner.

Officiell webbplats

Installation av ArgoCD på OpenShift

ArgoCD erbjuder ett utmärkt kommandoradsgränssnitt och webbkonsol, därför kommer vi inte att diskutera Flux och andra alternativ här.

För att distribuera ArgoCD på OpenShift 4, följ dessa steg som klusteradministratör:

Distribution av 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}')

Justera ArgoCD Server så att den syns 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=Redirect

Distribution av 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

Ändra administratörslösenordet för 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

Efter att ha genomfört dessa steg kan ArgoCD Server användas via ArgoCD WebUI eller kommandoradsverktyget ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – det är aldrig för sent

"Tåget har gått" – så säger man om en situation när möjligheten att göra något har gått förlorad. När det gäller OpenShift skapar ofta viljan att omedelbart börja använda denna nya, coola plattform just en sådan situation med hantering och underhåll av rutter, deployment och andra OpenShift-objekt. Men är chansen alltid helt förlorad?

Vi fortsätter med vår serie artiklar om GitOps, idag visar vi hur man omvandlar en manuellt skapad applikation och dess resurser till en process där allt hanteras av GitOps-verktyget. För detta kommer vi först att manuellt distribuera applikationen httpd. På bilden nedan visas hur vi skapar ett namnrum, en deployment och en tjänst, och sedan exponerar vi denna tjänst för att skapa en rutt.

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

Så, vi har en manuellt skapad applikation. Nu måste den övergå till att hanteras av GitOps utan att tappa tillgängligheten. Kort sagt, så här gör man:

• Skapa ett Git-repositorium för koden.
• Exportera våra nuvarande objekt och ladda upp dem till Git-repositoriet.
• Välj och distribuera GitOps-verktygen.
• Lägg till vårt repo i dessa verktyg.
• Definiera applikationen i våra GitOps-verktyg.
• Genomför en testkörning av applikationen med hjälp av GitOps-verktygen.
• Synkronisera objekten med hjälp av GitOps-verktygen.
• Aktivera rensning (pruning) och automatisk synkronisering av objekt.

Som nämnts tidigare artikeln, i GitOps finns det en och endast en källa till information om alla objekt i Kubernetes-kluster(n) – Git-repositoriet. Vidare utgår vi från att din organisation redan använder ett Git-repo. Det kan vara offentligt eller privat, men det måste nödvändigtvis vara tillgängligt för Kubernetes-kluster. Detta kan vara samma repository som för kodbaserna, eller ett separat repository skapat speciellt för distributioner. Det rekommenderas att ha strikta behörigheter i repositoriet eftersom det kommer att lagra sekretessobjekt, rutter och andra säkerhetskänsliga saker.

I vårt exempel kommer vi att skapa ett nytt offentligt repository på GitHub. Du kan namnge det hur som helst; vi använder namnet blogpost.

Om YAML-filerna för objekten inte lagrades lokalt eller i Git, måste vi använda binärerna oc eller kubectl. På skärmdumpen nedan begär vi YAML för vårt namnrymden, distributionen, tjänsten och rutten. Innan dess klonade vi det nyss skapade repositoriet och gick in i det med kommandot cd.

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

Nu ska vi redigera filen deployment.yaml för att ta bort fältet som Argo CD inte kan synkronisera.

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

Dessutom måste vi ändra rutten. Först sätter vi en fler-radig variabel och sedan ersätter vi ingress: null med innehållet i denna variabel.

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

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

Så, nu har vi hanterat filerna, det återstår att spara dem i Git-repositoriet. Efter det blir detta repository den enda källan till information, och alla manuella ändringar av objekten ska strikt förbjudas.

git commit -am 'initial commit of objects'
git push origin master

Vi utgår från att ArgoCD redan är installerat (för hur man gör det, se föregående) inlägg). Därför lägger vi till det repository vi skapade i Argo CD, som innehåller koden för vår applikation i vårt exempel. Se bara till att du anger just det repository som du skapade tidigare.

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

Nu skapar vi applikationen. Applikationen definierar värden så att GitOps-verktyget förstår vilket repository och sökvägar som ska användas, vilken OpenShift som behövs för att hantera objekten, samt vilken specifik gren av repositoryt som krävs, och om resursautokopiering ska utföras.

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 applikationen har definierats i Argo CD börjar detta verktyg att kontrollera redan distribuerade objekt för att se om de överensstämmer med definitionerna i repositoryt. I vårt exempel är autokopiering och rensning inaktiverade, så elementen förändras ännu inte. Observera att i Argo CD:s gränssnitt kommer vår applikation att ha statusen 'Out of Sync', eftersom det inte finns någon label som sätts av ArgoCD.
Det är just därför, när vi senare kör synkronisering, så kommer inga återdistribueringar av objekten att utföras.

Nu kör vi ett test för att säkerställa att det inte finns några fel i våra filer.

argocd app sync simple-app --dry-run

Om det inte finns några fel kan vi gå vidare till synkroniseringen.

argocd app sync simple-app

Efter att ha kört kommandot argocd get för vår applikation, bör vi se att applikationens status ändrats till Healthy eller Synced. Detta kommer att betyda att alla resurser i Git-repositoryt nu matchar de resurser som redan har distribuerats.

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

Nu kan vi aktivera autokopiering och rensning för att säkerställa att inget skapas manuellt och att varje gång ett objekt skapas eller uppdateras i repositoryt kommer en distribution att utföras.

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

Så, vi har framgångsrikt överfört en applikation under GitOps, som från början inte använde GitOps på något sätt.

Källa: habr.com