🥇Inleiding tot GitOps voor OpenShift

Vandaag zullen we het hebben over de principes en modellen van GitOps, en hoe deze modellen worden geïmplementeerd op het OpenShift-platform. Er is een interactieve gids over dit onderwerp beschikbaar link.

In een notendop is GitOps een reeks praktijken voor het gebruik van Git-pull-verzoeken om infrastructuur- en applicatieconfiguraties te beheren. De Git-repository in GitOps wordt behandeld als één enkele bron van informatie over de status van het systeem, en eventuele wijzigingen in deze status zijn volledig traceerbaar en controleerbaar.

Het idee van het bijhouden van wijzigingen in GitOps is zeker niet nieuw; deze aanpak wordt al lang vrijwel universeel gebruikt bij het werken met de broncode van applicaties. GitOps implementeert eenvoudigweg vergelijkbare functies (reviews, pull-requests, tags, etc.) in infrastructuur- en applicatieconfiguratiebeheer en biedt vergelijkbare voordelen als in het geval van broncodebeheer.

Er bestaat geen academische definitie of goedgekeurde reeks regels voor GitOps, alleen een reeks principes waarop deze praktijk is gebouwd:

De declaratieve beschrijving van het systeem wordt opgeslagen in de Git-repository (configuraties, monitoring, enz.).
Statuswijzigingen worden doorgevoerd via pull-requests.
Met behulp van Git-pushverzoeken wordt de status van draaiende systemen in lijn gebracht met de gegevens in de repository.

GitOps-principes

Systeemdefinities worden beschreven als broncode

De systeemconfiguratie wordt behandeld als code, zodat deze kan worden opgeslagen en automatisch kan worden bijgewerkt in een Git-repository, die als enige bron van waarheid dient. Deze aanpak maakt het eenvoudig om wijzigingen in systemen uit te rollen en terug te draaien.

De gewenste status en configuratie van systemen worden ingesteld en geversioneerd in Git

Door de gewenste status van systemen in Git op te slaan en te versiebeheer, kunnen we wijzigingen in systemen en applicaties eenvoudig uitrollen en terugdraaien. We kunnen ook de beveiligingsmechanismen van Git gebruiken om het eigendom van de code te controleren en de authenticiteit ervan te verifiëren.

Configuratiewijzigingen kunnen automatisch worden toegepast via pull-requests

Met behulp van Git-pull-verzoeken kunnen we eenvoudig bepalen hoe wijzigingen worden toegepast op configuraties in de repository. Ze kunnen bijvoorbeeld ter beoordeling aan andere teamleden worden gegeven of CI-tests worden uitgevoerd, enz.

En tegelijkertijd is het niet nodig om de bestuursbevoegdheden links en rechts te verdelen. Om configuratiewijzigingen door te voeren hebben gebruikers alleen de juiste machtigingen nodig in de Git-repository waar deze configuraties zijn opgeslagen.

Het probleem van ongecontroleerde drift van configuraties oplossen

Zodra de gewenste staat van het systeem is opgeslagen in een Git-repository, hoeven we alleen maar software te vinden die ervoor zorgt dat de huidige staat van het systeem overeenkomt met de gewenste staat. Als dit niet het geval is, zou deze software - afhankelijk van de instellingen - de discrepantie zelf moeten elimineren, of ons op de hoogte moeten stellen van configuratieafwijking.

GitOps-modellen voor OpenShift

Resourceafstemming op het cluster

Volgens dit model heeft het cluster een controller die verantwoordelijk is voor het vergelijken van Kubernetes-bronnen (YAML-bestanden) in de Git-repository met de echte bronnen van het cluster. Als er afwijkingen worden geconstateerd, stuurt de verwerkingsverantwoordelijke notificaties en onderneemt mogelijk actie om de afwijkingen te corrigeren. Dit GitOps-model wordt gebruikt in Anthos Config Management en Weaveworks Flux.

Externe resourceafstemming (push)

