Inleiding tot GitOps voor OpenShift

Vandaag bespreken we de principes en modellen van GitOps, evenals hoe deze modellen worden geïmplementeerd op het OpenShift-platform. Een interactieve handleiding over dit onderwerp is beschikbaar. via de link.

Kort gezegd, GitOps is een set van praktische methoden voor het gebruik van Git-pullverzoeken om de configuraties van infrastructuur en applicaties te beheren. Een Git-repository binnen GitOps wordt beschouwd als de enkele bron van waarheid over de status van het systeem, waarbij alle wijzigingen aan deze status volledig kunnen worden gevolgd en geauditeerd.

Het idee van het volgen van wijzigingen in GitOps is niet nieuw; deze aanpak wordt al geruime tijd en bijna overal toegepast bij het werken met applicatiecode. GitOps implementeert eenvoudigweg soortgelijke functies (review-controles, pull-verzoeken, tags, enz.) bij het beheren van configuraties van infrastructuur en applicaties, en biedt vergelijkbare voordelen als bij het beheren van broncode.

Voor GitOps bestaat er geen academische definitie of goedgekeurde set regels, slechts een reeks principes waarop deze praktijk is gebaseerd:

• De declaratieve beschrijving van het systeem wordt opgeslagen in een Git-repository (configuraties, monitoring, enz.).
• Wijzigingen in de status worden uitgevoerd via pull-verzoeken.
• De status van actieve systemen wordt in overeenstemming gebracht met de gegevens in de repository via Git-pushverzoeken.

De principes van GitOps

• Systeemdefinities worden beschreven als broncode

Configuratie van systemen wordt beschouwd als code, zodat deze kan worden opgeslagen en automatisch versiebeheer kan krijgen in een Git-repository, die fungeert als de enige bron van waarheid. Deze aanpak maakt het gemakkelijk om wijzigingen in systemen door te voeren (rollout) en terug te draaien (rollback).

• De gewenste status en configuratie van systemen worden gedefinieerd en versiebeheer in Git.

Door de gewenste status van systemen op te slaan en te versioneren in Git, krijgen we de mogelijkheid om wijzigingen in systemen en applicaties gemakkelijk door te voeren en terug te draaien. We kunnen ook de beveiligingsmechanismen van Git gebruiken voor het beheer van code-eigendom en authenticiteitsbevestiging.

• Wijzigingen in configuraties kunnen automatisch worden toegepast via pull-verzoeken.

Met Git-pullverzoeken kunnen we gemakkelijk beheren hoe wijzigingen worden toegepast op configuraties in de repository. Bijvoorbeeld, ze kunnen ter beoordeling aan andere teamleden worden gegeven of door CI-tests worden gehaald.

En daarbij hoeft er geen admin-rechten te worden uitgedeeld. Om wijzigingen in de configuratie vast te leggen, hebben gebruikers voldoende bevoegdheden nodig in de Git-repository waarin deze configuraties worden opgeslagen.

• Het probleem van ongecontroleerde configuratiedrift oplossen

Wanneer de gewenste staat van het systeem in de Git-repository wordt opgeslagen, hoeven we alleen maar software te vinden die controleert of de huidige staat van het systeem overeenkomt met de gewenste staat. Als dat niet het geval is, moet deze software - afhankelijk van de instellingen - ofwel het verschil automatisch verhelpen, ofwel ons waarschuwen voor de configuratiedrift.

GitOps-modellen voor OpenShift

On-Cluster Resource Reconciler

Volgens dit model is er in de cluster een controller verantwoordelijk voor het vergelijken van Kubernetes-resources (YAML-bestanden) in de Git-repository met de werkelijke resources van de cluster. Bij het ontdekken van discrepanties stuurt de controller meldingen en neemt wellicht maatregelen om de verschillen te verhelpen. Dit GitOps-model wordt gebruikt in Anthos Config Management en Weaveworks Flux.

External Resource Reconciler (Push)

