Úvod do GitOps pre OpenShift

Dnes si povieme niečo o princípoch a modeloch GitOps, ako aj o tom, ako sú tieto modely implementované na platforme OpenShift. K dispozícii je interaktívny sprievodca na túto tému по ссылке.

Stručne povedané, GitOps je súbor postupov na používanie žiadostí Git pull na správu konfigurácií infraštruktúry a aplikácií. S úložiskom Git v GitOps sa zaobchádza ako s jediným zdrojom informácií o stave systému a akékoľvek zmeny tohto stavu sú plne sledovateľné a auditovateľné.

Myšlienka sledovania zmien v GitOps nie je v žiadnom prípade nová; tento prístup sa už dlho používa takmer univerzálne pri práci so zdrojovým kódom aplikácie. GitOps jednoducho implementuje podobné funkcie (recenzie, pull requesty, tagy atď.) do správy infraštruktúry a konfigurácie aplikácií a poskytuje podobné výhody ako v prípade správy zdrojového kódu.

Neexistuje žiadna akademická definícia ani schválený súbor pravidiel pre GitOps, iba súbor princípov, na ktorých je táto prax postavená:

• Deklaratívny popis systému je uložený v úložisku Git (konfigurácie, monitorovanie atď.).
• Zmeny stavu sa vykonávajú prostredníctvom žiadostí o stiahnutie.
• Stav spustených systémov je zosúladený s údajmi v úložisku pomocou Git push requestov.

Princípy GitOps

• Definície systému sú opísané ako zdrojový kód

Konfigurácia systémov sa považuje za kód, takže môže byť uložená a automaticky verzovaná v úložisku Git, ktoré slúži ako jediný zdroj pravdy. Tento prístup uľahčuje zavedenie a vrátenie zmien v systémoch.

• Požadovaný stav a konfigurácia systémov sú nastavené a verzované v Git

Uložením a verzovaním požadovaného stavu systémov v systéme Git sme schopní jednoducho zaviesť a vrátiť zmeny do systémov a aplikácií. Môžeme tiež použiť bezpečnostné mechanizmy Git na kontrolu vlastníctva kódu a overenie jeho pravosti.

• Zmeny konfigurácie je možné automaticky aplikovať prostredníctvom požiadaviek na stiahnutie

Pomocou žiadostí Git pull môžeme jednoducho kontrolovať, ako sa zmeny aplikujú na konfigurácie v úložisku. Môžu byť napríklad poskytnuté iným členom tímu na preskúmanie alebo vykonanie testov CI atď.

A zároveň nie je potrebné rozdeľovať právomoci správcu vľavo a vpravo. Na potvrdenie zmien konfigurácie potrebujú používatelia iba príslušné povolenia v úložisku Git, kde sú tieto konfigurácie uložené.

• Riešenie problému nekontrolovaného posunu konfigurácií

Keď je požadovaný stav systému uložený v úložisku Git, už nám ostáva len nájsť softvér, ktorý zabezpečí, aby sa aktuálny stav systému zhodoval s požadovaným stavom. Ak tomu tak nie je, potom by mal tento softvér – v závislosti od nastavení – buď odstrániť nezrovnalosť sám, alebo nás upozorniť na posun konfigurácie.

Modely GitOps pre OpenShift

On-Cluster Resource Reconciler

Podľa tohto modelu má klaster radič, ktorý je zodpovedný za porovnávanie zdrojov Kubernetes (súbory YAML) v úložisku Git so skutočnými zdrojmi klastra. Ak sa zistia nezrovnalosti, kontrolór pošle upozornenia a prípadne podnikne kroky na nápravu nezrovnalostí. Tento model GitOps sa používa v Anthos Config Management a Weaveworks Flux.

Externý zdroj zosúladenia (push)

Tento model možno považovať za variáciu predchádzajúceho, keď máme jeden alebo viac radičov zodpovedných za synchronizáciu zdrojov v pároch „Git repository - Kubernetes cluster“. Rozdiel je v tom, že každý riadený klaster nemusí mať nevyhnutne svoj vlastný samostatný radič. Páry klastrov Git - k8s sú často definované ako CRD (vlastné definície prostriedkov), ktoré môžu popisovať, ako by mal radič vykonávať synchronizáciu. V rámci tohto modelu radiče porovnávajú úložisko Git špecifikované v CRD s klastrovými prostriedkami Kubernetes, ktoré sú tiež špecifikované v CRD, a na základe výsledkov porovnania vykonávajú príslušné akcie. Najmä tento model GitOps sa používa v ArgoCD.

