Hjoed sille wy prate oer de prinsipes en modellen fan GitOps, lykas hoe't dizze modellen wurde ymplementearre op it OpenShift-platfoarm. In ynteraktive gids oer dit ûnderwerp is beskikber .
Yn in notedop is GitOps in set fan praktiken foar it brûken fan Git pull-oanfragen om ynfrastruktuer en applikaasjekonfiguraasjes te behearjen. It Git-repository yn GitOps wurdt behannele as ien boarne fan ynformaasje oer de steat fan it systeem, en alle feroaringen yn dizze steat binne folslein traceerber en kontrolearber.
It idee fan it folgjen fan feroaringen yn GitOps is lang net nij; dizze oanpak is al lang hast universeel brûkt by it wurkjen mei applikaasjeboarnekoade. GitOps ymplementearret gewoan ferlykbere funksjes (resinsjes, pull-oanfragen, tags, ensfh.)
D'r is gjin akademyske definysje of goedkarde set regels foar GitOps, allinich in set prinsipes wêrop dizze praktyk is boud:
- De deklarative beskriuwing fan it systeem wurdt opslein yn it Git-repository (konfiguraasjes, tafersjoch, ensfh.).
- Steatwizigingen wurde makke troch pull-oanfragen.
- De steat fan rinnende systemen wurdt yn oerienstimming brocht mei de gegevens yn 'e repository mei Git push-oanfragen.
GitOps-prinsipes
- Systeemdefinysjes wurde beskreaun as boarnekoade
Systeemkonfiguraasje wurdt behannele as koade, sadat it kin wurde opslein en automatysk ferzje yn in Git-repository, dat tsjinnet as ienige boarne fan wierheid. Dizze oanpak makket it maklik om feroaringen yn systemen út te rollen en werom te setten.
- De winske steat en konfiguraasje fan systemen wurde ynsteld en ferzje yn Git
Troch de winske steat fan systemen yn Git op te slaan en te ferzjen, kinne wy wizigingen maklik útrolje en weromdraaie nei systemen en applikaasjes. Wy kinne ek de feiligensmeganismen fan Git brûke om koade-eigendom te kontrolearjen en de autentisiteit te ferifiearjen.
- Konfiguraasjewizigingen kinne automatysk tapast wurde fia pull-oanfragen
Mei help fan Git pull-oanfragen kinne wy maklik kontrolearje hoe't wizigingen tapast wurde op konfiguraasjes yn it repository. Se kinne bygelyks wurde jûn oan oare teamleden foar resinsje of rinne troch CI-tests, ensfh.
En tagelyk is d'r gjin ferlet om adminfoech lofts en rjochts te fersprieden. Om konfiguraasjewizigingen te dwaan, hawwe brûkers allinich passende tagongsrjochten nedich yn it Git-repository wêr't dy konfiguraasjes wurde opslein.
- It probleem oplosse fan ûnkontroleare drift fan konfiguraasjes
Sadree't de winske tastân fan it systeem is opslein yn in Git-repository, alles wat wy hoege te dwaan is software te finen dy't derfoar soargje dat de hjoeddeistige tastân fan it systeem oerienkomt mei syn winske steat. As dit net it gefal is, dan moat dizze software - ôfhinklik fan 'e ynstellings - de diskrepânsje op harsels eliminearje, of ús ynformearje oer konfiguraasjedrift.
GitOps-modellen foar OpenShift
On-Cluster Resource Reconciler
Neffens dit model hat it kluster in kontrôler dy't ferantwurdlik is foar it fergelykjen fan Kubernetes-boarnen (YAML-bestannen) yn it Git-repository mei de echte boarnen fan it kluster. As diskrepânsjes wurde ûntdutsen, stjoert de controller notifikaasjes en nimt mooglik aksje om de diskrepânsjes te korrigearjen. Dit GitOps-model wurdt brûkt yn Anthos Config Management en Weaveworks Flux.
Eksterne Resource Reconciler (Push)
Dit model kin wurde beskôge as in fariaasje fan 'e foarige, as wy ien of mear controllers hawwe dy't ferantwurdlik binne foar syngronisaasje fan boarnen yn' e "Git repository - Kubernetes cluster" pearen. It ferskil hjir is dat elk beheard kluster net needsaaklik syn eigen aparte controller hat. Git - k8s kluster pearen wurde faak definiearre as CRDs (oanpaste boarne definysjes), dat kin beskriuwe hoe't de controller moat útfiere syngronisaasje. Binnen dit model fergelykje controllers it Git-repository spesifisearre yn 'e CRD mei de Kubernetes-klusterboarnen, dy't ek yn' e CRD oantsjutte binne, en útfiere passende aksjes basearre op 'e resultaten fan' e fergeliking. Benammen dit GitOps-model wurdt brûkt yn ArgoCD.
GitOps op it OpenShift-platfoarm
Behear fan multi-cluster Kubernetes ynfrastruktuer
Mei de fersprieding fan Kubernetes en de tanimmende populariteit fan multi-wolkstrategyen en edge computing, nimt it gemiddelde oantal OpenShift-klusters per klant ek ta.
Bygelyks, by it brûken fan edge computing, kinne de klusters fan ien klant yn hûnderten of sels tûzenen ynset wurde. As gefolch, hy wurdt twongen om te beheare ferskate ûnôfhinklike of koördinearre OpenShift klusters yn de iepenbiere wolk en on-premise.
Yn dit gefal moatte in protte problemen oplost wurde, benammen:
- Kontrolearje dat de klusters yn in identike steat binne (konfiguraasjes, tafersjoch, opslach, ensfh.)
- Recreate (of weromsette) klusters basearre op in bekende steat.
- Meitsje nije klusters basearre op in bekende steat.
- Rôlje wizigingen út nei meardere OpenShift-klusters.
- Feroarings weromdraaie oer meardere OpenShift-klusters.
- Link sjabloan konfiguraasjes oan ferskate omjouwings.
Applikaasje konfiguraasjes
Tidens har libbenssyklus passe applikaasjes faak troch in ketting fan klusters (dev, poadium, ensfh.) foardat se yn in produksjekluster einigje. Derneist, fanwege beskikberens en skalberens easken, klanten faak ynsette applikaasjes oer meardere on-premise klusters of meardere regio fan in iepenbiere wolk platfoarm.
Yn dit gefal moatte de folgjende taken oplost wurde:
- Soargje foar de beweging fan applikaasjes (binaries, konfiguraasjes, ensfh.) tusken klusters (dev, poadium, ensfh.).
- Rôlje wizigingen út oan applikaasjes (binaries, konfiguraasjes, ensfh.) yn ferskate OpenShift-klusters.
- Feroarje wizigingen nei applikaasjes werom nei in earder bekende steat.
OpenShift GitOps Use Cases
1. Feroarings tapasse fan it Git-repository
In klusterbehearder kin OpenShift-klusterkonfiguraasjes opslaan yn in Git-repository en automatysk tapasse om nije klusters sûnder muoite te meitsjen en se yn in steat te bringen dy't identyk is oan de bekende steat opslein yn it Git-repository.
2. Syngronisaasje mei Secret Manager
De behearder sil ek profitearje fan de mooglikheid om OpenShift-geheime objekten te syngronisearjen mei passende software lykas Vault om se te behearjen mei helpmiddels dy't spesjaal makke binne foar dit.
3. Kontrôle fan drift konfiguraasjes
De admin sil allinich yn it foardiel wêze as OpenShift GitOps sels identifisearret en warskôget oer diskrepânsjes tusken echte konfiguraasjes en de spesifisearre yn it repository, sadat se fluch kinne reagearje op drift.
4. Notifikaasjes oer konfiguraasje drift
Se binne nuttich yn it gefal as de behearder fluch leare wol oer gefallen fan konfiguraasjedrift om fluch op himsels passende maatregels te nimmen.
5. Hânlieding syngronisaasje fan konfiguraasjes as drifting
Lit de admin it OpenShift-kluster syngronisearje mei it Git-repository yn gefal fan konfiguraasjedrift, om it kluster fluch werom te bringen nei in earder bekende steat.
6.Auto-syngronisaasje fan konfiguraasjes by drifting
De behearder kin it OpenShift-kluster ek ynstelle om automatysk te syngronisearjen mei it repository as in drift ûntdutsen wurdt, sadat de klusterkonfiguraasje altyd oerienkomt mei de konfiguraasjes yn Git.
7. Ferskate klusters - ien repository
De behearder kin konfiguraasjes fan ferskate ferskillende OpenShift-klusters opslaan yn ien Git-repository en selektyf tapasse as nedich.
8. Hiërargy fan klusterkonfiguraasjes (erfenis)
De admin kin in hiërargy fan klusterkonfiguraasjes ynstelle yn 'e repository (poadium, prod, appportfolio, ensfh. mei erfskip). Mei oare wurden, it kin bepale oft konfiguraasjes moatte wurde tapast op ien of mear klusters.
As in behearder bygelyks de hiërargy ynstelt "Produksjeklusters (prod) → Systeem X-klusters → Produksjeklusters fan systeem X" yn it Git-repository, dan wurdt in kombinaasje fan de folgjende konfiguraasjes tapast op de produksjeklusters fan systeem X:
- Konfiguraasjes mienskiplik foar alle produksjeklusters.
- Konfiguraasjes foar it System X-kluster.
- Konfiguraasjes foar it X-systeemproduksjekluster.
9. Sjabloanen en konfiguraasje oerskriuwt
De behearder kin in set fan erfde konfiguraasjes en harren wearden oerskriuwe, bygelyks om de konfiguraasje foar spesifike klusters dêr't se sille wurde tapast op te fine.
10. Selektyf befetsje en útslute foar konfiguraasjes, applikaasje konfiguraasjes
De behearder kin de betingsten ynstelle foar de tapassing of net-tapassing fan bepaalde konfiguraasjes foar klusters mei bepaalde skaaimerken.
11. Template stipe
Untwikkelders sille profitearje fan de mooglikheid om te kiezen hoe't applikaasje-boarnen wurde definieare (Helm Chart, pure Kubernetes yaml, ensfh.) Om it meast geskikte formaat te brûken foar elke spesifike applikaasje.
GitOps-ark op it OpenShift-platfoarm
ArgoCD
ArgoCD ymplementearret it External Resource Reconcile-model en biedt in sintralisearre UI foar it orkestrearjen fan ien-nei-folle relaasjes tusken klusters en Git-repositories. De neidielen fan dit programma omfetsje it ûnfermogen om applikaasjes te behearjen as ArgoCD net wurket.
flow
Flux ymplementearret in On-Cluster Resource Reconcile-model en, as gefolch, is d'r gjin sintralisearre behear fan 'e definysje-repository, wat in swak punt is. Oan 'e oare kant, krekt fanwegen it gebrek oan sintralisaasje, bliuwt de mooglikheid om applikaasjes te behearjen, sels as ien kluster mislearret.
ArgoCD ynstalleare op OpenShift
ArgoCD biedt in poerbêste kommandorigelynterface en webkonsole, dus wy sille Flux en oare alternativen hjir net dekke.
Om ArgoCD yn te setten op it OpenShift 4-platfoarm, folgje dizze stappen as klusterbehearder:
ArgoCD-komponinten ynsette op it OpenShift-platfoarm
# 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}')Ferbettering fan ArgoCD Server sadat it kin wurde sjoen troch 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=RedirectArgoCD Cli Tool ynsette
# 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/argocdIt feroarjen fan it ArgoCD Server admin wachtwurd
# 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
Nei it foltôgjen fan dizze stappen kinne jo wurkje mei ArgoCD Server fia de ArgoCD WebUI webkonsole of it ArgoCD Cli kommandorigelark.
GitOps - It is nea te let
"De trein is ferlitten" - dit is wat se sizze oer in situaasje as de kâns om wat te dwaan is mist. Yn it gefal fan OpenShift, de winsk om daliks te begjinnen mei it brûken fan dit koele nije platfoarm makket faaks krekt dizze situaasje mei it behear en ûnderhâld fan rûtes, ynset en oare OpenShift-objekten. Mar wurdt de kâns altyd hielendal mist?
Trochgean fan de rige artikels oer , hjoed sille wy jo sjen litte hoe't jo in mei de hân makke applikaasje en har boarnen transformearje yn in proses wêr't alles wurdt beheard troch GitOps-ark. Om dit te dwaan, sille wy earst de httpd-applikaasje manuell ynsette. De skermôfbylding hjirûnder lit sjen hoe't wy in nammeromte, ynset en tsjinst meitsje, en dan dizze tsjinst bleatstelle om in rûte te meitsjen.
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-appSa hawwe wy in mei de hân makke applikaasje. No moat it wurde oerdroegen ûnder GitOps-behear sûnder ferlies fan beskikberens. Koartsein, it docht dit:
- Meitsje in Git repository foar de koade.
- Wy eksportearje ús hjoeddeistige objekten en uploade se nei it Git-repository.
- GitOps-ark selektearje en ynsette.
- Wy foegje ús repository ta oan dizze toolkit.
- Wy definiearje de applikaasje yn ús GitOps toolkit.
- Wy fiere in testrun fan 'e applikaasje mei de GitOps toolkit.
- Wy syngronisearje objekten mei de GitOps toolkit.
- Skeakelje snoeien en automatyske syngronisaasje fan objekten yn.
Lykas neamd yn 'e foarige , yn GitOps is d'r ien en ien boarne fan ynformaasje oer alle objekten yn 'e Kubernetes-kluster(s) - it Git-repository. Dêrnei geane wy út fan it útgongspunt dat jo organisaasje al in Git-repository brûkt. It kin iepenbier of privee wêze, mar it moat tagonklik wêze foar Kubernetes-klusters. Dit kin itselde repository wêze as foar applikaasjekoade, of in apart repository dat spesifyk makke is foar ynset. It is oan te rieden om strikte tagongsrjochten te hawwen yn 'e repository, om't geheimen, rûtes en oare feiligensgefoelige dingen dêr wurde opslein.
Yn ús foarbyld sille wy in nij iepenbier repository oanmeitsje op GitHub. Jo kinne it neame wat jo wolle, wy brûke de namme blogpost.
As de YAML-objektbestannen net lokaal of yn Git waarden opslein, dan moatte jo de oc- of kubectl-binaries brûke. Yn it skermôfbylding hjirûnder freegje wy YAML foar ús nammeromte, ynset, tsjinst en rûte. Dêrfoar klonen wy it nij oanmakke repository en cd deryn.
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.yamlLitte wy no de deployment.yaml-bestân bewurkje om it fjild te ferwiderjen dat Argo CD net syngronisearje kin.
sed -i '/sgeneration: .*/d' deployment.yamlBoppedat moat de rûte feroare wurde. Wy sille earst in multiline fariabele ynstelle en dan ingress: null ferfange mei de ynhâld fan dy fariabele.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlDat, wy hawwe de bestannen sorteare, alles wat oerbliuwt is om se te bewarjen yn it Git-repository. Dêrnei wurdt dit repository de ienige boarne fan ynformaasje, en alle hânmjittige feroarings oan objekten moatte strang ferbean wurde.
git commit -am ‘initial commit of objects’
git push origin masterFierder geane wy út fan it feit dat jo ArgoCD al hawwe ynset (hoe dit te dwaan - sjoch foarige ). Dêrom sille wy it repository dat wy makke hawwe oan 'e Argo CD tafoegje, mei de applikaasjekoade út ús foarbyld. Soargje gewoan dat jo it krekte repository spesifisearje dat jo earder makke hawwe.
argocd repo add https://github.com/cooktheryan/blogpostLitte wy no de applikaasje oanmeitsje. De applikaasje stelt wearden yn sadat de GitOps toolkit begrypt hokker repository en paden te brûken, hokker OpenShift is nedich om objekten te behearjen, hokker spesifike tûke fan it repository nedich is, en oft boarnen auto-syngronisearje moatte.
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
Sadree't in applikaasje is oantsjutte yn de Argo CD, de toolkit begjint te kontrolearjen al ynset objekten tsjin de definysjes yn de repository. Yn ús foarbyld binne auto-syngronisaasje en skjinmeitsjen útskeakele, sadat de eleminten noch net feroarje. Tink derom dat yn 'e Argo CD-ynterface ús applikaasje de status "Out of Sync" sil hawwe, om't d'r gjin label is dat ArgoCD leveret.
Dit is wêrom as wy begjinne syngronisaasje in bytsje letter, de objekten wurde net opnij ynset.
Litte wy no in testrinne dwaan om te soargjen dat d'r gjin flaters binne yn ús bestannen.
argocd app sync simple-app --dry-runAs d'r gjin flaters binne, kinne jo trochgean mei syngronisaasje.
argocd app sync simple-appNei it útfieren fan it argocd get-kommando op ús applikaasje, moatte wy sjen dat de applikaasjestatus is feroare nei Healthy or Synced. Dit sil betsjutte dat alle boarnen yn it Git-repository no oerienkomme mei dy boarnen dy't al binne ynset.
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
... No kinne jo auto-syngronisaasje en skjinmeitsjen ynskeakelje om te soargjen dat neat mei de hân oanmakke wurdt en dat elke kear as in objekt wurdt oanmakke of bywurke nei it repository, in ynset sil plakfine.
argocd app set simple-app --sync-policy automated --auto-prune
Dat, wy hawwe mei súkses in applikaasje ûnder GitOps-kontrôle brocht dy't GitOps yn earste ynstânsje op gjin inkelde manier brûkte.
Boarne: www.habr.com