Dit model kan worden gezien als een variant van het vorige, waarbij we een of meerdere controllers hebben die verantwoordelijk zijn voor de synchronisatie van resources in paren 'Git-repository - Kubernetes-cluster'. Het verschil hier is dat in elke beheerde cluster niet per se een aparte controller aanwezig hoeft te zijn. De paren 'Git - k8s-cluster' worden vaak gedefinieerd als CRD-beschrijvingen (custom resources definition), waarin kan worden beschreven hoe de controller de synchronisatie moet uitvoeren. In dit model vergelijken controllers de Git-repository zoals aangegeven in de CRD, met de Kubernetes-resources die ook in de CRD zijn vastgelegd, en voeren ze de bijbehorende acties uit op basis van de vergelijking. Dit specifieke GitOps-model wordt gebruikt in ArgoCD.

GitOps op het OpenShift-platform

Beheer van multi-cluster Kubernetes-infrastructuur

Met de verspreiding van Kubernetes en de groei van multi-cloudstrategieën en edge computing neemt ook het gemiddelde aantal OpenShift-clusters per klant toe.

Bijvoorbeeld, bij het gebruik van edge computing kunnen clusters van één klant in honderden of zelfs duizenden worden uitgerold. Dit dwingt hen om meerdere onafhankelijke of gecoördineerde OpenShift-clusters in de publieke cloud en on-premise te beheren.

Daardoor moet een hele reeks problemen worden opgelost, waaronder:

• Controleren dat de clusters in identieke staat verkeren (configuraties, monitoring, opslag, enz.).
• Clusters opnieuw maken (of herstellen) naar een bekende staat.
• Nieuwe clusters creëren op basis van een bekende staat.
• Wijzigingen aanbrengen op meerdere OpenShift-clusters.
• Wijzigingen terugdraaien op meerdere OpenShift-clusters.
• Gepersonaliseerde configuraties koppelen aan verschillende omgevingen.

Applicatieconfiguraties

Tijdens hun levenscyclus doorlopen applicaties vaak een reeks clusters (dev, stage, enz.) voordat ze in het productiecluster terechtkomen. Bovendien zetten klanten vanwege beschikbaarheids- en schaalbaarheidseisen vaak applicaties gelijktijdig uit op meerdere on-premise clusters of in verschillende regio's van een publieke cloudplatform.

Bij dit proces moeten de volgende taken worden uitgevoerd:

• Zorg dragen voor de beweging van applicaties (binaries, configuraties, enz.) tussen clusters (dev, stage, enz.).
• Wijzigingen in applicaties (binaries, configuraties, enz.) toepassen op meerdere OpenShift-clusters.
• Wijzigingen in applicaties terugdraaien naar het niveau van een vorige bekende staat.

Toepassingsscenario's voor OpenShift GitOps

1. Wijzigingen toepassen vanuit de Git-repository

De clusterbeheerder kan OpenShift-clusterconfiguraties opslaan in een Git-repository en ze automatisch toepassen, zodat nieuwe clusters zonder moeite kunnen worden aangemaakt en in een staat kunnen worden gebracht die identiek is aan de bekende staat die in de Git-repository is opgeslagen.

2. Synchronisatie met Secret Manager

Voor de beheerder is de mogelijkheid om secret-objecten van OpenShift te synchroniseren met bijbehorende software zoals Vault handig, zodat ze ermee kunnen omgaan met speciaal hiervoor ontwikkelde tools.

3. Controle van configuratiedrift

De admin zal zeker blij zijn als OpenShift GitOps automatisch afwijkingen detecteert en waarschuwt voor verschillen tussen de werkelijke configuraties en die welke in de repository zijn gedefinieerd, zodat snel op drift kan worden gereageerd.

4. Configuraties Driftmeldingen

Nuttig voor wanneer een admin snel op de hoogte wil zijn van configuratiedrift, zodat hij snel zelf maatregelen kan nemen.

5. Handmatige configuratiesynchronisatie bij drift

Stelt de admin in staat om het OpenShift-cluster te synchroniseren met de Git-repository in het geval van configuratiedrift, zodat het cluster snel kan worden teruggebracht naar een eerder bekend staat.

6. Autosynchronisatie van configuraties bij drift