GitOps na platforme OpenShift

Správa multiklastrovej infraštruktúry Kubernetes

S rozširovaním Kubernetes a rastúcou popularitou multicloudových stratégií a edge computingu sa zvyšuje aj priemerný počet klastrov OpenShift na zákazníka.

Napríklad pri použití edge computingu môžu byť klastre jedného zákazníka nasadené v stovkách alebo dokonca tisíckach. V dôsledku toho je nútený spravovať niekoľko nezávislých alebo koordinovaných klastrov OpenShift vo verejnom cloude a on-premise.

V tomto prípade je potrebné vyriešiť veľa problémov, najmä:

• Kontrola, či sú klastre v identickom stave (konfigurácie, monitorovanie, úložisko atď.)
• Znovu vytvorte (alebo obnovte) klastre na základe známeho stavu.
• Vytvorte nové klastre na základe známeho stavu.
• Zaveďte zmeny do viacerých klastrov OpenShift.
• Vráťte späť zmeny vo viacerých klastroch OpenShift.
• Prepojte konfigurácie podľa šablóny s rôznymi prostrediami.

Konfigurácie aplikácií

Aplikácie počas svojho životného cyklu často prechádzajú reťazcom klastrov (dev, stage atď.), kým skončia v produkčnom klastri. Okrem toho z dôvodu požiadaviek na dostupnosť a škálovateľnosť zákazníci často nasadzujú aplikácie do viacerých on-premise klastrov alebo viacerých oblastí verejnej cloudovej platformy.

V tomto prípade je potrebné vyriešiť nasledujúce úlohy:

• Zabezpečte pohyb aplikácií (binárnych súborov, konfigurácií atď.) medzi klastrami (dev, stage atď.).
• Zaveďte zmeny do aplikácií (binárne súbory, konfigurácie atď.) v niekoľkých klastroch OpenShift.
• Vrátiť zmeny v aplikáciách do predchádzajúceho známeho stavu.

Prípady použitia OpenShift GitOps

1. Aplikovanie zmien z úložiska Git

Správca klastra môže ukladať konfigurácie klastrov OpenShift v úložisku Git a automaticky ich použiť na jednoduché vytváranie nových klastrov a ich uvedenie do stavu identického so známym stavom uloženým v úložisku Git.

2. Synchronizácia s Secret Manager

Správca bude ťažiť aj zo schopnosti synchronizovať tajné objekty OpenShift s príslušným softvérom, ako je Vault, aby ich mohol spravovať pomocou nástrojov špeciálne vytvorených na tento účel.

3. Kontrola konfigurácií driftu

Správca bude len za to, ak samotný OpenShift GitOps identifikuje a upozorní na nezrovnalosti medzi skutočnými konfiguráciami a konfiguráciami špecifikovanými v úložisku, aby mohli rýchlo reagovať na drift.

4. Upozornenia na posun konfigurácie

Sú užitočné v prípade, keď sa administrátor chce rýchlo dozvedieť o prípadoch posunu konfigurácie, aby mohol sám rýchlo prijať vhodné opatrenia.

5. Manuálna synchronizácia konfigurácií pri driftovaní

Umožňuje správcovi synchronizovať klaster OpenShift s úložiskom Git v prípade posunu konfigurácie, aby sa klaster rýchlo vrátil do predchádzajúceho známeho stavu.

6.Automatická synchronizácia konfigurácií pri driftovaní

Správca môže tiež nakonfigurovať klaster OpenShift na automatickú synchronizáciu s úložiskom, keď sa zistí posun, takže konfigurácia klastra sa vždy zhoduje s konfiguráciami v systéme Git.

7. Niekoľko klastrov – jedno úložisko

Správca môže uložiť konfigurácie niekoľkých rôznych klastrov OpenShift do jedného úložiska Git a selektívne ich použiť podľa potreby.

8. Hierarchia konfigurácií klastrov (dedičnosť)