Dit model kan worden beschouwd als een variatie op het vorige, wanneer we een of meer controllers hebben die verantwoordelijk zijn voor het synchroniseren van bronnen in de paren "Git-repository - Kubernetes-cluster". Het verschil hier is dat elk beheerd cluster niet noodzakelijkerwijs een eigen afzonderlijke controller heeft. Git - k8s-clusterparen worden vaak gedefinieerd als CRD's (aangepaste resourcedefinities), die kunnen beschrijven hoe de controller de synchronisatie moet uitvoeren. Binnen dit model vergelijken controllers de Git-repository die is gespecificeerd in de CRD met de Kubernetes-clusterbronnen, die ook zijn gespecificeerd in de CRD, en voeren zij passende acties uit op basis van de resultaten van de vergelijking. Dit GitOps-model wordt met name gebruikt in ArgoCD.

GitOps op het OpenShift-platform

Beheer van multi-cluster Kubernetes-infrastructuur

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

Bij gebruik van edge computing kunnen de clusters van één klant bijvoorbeeld in honderden of zelfs duizenden worden ingezet. Als gevolg hiervan wordt hij gedwongen meerdere onafhankelijke of gecoördineerde OpenShift-clusters in de publieke cloud en on-premise te beheren.

In dit geval moeten veel problemen worden opgelost, met name:

Controleer of de clusters zich in een identieke staat bevinden (configuraties, monitoring, opslag, enz.)
Clusters opnieuw maken (of herstellen) op basis van een bekende status.
Maak nieuwe clusters op basis van een bekende status.
Implementeer wijzigingen in meerdere OpenShift-clusters.
Wijzigingen ongedaan maken in meerdere OpenShift-clusters.
Koppel sjabloonconfiguraties aan verschillende omgevingen.

Applicatieconfiguraties

Tijdens hun levenscyclus doorlopen applicaties vaak een keten van clusters (dev, stage, etc.) voordat ze in een productiecluster terechtkomen. Bovendien implementeren klanten vanwege beschikbaarheids- en schaalbaarheidsvereisten vaak applicaties over meerdere lokale clusters of meerdere regio's van een openbaar cloudplatform.

In dit geval moeten de volgende taken worden opgelost:

Zorg voor de verplaatsing van applicaties (binaire bestanden, configuraties, enz.) tussen clusters (dev, stage, enz.).
Implementeer wijzigingen in applicaties (binaire bestanden, configuraties, etc.) in verschillende OpenShift-clusters.
Wijzigingen in applicaties terugdraaien naar een eerder bekende staat.

OpenShift GitOps-gebruikscases

1. Wijzigingen toepassen vanuit de Git-repository

Een clusterbeheerder kan OpenShift-clusterconfiguraties opslaan in een Git-repository en deze automatisch toepassen om moeiteloos nieuwe clusters te maken en deze in een staat te brengen die identiek is aan de bekende staat die is opgeslagen in de Git-repository.

2. Synchronisatie met Secret Manager

De beheerder zal ook profiteren van de mogelijkheid om geheime OpenShift-objecten te synchroniseren met geschikte software zoals Vault, om ze te beheren met behulp van speciaal hiervoor gemaakte tools.

3. Controle van driftconfiguraties

De beheerder zal er alleen voorstander van zijn als OpenShift GitOps zelf discrepanties tussen echte configuraties en de configuraties gespecificeerd in de repository identificeert en waarschuwt, zodat ze snel kunnen reageren op drift.

4. Meldingen over configuratieafwijking

Ze zijn nuttig in het geval dat de beheerder snel kennis wil nemen van gevallen van configuratiedrift, zodat hij zelf snel passende maatregelen kan nemen.

5. Handmatige synchronisatie van configuraties tijdens driften

Hiermee kan de beheerder het OpenShift-cluster synchroniseren met de Git-repository in geval van configuratiedrift, om het cluster snel terug te brengen naar een eerder bekende staat.

6. Automatische synchronisatie van configuraties tijdens driften

De beheerder kan het OpenShift-cluster ook configureren om automatisch te synchroniseren met de repository wanneer er een drift wordt gedetecteerd, zodat de clusterconfiguratie altijd overeenkomt met de configuraties in Git.

7. Meerdere clusters - één repository

De beheerder kan configuraties van verschillende OpenShift-clusters in één Git-repository opslaan en deze indien nodig selectief toepassen.