De admin kan ook het OpenShift-cluster instellen om automatisch te synchroniseren met de repository bij het detecteren van drift, zodat de clusterconfiguratie altijd overeenkomt met de bestanden in Git.

7. Meerdere clusters – één repository

De admin kan de configuraties van meerdere verschillende OpenShift-clusters in één Git-repository opslaan en selectief toepassen wanneer nodig.

8. Hiërarchie van clusterconfiguraties (overerving)

De admin kan een hiërarchie van clusterconfiguraties in de repository instellen (stage, prod, app portfolio enzovoort met overerving). Met andere woorden, hij kan definiëren hoe configuraties moeten worden toegepast - op één of meerdere clusters.

Bijvoorbeeld, als de admin in de Git-repository een hiërarchie instelt van "Productieclusters (prod) → Clusters van systeem X → Productieclusters van systeem X", dan wordt een combinatie van de volgende configuraties toegepast op de productieclusters van systeem X:

• Configuraties die gemeenschappelijk zijn voor alle productieclusters.
• Configuraties voor het cluster van systeem X.
• Configuraties voor de productiecluster van systeem X.

9. Sjablonen en configuratie-overriding

De admin kan een set overgenomen configuraties en hun waarden overschrijven om de configuratie beter af te stemmen op specifieke clusters waaraan ze zullen worden toegepast.

10. Selectieve includes en excludes voor configuraties, applicatieconfiguraties

De admin kan voorwaarden stellen voor het al dan niet toepassen van specifieke configuraties op clusters met bepaalde kenmerken.

11. Ondersteuning voor sjablonen

Ontwikkelaars zullen de mogelijkheid waarderen om te kiezen hoe de applicatiebronnen zullen worden gedefinieerd (Helm Chart, pure Kubernetes yaml, enzovoort) om het meest geschikte formaat voor elke specifieke applicatie te gebruiken.

GitOps-tools op het OpenShift-platform

ArgoCD

ArgoCD implementeert het model External Resource Reconcile en biedt een gecentraliseerde UI voor het orkestreren van de relaties tussen clusters en Git-repositories volgens het 'one-to-many' model. Een van de nadelen van dit programma is dat applicaties niet beheerd kunnen worden wanneer ArgoCD niet werkt.

Officiële website

Flux

Flux implementeert het model On-Cluster Resource Reconcile, en als gevolg daarvan is er geen gecentraliseerd beheer van de definitie-repository, wat een zwakte is. Aan de andere kant betekent het ontbreken van centralisatie dat het mogelijk blijft om applicaties te beheren, zelfs wanneer een cluster uitvalt.

Officiële website

ArgoCD installeren op OpenShift

ArgoCD biedt een uitstekende commandoregelinterface en webconsole, daarom zullen we hier Flux en andere alternatieven niet bespreken.

Volg deze stappen als clusterbeheerder om ArgoCD in te zetten op het OpenShift 4-platform:

De implementatie van ArgoCD-componenten op het OpenShift-platform

# 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}')

De ArgoCD-server aanpassen zodat deze zichtbaar is voor 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

ArgoCD Cli Tool implementeren

# 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

Het administratiewachtwoord van de ArgoCD-server wijzigen

# 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

Na het uitvoeren van deze stappen kan de ArgoCD-server worden bediend via de ArgoCD WebUI of de ArgoCD Cli commandoregeltool.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – het is nooit te laat

"De trein is vertrokken" - dit wordt gezegd over een situatie waarin de mogelijkheid om iets te doen is gemist. In het geval van OpenShift creëert de wens om deze nieuwe spannende platform meteen te gebruiken vaak zo'n situatie met het beheer en onderhoud van routes, deployments en andere OpenShift-objecten. Maar is de kans altijd voorgoed gemist?

Voortbouwend op onze serie artikelen over GitOps, laten we vandaag zien hoe we een handmatig gemaakte applicatie en de bijbehorende middelen kunnen omzetten in een proces dat volledig wordt beheerd door het GitOps-instrumentarium. Hiervoor zullen we eerst handmatig de httpd-applicatie implemeneteren. Op de onderstaande screenshot zie je hoe we een namespace, deployment en service creëren, en vervolgens deze service exposen om een route te maken.

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