Správca môže nastaviť hierarchiu konfigurácií klastra v úložisku (fáza, produkt, portfólio aplikácií atď. s dedičnosťou). Inými slovami, môže určiť, či sa majú konfigurácie použiť na jeden alebo viac klastrov.

Ak napríklad administrátor nastaví hierarchiu „Produkčné klastre (prod) → Klastre systému X → Produkčné klastre systému X“ v úložisku Git, na produkčné klastre systému X sa použije kombinácia nasledujúcich konfigurácií:

• Konfigurácie spoločné pre všetky produkčné klastre.
• Konfigurácie pre klaster System X.
• Konfigurácie pre produkčný klaster systému X.

9. Šablóny a prepisy konfigurácie

Správca môže prepísať množinu zdedených konfigurácií a ich hodnôt, napríklad na doladenie konfigurácie pre konkrétne klastre, na ktoré sa použijú.

10. Selektívne zahrnutie a vylúčenie pre konfigurácie, konfigurácie aplikácií

Administrátor môže nastaviť podmienky pre aplikáciu alebo neaplikáciu určitých konfigurácií na klastre s určitými vlastnosťami.

11. Podpora šablón

Vývojári budú ťažiť z možnosti vybrať si, ako budú definované aplikačné zdroje (Helm Chart, čistý Kubernetes yaml atď.), aby použili najvhodnejší formát pre každú konkrétnu aplikáciu.

Nástroje GitOps na platforme OpenShift

ArgoCD

ArgoCD implementuje model zosúladenia externých zdrojov a ponúka centralizované používateľské rozhranie na organizovanie vzťahov typu one-to-many medzi klastrami a úložiskami Git. Medzi nevýhody tohto programu patrí nemožnosť spravovať aplikácie, keď ArgoCD nefunguje.

Oficiálne internetové stránky

Prúdenie

Flux implementuje On-Cluster Resource Reconcile model a v dôsledku toho neexistuje centralizovaná správa úložiska definícií, čo je slabá stránka. Na druhej strane práve kvôli chýbajúcej centralizácii zostáva možnosť spravovať aplikácie aj v prípade zlyhania jedného klastra.

Oficiálne internetové stránky

Inštalácia ArgoCD na OpenShift

ArgoCD ponúka vynikajúce rozhranie príkazového riadku a webovú konzolu, takže sa tu nebudeme zaoberať Fluxom a inými alternatívami.

Ak chcete nasadiť ArgoCD na platforme OpenShift 4, postupujte ako správca klastra podľa týchto krokov:

Nasadenie komponentov ArgoCD na platforme OpenShift

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

Vylepšenie ArgoCD Servera tak, aby ho bolo možné vidieť pomocou 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

Nasadenie 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

Zmena hesla správcu servera ArgoCD

# 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

Po dokončení týchto krokov môžete so serverom ArgoCD pracovať prostredníctvom webovej konzoly ArgoCD WebUI alebo nástroja príkazového riadka ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – Nikdy nie je neskoro

„Vlak odišiel“ - takto sa hovorí o situácii, keď sa premeškala príležitosť niečo urobiť. V prípade OpenShift túžba okamžite začať používať túto skvelú novú platformu často vytvára presne túto situáciu pri správe a údržbe trás, nasadení a iných objektov OpenShift. Je však šanca vždy úplne stratená?

Pokračovanie série článkov o GitOps, dnes vám ukážeme, ako premeniť ručne vyrobenú aplikáciu a jej zdroje na proces, kde všetko riadia nástroje GitOps. Aby sme to dosiahli, najprv manuálne nasadíme aplikáciu httpd. Snímka obrazovky nižšie ukazuje, ako vytvoríme priestor názvov, nasadenie a službu a potom túto službu vystavíme na vytvorenie trasy.

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

Takže máme ručne vyrobenú aplikáciu. Teraz ho treba preniesť pod správu GitOps bez straty dostupnosti. V skratke to robí toto:

• Vytvorte úložisko Git pre kód.
• Exportujeme naše aktuálne objekty a nahrávame ich do úložiska Git.
• Výber a nasadenie nástrojov GitOps.
• Do tejto sady nástrojov pridávame naše úložisko.
• Aplikáciu definujeme v našej sade nástrojov GitOps.
• Vykonávame testovaciu prevádzku aplikácie pomocou sady nástrojov GitOps.
• Objekty synchronizujeme pomocou sady nástrojov GitOps.
• Povoliť orezávanie a automatickú synchronizáciu objektov.

