Idag kommer vi att prata om principerna och modellerna för GitOps, samt hur dessa modeller implementeras på OpenShift-plattformen. En interaktiv guide om detta ämne finns tillgänglig .
I ett nötskal är GitOps en uppsättning metoder för att använda Git pull-förfrågningar för att hantera infrastruktur och applikationskonfigurationer. Git-förrådet i GitOps behandlas som en enda informationskälla om systemets tillstånd, och alla ändringar av detta tillstånd är helt spårbara och granskningsbara.
Idén med ändringsspårning i GitOps är inte på något sätt ny; detta tillvägagångssätt har länge använts nästan universellt när man arbetar med applikationskällkod. GitOps implementerar helt enkelt liknande funktioner (recensioner, pull-förfrågningar, taggar, etc.) i hantering av infrastruktur och applikationskonfiguration och ger liknande fördelar som i fallet med källkodshantering.
Det finns ingen akademisk definition eller godkänd uppsättning regler för GitOps, bara en uppsättning principer som denna praxis bygger på:
- Den deklarativa beskrivningen av systemet lagras i Git-förvaret (konfigurationer, övervakning, etc.).
- Tillståndsändringar görs genom pull-förfrågningar.
- Tillståndet för körande system bringas i linje med data i förvaret med hjälp av Git push-förfrågningar.
GitOps principer
- Systemdefinitioner beskrivs som källkod
Systemkonfigurationen behandlas som kod så att den kan lagras och automatiskt versioneras i ett Git-förråd, som fungerar som en enda källa till sanning. Detta tillvägagångssätt gör det enkelt att rulla ut och återställa ändringar i system.
- Det önskade tillståndet och konfigurationen av systemen ställs in och versioneras i Git
Genom att lagra och versionera önskat systemtillstånd i Git kan vi enkelt rulla ut och återställa ändringar i system och applikationer. Vi kan också använda Gits säkerhetsmekanismer för att kontrollera kodägande och verifiera dess äkthet.
- Konfigurationsändringar kan tillämpas automatiskt via pull-förfrågningar
Med hjälp av Git pull-förfrågningar kan vi enkelt styra hur ändringar tillämpas på konfigurationer i förvaret. Till exempel kan de ges till andra teammedlemmar för granskning eller genomgå CI-tester, etc.
Och samtidigt finns det inget behov av att fördela administratörsbefogenheter åt vänster och höger. För att utföra konfigurationsändringar behöver användare bara lämpliga behörigheter i Git-förvaret där dessa konfigurationer lagras.
- Åtgärda problemet med okontrollerad drift av konfigurationer
När det önskade tillståndet för systemet har lagrats i ett Git-förråd, är allt vi behöver göra att hitta mjukvara som säkerställer att det aktuella tillståndet för systemet matchar dess önskade tillstånd. Om så inte är fallet bör den här programvaran - beroende på inställningarna - antingen eliminera avvikelsen på egen hand eller meddela oss om konfigurationsdrift.
GitOps-modeller för OpenShift
On-Cluster Resource Reconciler
Enligt denna modell har klustret en kontroller som ansvarar för att jämföra Kubernetes-resurser (YAML-filer) i Git-förvaret med de verkliga resurserna i klustret. Om avvikelser upptäcks skickar den registeransvarige meddelanden och vidtar eventuellt åtgärder för att rätta till avvikelserna. Denna GitOps-modell används i Anthos Config Management och Weaveworks Flux.
Extern resursavstämningsenhet (Push)
Den här modellen kan betraktas som en variant av den tidigare, när vi har en eller flera kontroller som ansvarar för att synkronisera resurser i paren "Git repository - Kubernetes-kluster". Skillnaden här är att varje hanterat kluster inte nödvändigtvis har sin egen separata kontroller. Git - k8s klusterpar definieras ofta som CRDs (custom resource definitions), som kan beskriva hur styrenheten ska utföra synkronisering. Inom denna modell jämför styrenheter Git-förvaret som specificeras i CRD med Kubernetes-klusterresurserna, som också specificeras i CRD, och utför lämpliga åtgärder baserat på resultaten av jämförelsen. I synnerhet används denna GitOps-modell i ArgoCD.
GitOps på OpenShift-plattformen
Administration av Kubernetes-infrastruktur med flera kluster
Med spridningen av Kubernetes och den växande populariteten för multimolnstrategier och edge computing ökar också det genomsnittliga antalet OpenShift-kluster per kund.
Till exempel, när du använder edge computing, kan en kunds kluster distribueras i hundratals eller till och med tusentals. Som ett resultat tvingas han hantera flera oberoende eller samordnade OpenShift-kluster i det offentliga molnet och på plats.
I det här fallet måste många problem lösas, särskilt:
- Kontrollera att klustren är i identiskt tillstånd (konfigurationer, övervakning, lagring, etc.)
- Återskapa (eller återställ) kluster baserat på ett känt tillstånd.
- Skapa nya kluster baserat på ett känt tillstånd.
- Rulla ut ändringar till flera OpenShift-kluster.
- Återställ ändringar över flera OpenShift-kluster.
- Länka mallkonfigurationer till olika miljöer.
Applikationskonfigurationer
Under sin livscykel passerar applikationer ofta genom en kedja av kluster (dev, stage, etc.) innan de hamnar i ett produktionskluster. På grund av krav på tillgänglighet och skalbarhet distribuerar kunder dessutom ofta applikationer över flera lokala kluster eller flera regioner i en offentlig molnplattform.
I det här fallet måste följande uppgifter lösas:
- Säkerställ förflyttning av applikationer (binärer, konfigurationer, etc.) mellan kluster (dev, scen, etc.).
- Rulla ut ändringar av applikationer (binära filer, konfigurationer, etc.) i flera OpenShift-kluster.
- Återställ ändringar i applikationer till ett tidigare känt tillstånd.
Användningsfall för OpenShift GitOps
1. Tillämpa ändringar från Git-förvaret
En klusteradministratör kan lagra OpenShift-klusterkonfigurationer i ett Git-förråd och automatiskt använda dem för att enkelt skapa nya kluster och föra dem till ett tillstånd som är identiskt med det kända tillståndet som är lagrat i Git-förvaret.
2. Synkronisering med Secret Manager
Administratören kommer också att dra nytta av möjligheten att synkronisera OpenShift-hemliga objekt med lämplig programvara som Vault för att hantera dem med hjälp av verktyg speciellt skapade för detta.
3. Kontroll av driftkonfigurationer
Administratören kommer bara att vara för om OpenShift GitOps själv identifierar och varnar för avvikelser mellan verkliga konfigurationer och de som anges i förvaret, så att de snabbt kan svara på drift.
4. Meddelanden om konfigurationsdrift
De är användbara i de fall administratören snabbt vill lära sig om fall av konfigurationsavvikelser för att snabbt kunna vidta lämpliga åtgärder på egen hand.
5. Manuell synkronisering av konfigurationer vid drift
Tillåter administratören att synkronisera OpenShift-klustret med Git-förvaret i händelse av konfigurationsdrift, för att snabbt återställa klustret till ett tidigare känt tillstånd.
6.Auto-synkronisering av konfigurationer vid drift
Administratören kan också konfigurera OpenShift-klustret för att automatiskt synkronisera med förvaret när en drift upptäcks, så att klusterkonfigurationen alltid matchar konfigurationerna i Git.
7. Flera kluster - ett förvar
Administratören kan lagra konfigurationer av flera olika OpenShift-kluster i ett Git-förråd och selektivt tillämpa dem efter behov.
8. Hierarki av klusterkonfigurationer (arv)
Administratören kan ställa in en hierarki av klusterkonfigurationer i arkivet (stage, prod, appportfölj, etc. med arv). Med andra ord kan den avgöra om konfigurationer ska tillämpas på ett eller flera kluster.
Till exempel, om en administratör ställer in hierarkin "Produktionskluster (prod) → System X-kluster → Produktionskluster för system X" i Git-förrådet, tillämpas en kombination av följande konfigurationer på produktionsklustren i system X:
- Konfigurationer som är gemensamma för alla produktionskluster.
- Konfigurationer för System X-klustret.
- Konfigurationer för X-systemets produktionskluster.
9. Mallar och åsidosättande av konfigurationer
Administratören kan åsidosätta en uppsättning ärvda konfigurationer och deras värden, till exempel för att finjustera konfigurationen för specifika kluster som de kommer att tillämpas på.
10. Selektivt inkludera och exkludera för konfigurationer, applikationskonfigurationer
Administratören kan ställa in villkoren för tillämpning eller icke-tillämpning av vissa konfigurationer till kluster med vissa egenskaper.
11. Mallstöd
Utvecklare kommer att dra nytta av möjligheten att välja hur applikationsresurser ska definieras (Helm Chart, ren Kubernetes yaml, etc.) för att använda det mest lämpliga formatet för varje specifik applikation.
GitOps-verktyg på OpenShift-plattformen
ArgoCD
ArgoCD implementerar External Resource Reconcile-modellen och erbjuder ett centraliserat användargränssnitt för orkestrering av en-till-många-relationer mellan kluster och Git-förråd. Nackdelarna med detta program inkluderar oförmågan att hantera applikationer när ArgoCD inte fungerar.
Flux
Flux implementerar en On-Cluster Resource Reconcile-modell och som ett resultat finns det ingen centraliserad hantering av definitionsförrådet, vilket är en svag punkt. Å andra sidan, just på grund av bristen på centralisering, kvarstår förmågan att hantera applikationer även om ett kluster misslyckas.
Installerar ArgoCD på OpenShift
ArgoCD erbjuder ett utmärkt kommandoradsgränssnitt och webbkonsol, så vi kommer inte att täcka Flux och andra alternativ här.
För att distribuera ArgoCD på OpenShift 4-plattformen, följ dessa steg som klusteradministratör:
Distribuera 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}')Förbättring av ArgoCD Server så att den kan ses 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=RedirectInstallera 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 ArgoCD Servers administratörslösenord
# 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 slutfört dessa steg kan du arbeta med ArgoCD Server via ArgoCD WebUI webbkonsol eller ArgoCD Cli kommandoradsverktyg.
GitOps - Det är aldrig för sent
"Tåget har gått" - det här är vad de säger om en situation när möjligheten att göra något missas. När det gäller OpenShift skapar viljan att omedelbart börja använda denna coola nya plattform ofta just denna situation med hantering och underhåll av rutter, utplaceringar och andra OpenShift-objekt. Men är chansen alltid helt förlorad?
Fortsätter artikelserien om , idag visar vi dig hur du omvandlar en handgjord applikation och dess resurser till en process där allt hanteras av GitOps-verktyg. För att göra detta kommer vi först att manuellt distribuera httpd-applikationen. Skärmdumpen nedan visar hur vi skapar ett namnområde, distribution och tjänst, och sedan exponerar den här tjänsten 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-appSå vi har en handgjord applikation. Nu måste den överföras under GitOps-hantering utan förlust av tillgänglighet. Kort sagt, det gör så här:
- Skapa ett Git-förråd för koden.
- Vi exporterar våra nuvarande objekt och laddar upp dem till Git-förvaret.
- Välja och distribuera GitOps-verktyg.
- Vi lägger till vårt arkiv till denna verktygslåda.
- Vi definierar applikationen i vår GitOps-verktygslåda.
- Vi utför en testkörning av applikationen med hjälp av GitOps verktygslåda.
- Vi synkroniserar objekt med hjälp av GitOps verktygslåda.
- Aktivera beskärning och automatisk synkronisering av objekt.
Som redan nämnts i föregående , i GitOps finns det en och endast en informationskälla om alla objekt i Kubernetes-klustret/-klustret - Git-förrådet. Därefter utgår vi från premissen att din organisation redan använder ett Git-förråd. Det kan vara offentligt eller privat, men det måste vara tillgängligt för Kubernetes-kluster. Detta kan vara samma arkiv som för applikationskod, eller ett separat arkiv skapat specifikt för distributioner. Det rekommenderas att ha strikta behörigheter i förvaret eftersom hemligheter, rutter och andra säkerhetskänsliga saker kommer att lagras där.
I vårt exempel kommer vi att skapa ett nytt offentligt arkiv på GitHub. Du kan kalla det vad du vill, vi använder namnet blogginlägg.
Om YAML-objektfilerna inte lagrades lokalt eller i Git, måste du använda binärfilerna oc eller kubectl. I skärmdumpen nedan begär vi YAML för vårt namnområde, distribution, tjänst och rutt. Innan detta klonade vi det nyskapade arkivet och cd in 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.yamlLåt oss nu redigera filen deployment.yaml för att ta bort fältet som Argo CD inte kan synkronisera.
sed -i '/sgeneration: .*/d' deployment.yamlDessutom behöver rutten ändras. Vi ställer först in en flerradsvariabel och ersätter sedan ingress: null med innehållet i den variabeln.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlSå vi har sorterat ut filerna, allt som återstår är att spara dem i Git-förvaret. Därefter blir detta arkiv den enda informationskällan, och alla manuella ändringar av objekt bör vara strängt förbjudna.
git commit -am ‘initial commit of objects’
git push origin masterVidare utgår vi från det faktum att du redan har distribuerat ArgoCD (hur man gör detta - se föregående ). Därför kommer vi att lägga till arkivet vi skapade till Argo-cd:n, som innehåller applikationskoden från vårt exempel. Se bara till att du anger det exakta arkivet som du skapade tidigare.
argocd repo add https://github.com/cooktheryan/blogpostLåt oss nu skapa applikationen. Applikationen ställer in värden så att GitOps verktygslåda förstår vilket arkiv och sökvägar som ska användas, vilket OpenShift som behövs för att hantera objekt, vilken specifik gren av arkivet som behövs och om resurser ska synkroniseras automatiskt.
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 ett program har specificerats i Argo-cd:n börjar verktygslådan kontrollera redan distribuerade objekt mot definitionerna i förvaret. I vårt exempel är automatisk synkronisering och rengöring inaktiverade, så elementen ändras inte ännu. Observera att i Argo CD-gränssnittet kommer vår applikation att ha statusen "Out of Sync" eftersom det inte finns någon etikett som ArgoCD tillhandahåller.
Det är därför när vi startar synkroniseringen lite senare, kommer objekten inte att distribueras om.
Låt oss nu göra en testkörning för att se till att det inte finns några fel i våra filer.
argocd app sync simple-app --dry-runOm det inte finns några fel kan du fortsätta till synkroniseringen.
argocd app sync simple-appEfter att ha kört kommandot argocd get på vår applikation bör vi se att applikationsstatusen har ändrats till Healthy eller Synced. Detta kommer att innebära att alla resurser i Git-förvaret nu motsvarar 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: <none>
Sync Status: Synced to master (60e1678)
Health Status: Healthy
... Nu kan du aktivera automatisk synkronisering och rensning för att säkerställa att ingenting skapas manuellt och att varje gång ett objekt skapas eller uppdateras till förvaret kommer en distribution att ske.
argocd app set simple-app --sync-policy automated --auto-prune
Så vi har framgångsrikt tagit med en applikation under GitOps-kontroll som från början inte använde GitOps på något sätt.
Källa: will.com