Vandag sal ons praat oor die beginsels en modelle van GitOps, asook hoe hierdie modelle op die OpenShift-platform geïmplementeer word. 'n Interaktiewe gids oor hierdie onderwerp is beskikbaar .
In 'n neutedop, GitOps is 'n stel praktyke vir die gebruik van Git pull-versoeke om infrastruktuur en toepassingkonfigurasies te bestuur. Die Git-bewaarplek in GitOps word as 'n enkele bron van inligting oor die toestand van die stelsel hanteer, en enige veranderinge aan hierdie toestand is ten volle naspeurbaar en ouditeerbaar.
Die idee van veranderingsopsporing in GitOps is geensins nuut nie; hierdie benadering is lankal byna universeel gebruik wanneer daar met toepassingsbronkode gewerk word. GitOps implementeer eenvoudig soortgelyke kenmerke (resensies, trekversoeke, merkers, ens.) in infrastruktuur- en toepassingkonfigurasiebestuur en bied soortgelyke voordele as in die geval van bronkodebestuur.
Daar is geen akademiese definisie of goedgekeurde stel reëls vir GitOps nie, slegs 'n stel beginsels waarop hierdie praktyk gebou is:
- Die verklarende beskrywing van die stelsel word in die Git-bewaarplek gestoor (konfigurasies, monitering, ens.).
- Staatsveranderinge word gemaak deur trekversoeke.
- Die toestand van lopende stelsels word in lyn gebring met die data in die bewaarplek met Git-stootversoeke.
GitOps-beginsels
- Stelseldefinisies word as bronkode beskryf
Stelselkonfigurasie word as kode hanteer sodat dit gestoor en outomaties in 'n Git-bewaarplek geberg kan word, wat as 'n enkele bron van waarheid dien. Hierdie benadering maak dit maklik om veranderinge in stelsels te ontplooi en terug te rol.
- Die verlangde toestand en konfigurasie van stelsels word in Git gestel en geweer
Deur die verlangde toestand van stelsels in Git te stoor en weer te gee, kan ons veranderinge aan stelsels en toepassings maklik uitrol en terugrol. Ons kan ook Git se sekuriteitsmeganismes gebruik om kode-eienaarskap te beheer en die egtheid daarvan te verifieer.
- Konfigurasieveranderinge kan outomaties toegepas word via trekversoeke
Deur Git pull-versoeke te gebruik, kan ons maklik beheer hoe veranderinge op konfigurasies in die bewaarplek toegepas word. Hulle kan byvoorbeeld aan ander spanlede gegee word vir hersiening of deur CI-toetse, ens.
En terselfdertyd is dit nie nodig om admin magte links en regs te versprei nie. Om konfigurasieveranderinge te pleeg, benodig gebruikers slegs toepaslike toestemmings in die Git-bewaarplek waar daardie konfigurasies gestoor word.
- Die oplossing van die probleem van onbeheerde dryf van konfigurasies
Sodra die verlangde toestand van die stelsel in 'n Git-bewaarplek gestoor is, hoef ons net sagteware te vind wat sal verseker dat die huidige toestand van die stelsel ooreenstem met die verlangde toestand. As dit nie die geval is nie, moet hierdie sagteware - afhangend van die instellings - óf die teenstrydigheid op sy eie uitskakel, óf ons in kennis stel van konfigurasieverskuiwing.
GitOps-modelle vir OpenShift
On-Cluster Hulpbronversoener
Volgens hierdie model het die cluster 'n kontroleerder wat verantwoordelik is vir die vergelyking van Kubernetes-hulpbronne (YAML-lêers) in die Git-bewaarplek met die werklike bronne van die cluster. As teenstrydighede bespeur word, stuur die beheerder kennisgewings en neem moontlik stappe om die teenstrydighede reg te stel. Hierdie GitOps-model word gebruik in Anthos Config Management en Weaveworks Flux.
Eksterne Hulpbronversoener (Push)
Hierdie model kan beskou word as 'n variasie van die vorige een, wanneer ons een of meer beheerders het wat verantwoordelik is vir die sinchronisering van hulpbronne in die "Git repository - Kubernetes cluster" pare. Die verskil hier is dat elke bestuurde groepie nie noodwendig sy eie afsonderlike beheerder het nie. Git - k8s-klusterpare word dikwels gedefinieer as CRD's (pasgemaakte hulpbrondefinisies), wat kan beskryf hoe die beheerder sinchronisasie moet uitvoer. Binne hierdie model vergelyk beheerders die Git-bewaarplek wat in die CRD gespesifiseer is met die Kubernetes-klusterhulpbronne, wat ook in die CRD gespesifiseer word, en voer toepaslike aksies uit op grond van die resultate van die vergelyking. In die besonder word hierdie GitOps-model in ArgoCD gebruik.
GitOps op die OpenShift-platform
Administrasie van multi-kluster Kubernetes-infrastruktuur
Met die verspreiding van Kubernetes en die groeiende gewildheid van multi-wolk-strategieë en randrekenaars, neem die gemiddelde aantal OpenShift-klusters per kliënt ook toe.
Byvoorbeeld, wanneer randrekenaarkunde gebruik word, kan een kliënt se klusters in honderde of selfs duisende ontplooi word. As gevolg hiervan word hy gedwing om verskeie onafhanklike of gekoördineerde OpenShift-klusters in die publieke wolk en op die perseel te bestuur.
In hierdie geval moet baie probleme opgelos word, veral:
- Beheer dat die trosse in 'n identiese toestand is (konfigurasies, monitering, berging, ens.)
- Herskep (of herstel) trosse gebaseer op 'n bekende toestand.
- Skep nuwe trosse gebaseer op 'n bekende toestand.
- Ontplooi veranderinge aan verskeie OpenShift-klusters.
- Rol veranderinge terug oor verskeie OpenShift-klusters.
- Koppel sjabloonkonfigurasies aan verskillende omgewings.
Toepassing konfigurasies
Gedurende hul lewensiklus gaan toepassings dikwels deur 'n ketting van trosse (ontwikkelaar, stadium, ens.) voordat dit in 'n produksiekluster beland. Boonop, as gevolg van beskikbaarheid en skaalbaarheidsvereistes, ontplooi kliënte dikwels toepassings oor veelvuldige groepe op die perseel of verskeie streke van 'n publieke wolkplatform.
In hierdie geval moet die volgende take opgelos word:
- Verseker die beweging van toepassings (binaries, configs, ens.) tussen clusters (dev, stage, ens.).
- Ontplooi veranderinge aan toepassings (binaries, konfigurasies, ens.) in verskeie OpenShift-klusters.
- Rol veranderinge aan toepassings terug na 'n vorige bekende toestand.
OpenShift GitOps Gebruiksgevalle
1. Pas veranderinge vanaf die Git-bewaarplek toe
'n Klusteradministrateur kan OpenShift-klusterkonfigurasies in 'n Git-bewaarplek stoor en dit outomaties toepas om moeiteloos nuwe klusters te skep en dit in 'n toestand te bring wat identies is aan die bekende toestand wat in die Git-bewaarplek gestoor is.
2. Sinchronisasie met Secret Manager
Die administrateur sal ook baat by die vermoë om OpenShift-geheime voorwerpe met toepaslike sagteware soos Vault te sinchroniseer om dit te bestuur met behulp van gereedskap wat spesiaal daarvoor geskep is.
3. Beheer van drifkonfigurasies
Die admin sal slegs ten gunste wees as OpenShift GitOps self identifiseer en waarsku teen verskille tussen werklike konfigurasies en dié wat in die bewaarplek gespesifiseer word, sodat hulle vinnig op wegdryf kan reageer.
4. Kennisgewings oor konfigurasie dryf
Hulle is nuttig in die geval wanneer die administrateur vinnig wil leer oor gevalle van konfigurasieverskuiwing om vinnig toepaslike maatreëls op sy eie te neem.
5. Handmatige sinchronisasie van konfigurasies wanneer dryf
Laat die administrateur toe om die OpenShift-kluster met die Git-bewaarplek te sinchroniseer in die geval van konfigurasieverskuiwing, om die groep vinnig terug te keer na 'n vorige bekende toestand.
6.Outo-sinchronisasie van konfigurasies wanneer dryf
Die administrateur kan ook die OpenShift-groepering instel om outomaties met die bewaarplek te sinchroniseer wanneer 'n drif bespeur word, sodat die groepkonfigurasie altyd ooreenstem met die konfigurasies in Git.
7. Verskeie trosse - een bewaarplek
Die administrateur kan konfigurasies van verskeie verskillende OpenShift-klusters in een Git-bewaarplek stoor en dit selektief toepas soos nodig.
8. Hiërargie van groepkonfigurasies (oorerwing)
Die admin kan 'n hiërargie van groepkonfigurasies in die bewaarplek (stadium, prod, app-portefeulje, ens. met oorerwing) stel. Met ander woorde, dit kan bepaal of konfigurasies op een of meer groepe toegepas moet word.
Byvoorbeeld, as 'n administrateur die hiërargie "Produksieklusters (prod) → Stelsel X-klusters → Produksieklusters van stelsel X" in die Git-bewaarplek stel, dan word 'n kombinasie van die volgende konfigurasies toegepas op die produksieklusters van stelsel X:
- Konfigurasies wat algemeen is vir alle produksieklusters.
- Opstellings vir die System X-kluster.
- Opstellings vir die X-stelselproduksiekluster.
9. Sjablone en konfigurasie ignoreer
Die administrateur kan 'n stel oorgeërfde konfigurasies en hul waardes ignoreer, byvoorbeeld om die konfigurasie te verfyn vir spesifieke groepe waarop hulle toegepas sal word.
10. Selektiewe in- en uitsluit vir konfigurasies, toepassingskonfigurasies
Die administrateur kan die voorwaardes stel vir die toepassing of nie-toepassing van sekere konfigurasies op groepe met sekere eienskappe.
11. Sjabloon ondersteuning
Ontwikkelaars sal baat vind by die vermoë om te kies hoe toepassingshulpbronne gedefinieer sal word (Helm Chart, suiwer Kubernetes yaml, ens.) om die mees geskikte formaat vir elke spesifieke toepassing te gebruik.
GitOps-nutsgoed op die OpenShift-platform
ArgoCD
ArgoCD implementeer die External Resource Reconcile-model en bied 'n gesentraliseerde UI vir die orkestrering van een-tot-veel-verhoudings tussen trosse en Git-bewaarplekke. Die nadele van hierdie program sluit in die onvermoë om toepassings te bestuur wanneer ArgoCD nie werk nie.
Flux
Flux implementeer 'n On-Cluster Resource Reconcile-model en gevolglik is daar geen gesentraliseerde bestuur van die definisiebewaarplek nie, wat 'n swak punt is. Aan die ander kant, juis as gevolg van die gebrek aan sentralisasie, bly die vermoë om toepassings te bestuur, selfs as een groep misluk.
Installeer ArgoCD op OpenShift
ArgoCD bied 'n uitstekende opdraglyn-koppelvlak en webkonsole, so ons sal nie Flux en ander alternatiewe hier dek nie.
Om ArgoCD op die OpenShift 4-platform te ontplooi, volg hierdie stappe as 'n groepadministrateur:
Die implementering van ArgoCD-komponente op die 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 sodat dit deur OpenShift Route gesien kan word
# 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=RedirectOntplooi 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/argocdVerander die ArgoCD Server admin wagwoord
# 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 hierdie stappe voltooi het, kan u met ArgoCD Server werk deur die ArgoCD WebUI-webkonsole of die ArgoCD Cli-opdragreëlnutsding.
GitOps - Dit is nooit te laat nie
"Die trein het vertrek" - dit is wat hulle sê oor 'n situasie wanneer die geleentheid om iets te doen gemis word. In die geval van OpenShift, skep die begeerte om dadelik hierdie oulike nuwe platform te gebruik, dikwels presies hierdie situasie met die bestuur en instandhouding van roetes, ontplooiings en ander OpenShift-voorwerpe. Maar is die kans altyd heeltemal verlore?
Voortsetting van die reeks artikels oor , vandag sal ons jou wys hoe om 'n handgemaakte toepassing en sy hulpbronne te omskep in 'n proses waar alles deur GitOps-nutsgoed bestuur word. Om dit te doen, sal ons eers die httpd-toepassing handmatig ontplooi. Die skermkiekie hieronder wys hoe ons 'n naamruimte, ontplooiing en diens skep, en dan hierdie diens blootstel om 'n roete te skep.
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-appOns het dus 'n handgemaakte toepassing. Nou moet dit onder GitOps-bestuur oorgedra word sonder verlies aan beskikbaarheid. Kortom, dit doen dit:
- Skep 'n Git-bewaarplek vir die kode.
- Ons voer ons huidige voorwerpe uit en laai dit op na die Git-bewaarplek.
- Kies en ontplooi GitOps-nutsgoed.
- Ons voeg ons bewaarplek by hierdie gereedskapstel.
- Ons definieer die toepassing in ons GitOps-gereedskapstel.
- Ons voer 'n toetslopie van die toepassing uit met behulp van die GitOps-gereedskapstel.
- Ons sinchroniseer voorwerpe met behulp van die GitOps-gereedskapstel.
- Aktiveer snoei en outo-sinchronisasie van voorwerpe.
Soos in die vorige genoem , in GitOps is daar een en slegs een bron van inligting oor alle voorwerpe in die Kubernetes-kluster(s) - die Git-bewaarplek. Vervolgens gaan ons van die uitgangspunt uit dat u organisasie reeds 'n Git-bewaarplek gebruik. Dit kan publiek of privaat wees, maar dit moet toeganklik wees vir Kubernetes-klusters. Dit kan dieselfde bewaarplek wees as vir toepassingskode, of 'n aparte bewaarplek wat spesifiek vir ontplooiings geskep is. Dit word aanbeveel om streng toestemmings in die bewaarplek te hê, aangesien geheime, roetes en ander sekuriteitsensitiewe dinge daar gestoor sal word.
In ons voorbeeld sal ons 'n nuwe publieke bewaarplek op GitHub skep. Jy kan dit noem wat jy wil, ons gebruik die naam blogpost.
As die YAML-objeklêers nie plaaslik of in Git gestoor is nie, sal jy die oc of kubectl binaries moet gebruik. In die skermkiekie hieronder versoek ons YAML vir ons naamruimte, ontplooiing, diens en roete. Voor dit het ons die nuutgeskepte bewaarplek en cd daarin gekloon.
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.yamlKom ons redigeer nou die deployment.yaml-lêer om die veld te verwyder wat Argo CD nie kan sinkroniseer nie.
sed -i '/sgeneration: .*/d' deployment.yamlBoonop moet die roete verander word. Ons sal eers 'n multiline-veranderlike stel en dan ingress: null vervang met die inhoud van daardie veranderlike.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlDus, ons het die lêers uitgesorteer, al wat oorbly is om dit in die Git-bewaarplek te stoor. Waarna hierdie bewaarplek die enigste bron van inligting word, en enige handmatige veranderinge aan voorwerpe moet streng verbied word.
git commit -am ‘initial commit of objects’
git push origin masterOns gaan verder van die feit dat u reeds ArgoCD ontplooi het (hoe om dit te doen - sien vorige ). Daarom sal ons die bewaarplek wat ons geskep het, wat die toepassingskode van ons voorbeeld bevat, by die Argo-CD voeg. Maak net seker dat jy die presiese bewaarplek spesifiseer wat jy vroeër geskep het.
argocd repo add https://github.com/cooktheryan/blogpostKom ons skep nou die toepassing. Die toepassing stel waardes sodat die GitOps-gereedskapstel verstaan watter bewaarplek en paaie om te gebruik, watter OpenShift nodig is om voorwerpe te bestuur, watter spesifieke tak van die bewaarplek nodig is, en of hulpbronne outo-sinkroniseer moet word.
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
Sodra 'n toepassing in die Argo-CD gespesifiseer is, begin die gereedskapstel reeds ontplooide voorwerpe nagaan teen die definisies in die bewaarplek. In ons voorbeeld is outo-sinkronisering en opruiming gedeaktiveer, so die elemente verander nog nie. Neem asseblief kennis dat in die Argo CD-koppelvlak ons toepassing die status "Out of Sync" sal hê omdat daar geen etiket is wat ArgoCD verskaf nie.
Dit is hoekom wanneer ons 'n bietjie later begin sinchroniseer, die voorwerpe nie herontplooi sal word nie.
Kom ons doen nou 'n toetslopie om seker te maak dat daar geen foute in ons lêers is nie.
argocd app sync simple-app --dry-runAs daar geen foute is nie, kan u voortgaan met sinchronisasie.
argocd app sync simple-appNadat ons die argocd get-opdrag op ons toepassing uitgevoer het, behoort ons te sien dat die toepassingstatus verander het na gesond of gesinkroniseer. Dit sal beteken dat alle hulpbronne in die Git-bewaarplek nou ooreenstem met daardie hulpbronne wat reeds ontplooi is.
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
... Nou kan jy outo-sinkronisering en opruiming aktiveer om te verseker dat niks met die hand geskep word nie en dat elke keer as 'n voorwerp geskep of bygewerk word na die bewaarplek, 'n ontplooiing sal plaasvind.
argocd app set simple-app --sync-policy automated --auto-prune
Dus, ons het 'n toepassing suksesvol onder GitOps-beheer gebring wat aanvanklik nie GitOps op enige manier gebruik het nie.
Bron: will.com