8. Hiërarchie van clusterconfiguraties (overerving)

De beheerder kan een hiërarchie van clusterconfiguraties in de repository instellen (podium, product, app-portfolio, enz. met overname). Met andere woorden, het kan bepalen of configuraties moeten worden toegepast op een of meer clusters.

Als een beheerder bijvoorbeeld de hiërarchie “Productieclusters (prod) → Systeem X-clusters → Productieclusters van systeem X” in de Git-repository instelt, wordt een combinatie van de volgende configuraties toegepast op de productieclusters van systeem X:

Configuraties die gemeenschappelijk zijn voor alle productieclusters.
Configuraties voor het System X-cluster.
Configuraties voor het productiecluster van het X-systeem.

9. Sjablonen en configuratieoverschrijvingen

De beheerder kan een reeks overgenomen configuraties en hun waarden overschrijven, bijvoorbeeld om de configuratie te verfijnen voor specifieke clusters waarop ze worden toegepast.

10. Selectief opnemen en uitsluiten voor configuraties, applicatieconfiguraties

De beheerder kan voorwaarden stellen voor het wel of niet toepassen van bepaalde configuraties op clusters met bepaalde kenmerken.

11. Sjabloonondersteuning

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

GitOps-tools op het OpenShift-platform

ArgoCD

ArgoCD implementeert het External Resource Reconcile-model en biedt een gecentraliseerde gebruikersinterface voor het orkestreren van één-op-veel-relaties tussen clusters en Git-repository's. De nadelen van dit programma zijn onder meer het onvermogen om applicaties te beheren wanneer ArgoCD niet werkt.

Officiële website

Stroom

Flux implementeert een On-Cluster Resource Reconcile-model en als gevolg daarvan is er geen gecentraliseerd beheer van de definitierepository, wat een zwak punt is. Aan de andere kant blijft, juist door het gebrek aan centralisatie, de mogelijkheid om applicaties te beheren bestaan, zelfs als één cluster uitvalt.

Officiële website

ArgoCD installeren op OpenShift

ArgoCD biedt een uitstekende opdrachtregelinterface en webconsole, dus we zullen hier niet ingaan op Flux en andere alternatieven.

Om ArgoCD op het OpenShift 4-platform te implementeren, volgt u als clusterbeheerder deze stappen:

ArgoCD-componenten implementeren 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}')

Verbetering van ArgoCD Server 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 beheerderswachtwoord 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

Nadat u deze stappen hebt voltooid, kunt u met ArgoCD Server werken via de ArgoCD WebUI-webconsole of het ArgoCD Cli-opdrachtregelprogramma.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Het is nooit te laat

"De trein is vertrokken" - dit is wat ze zeggen over een situatie waarin de kans om iets te doen wordt gemist. In het geval van OpenShift creëert de wens om dit gave nieuwe platform direct in gebruik te nemen vaak precies deze situatie bij het beheer en onderhoud van routes, implementaties en andere OpenShift-objecten. Maar is de kans altijd volledig verloren?

Voortzetting van de reeks artikelen over Gitops, vandaag laten we u zien hoe u een handgemaakte applicatie en de bijbehorende bronnen kunt transformeren in een proces waarbij alles wordt beheerd door GitOps-tools. Om dit te doen, zullen we eerst handmatig de httpd-applicatie implementeren. De onderstaande schermafbeelding laat zien hoe we een naamruimte, implementatie en service maken en deze service vervolgens beschikbaar stellen 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

We hebben dus een handgemaakte applicatie. Nu moet het onder GitOps-beheer worden overgedragen zonder verlies van beschikbaarheid. Kort gezegd doet het dit:

Maak een Git-opslagplaats voor de code.
We exporteren onze huidige objecten en uploaden ze naar de Git-repository.
GitOps-tools selecteren en inzetten.
We voegen onze repository toe aan deze toolkit.
We definiëren de applicatie in onze GitOps toolkit.
We voeren een testrun van de applicatie uit met behulp van de GitOps-toolkit.
We synchroniseren objecten met behulp van de GitOps toolkit.
Schakel snoeien en automatische synchronisatie van objecten in.