Ako bolo uvedené v predchádzajúcom článok, v GitOps existuje jeden a jediný zdroj informácií o všetkých objektoch v klastri Kubernetes – úložisko Git. Ďalej vychádzame z predpokladu, že vaša organizácia už používa úložisko Git. Môže byť verejný alebo súkromný, ale musí byť prístupný pre klastre Kubernetes. Môže to byť rovnaké úložisko ako pre kód aplikácie alebo samostatné úložisko vytvorené špeciálne pre nasadenia. Odporúča sa mať prísne oprávnenia v úložisku, pretože sa tam budú ukladať tajomstvá, cesty a ďalšie veci citlivé na bezpečnosť.

V našom príklade vytvoríme nové verejné úložisko na GitHub. Môžete to nazvať ako chcete, my používame názov blogpost.

Ak súbory objektov YAML neboli uložené lokálne alebo v Git, budete musieť použiť binárne súbory oc alebo kubectl. Na snímke obrazovky nižšie požadujeme YAML pre náš menný priestor, nasadenie, službu a trasu. Predtým sme naklonovali novovytvorený repozitár a cd do neho.

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

Teraz upravme súbor deployment.yaml, aby sme odstránili pole, ktoré Argo CD nedokáže synchronizovať.

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

Okrem toho treba zmeniť trasu. Najprv nastavíme viacriadkovú premennú a potom nahradíme ingress: null obsahom tejto premennej.

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

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

Súbory sme teda vytriedili, zostáva ich už len uložiť do úložiska Git. Potom sa toto úložisko stane jediným zdrojom informácií a akékoľvek manuálne zmeny objektov by mali byť prísne zakázané.

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

Ďalej vychádzame zo skutočnosti, že ste už nasadili ArgoCD (ako to urobiť - pozri predchádzajúce pošta). Preto na Argo CD pridáme nami vytvorený repozitár obsahujúci aplikačný kód z nášho príkladu. Len sa uistite, že ste zadali presné úložisko, ktoré ste vytvorili predtým.

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

Teraz poďme vytvoriť aplikáciu. Aplikácia nastavuje hodnoty tak, aby súprava nástrojov GitOps pochopila, ktoré úložisko a cesty použiť, ktorý OpenShift je potrebný na správu objektov, ktorá konkrétna vetva úložiska je potrebná a či sa majú zdroje automaticky synchronizovať.

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

Keď je aplikácia špecifikovaná na Argo CD, sada nástrojov začne kontrolovať už nasadené objekty podľa definícií v úložisku. V našom príklade je automatická synchronizácia a čistenie vypnuté, takže prvky sa zatiaľ nemenia. Upozorňujeme, že v rozhraní Argo CD bude mať naša aplikácia stav „Mimo synchronizácie“, pretože neexistuje žiadny štítok, ktorý poskytuje ArgoCD.
To je dôvod, prečo, keď začneme synchronizáciu o niečo neskôr, objekty nebudú znovu rozmiestnené.

Teraz urobme skúšobnú prevádzku, aby sme sa uistili, že v našich súboroch nie sú žiadne chyby.

argocd app sync simple-app --dry-run

Ak nie sú žiadne chyby, môžete pokračovať v synchronizácii.

argocd app sync simple-app

Po spustení príkazu argocd get v našej aplikácii by sme mali vidieť, že stav aplikácie sa zmenil na Healthy alebo Synced. To bude znamenať, že všetky prostriedky v úložisku Git teraz zodpovedajú tým prostriedkom, ktoré už boli nasadené.

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
...   

Teraz môžete povoliť automatickú synchronizáciu a čistenie, aby ste sa uistili, že sa nič nevytvorí manuálne a že pri každom vytvorení objektu alebo aktualizácii do úložiska dôjde k nasadeniu.

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

Úspešne sme teda dostali pod kontrolu GitOps aplikáciu, ktorá pôvodne GitOps žiadnym spôsobom nevyužívala.

Zdroj: hab.com