Dus, we hebben een handmatig gemaakte applicatie. Nu moet deze worden overgezet naar GitOps-beheer zonder dat de beschikbaarheid verloren gaat. Kort gezegd doet het het volgende:

• Maak een Git-repository voor de code.
• We export our current resources and upload them to the Git repository.
• We select and deploy the GitOps tooling.
• We add our repository to this tooling.
• We define the application in our GitOps tooling.
• We perform a test run of the application using the GitOps tooling.
• We synchronize the resources using the GitOps tooling.
• We enable pruning and auto-synchronization of resources.

As previously mentioned, artikel, in GitOps there is one and only one source of truth for all resources in the Kubernetes cluster(s) – the Git repository. We assume that your organization already uses a Git repository. It can be public or private, but it must be accessible to the Kubernetes clusters. This can be the same repository that contains the application code, or a separate repository created specifically for deployments. It is recommended to have strict permissions in the repository, as sensitive objects like secrets, routes, and other security-sensitive items will be stored there.

In our example, we will create a new public repository on GitHub. It can be named whatever you like; we will use the name blogpost.

If the YAML files of the resources were not stored locally or in Git, you will need to use the oc or kubectl binaries. In the screenshot below, we are requesting YAML for our namespace, deployment, service, and route. Before this, we cloned the newly created repository and navigated to it with the cd command.

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

Now let's modify the deployment.yaml file to remove the field that Argo CD cannot synchronize.

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

Additionally, we need to change the route. First, we will define a multiline variable, and then replace ingress: null with the contents of this variable.

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

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

So, we have dealt with the files, and now we need to save them in the Git repository. After this, this repository becomes the one and only source of truth, and any manual changes to resources must be strictly prohibited.

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

Vervolgens gaan we ervan uit dat ArgoCD al is geïmplementeerd (hoe dit te doen – zie de vorige bericht). Daarom voegen we de door ons gemaakte repository toe aan Argo CD, die de code van de toepassing bevat uit ons voorbeeld. Zorg er alleen voor dat je precies die repository opgeeft die je eerder hebt gemaakt.

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

Nu maken we de toepassing aan. De toepassing specificeert waarden, zodat de GitOps-tool begrijpt welke repository en paden te gebruiken, welke OpenShift nodig is voor het beheren van objecten, en welke specifieke tak van de repository nodig is, en of de aut Synchronisatie van resources moet plaatsvinden.

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

Nadat de toepassing in Argo CD is ingesteld, begint deze tool te controleren of de al geïmplementeerde objecten overeenkomen met de definities in de repository. In ons voorbeeld zijn aut Synchronisatie en opruiming uitgeschakeld, dus de elementen veranderen voorlopig niet. Merk op dat onze toepassing in de Argo CD-interface de status 'Out of Sync' zal hebben, omdat er geen label is dat door ArgoCD wordt toegewezen.
Daarom, wanneer we later de synchronisatie starten, zal de redeploy van objecten niet plaatsvinden.

Laten we nu een proefrun uitvoeren om te controleren of er geen fouten in onze bestanden zitten.

argocd app sync simple-app --dry-run

Als er geen fouten zijn, kunnen we verdergaan met de synchronisatie.

argocd app sync simple-app

Na het uitvoeren van het argocd get-commando op onze toepassing, moeten we zien dat de status van de toepassing is veranderd naar Healthy of Synced. Dit betekent dat alle resources in de Git-repository nu overeenkomen met de reeds geïmplementeerde resources.

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 kunnen we de aut Synchronisatie en opruiming inschakelen om ervoor te zorgen dat er niets handmatig wordt aangemaakt en dat elke keer dat een object in de repository wordt aangemaakt of bijgewerkt, een implementatie zal plaatsvinden.

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

We hebben met succes een applicatie die oorspronkelijk geen gebruik maakte van GitOps, overgezet naar een GitOps-beheer.

Bron: habr.com