Zoals in de vorige al vermeld статье, in GitOps is er één en slechts één informatiebron over alle objecten in de Kubernetes-cluster(en) - de Git-repository. Vervolgens gaan we ervan uit dat uw organisatie al gebruik maakt van een Git repository. Het kan openbaar of privé zijn, maar het moet toegankelijk zijn voor Kubernetes-clusters. Dit kan dezelfde opslagplaats zijn als voor de applicatiecode, of een afzonderlijke opslagplaats die speciaal voor implementaties is gemaakt. Het wordt aanbevolen om strikte machtigingen in de repository te hebben, aangezien daar geheimen, routes en andere beveiligingsgevoelige zaken worden opgeslagen.

In ons voorbeeld zullen we een nieuwe openbare repository op GitHub maken. Je kunt het noemen hoe je wilt, wij gebruiken de naam blogpost.

Als de YAML-objectbestanden niet lokaal of in Git zijn opgeslagen, moet je de binaire bestanden oc of kubectl gebruiken. In de onderstaande schermafbeelding vragen we YAML aan voor onze naamruimte, implementatie, service en route. Voordien hebben we de nieuw gemaakte repository en cd erin gekloond.

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

Laten we nu het bestand deployment.yaml bewerken om het veld te verwijderen dat Argo CD niet kan synchroniseren.

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

Bovendien moet de route worden gewijzigd. We stellen eerst een variabele met meerdere regels in en vervangen vervolgens ingress: null door de inhoud van die variabele.

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

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

Dus we hebben de bestanden uitgezocht, het enige dat overblijft is ze op te slaan in de Git-repository. Daarna wordt deze repository de enige bron van informatie en moeten alle handmatige wijzigingen aan objecten ten strengste verboden zijn.

git commit -am ‘initial commit of objects’
git push origin master

Verder gaan we uit van het feit dat u ArgoCD al hebt geïmplementeerd (hoe u dit doet - zie vorig post). Daarom zullen we aan de Argo CD de repository toevoegen die we hebben gemaakt, met daarin de applicatiecode uit ons voorbeeld. Zorg ervoor dat u de exacte repository opgeeft die u eerder hebt gemaakt.

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

Laten we nu de applicatie maken. De applicatie stelt waarden in zodat de GitOps-toolkit begrijpt welke repository en paden moeten worden gebruikt, welke OpenShift nodig is om objecten te beheren, welke specifieke tak van de repository nodig is en of bronnen automatisch moeten worden gesynchroniseerd.

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

Zodra een applicatie op de Argo-cd is gespecificeerd, begint de toolkit reeds geïmplementeerde objecten te vergelijken met de definities in de repository. In ons voorbeeld zijn automatisch synchroniseren en opschonen uitgeschakeld, dus de elementen veranderen nog niet. Houd er rekening mee dat onze applicatie in de Argo CD-interface de status "Out of Sync" zal hebben omdat er geen label is dat ArgoCD biedt.
Dit is de reden waarom de objecten niet opnieuw worden ingezet als we iets later met de synchronisatie beginnen.

Laten we nu een testrun uitvoeren om er zeker van te zijn dat er geen fouten in onze bestanden voorkomen.

argocd app sync simple-app --dry-run

Als er geen fouten zijn, kunt u doorgaan met de synchronisatie.

argocd app sync simple-app

Nadat we de opdracht argocd get in onze applicatie hebben uitgevoerd, zouden we moeten zien dat de applicatiestatus is gewijzigd in Gezond of Gesynchroniseerd. Dit betekent dat alle bronnen in de Git-repository nu overeenkomen met de bronnen die al zijn geïmplementeerd.

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 kunt u automatische synchronisatie en opschoning inschakelen om ervoor te zorgen dat er niets handmatig wordt gemaakt en dat elke keer dat een object wordt gemaakt of bijgewerkt naar de repository, er een implementatie plaatsvindt.

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

We hebben dus met succes een applicatie onder GitOps-controle gebracht die aanvankelijk op geen enkele manier gebruik maakte van GitOps.

Bron: www.habr.com

Inleiding tot GitOps voor OpenShift