Úvod do GitOps pre OpenShift

Dnes vám predstavíme princípy a modely GitOps, ako aj to, ako sa tieto modely implementujú na platforme OpenShift. Interaktívny návod na túto tému je dostupný. na odkaze.

Stručne povedané, GitOps je súbor praktických metód využívania pull-requestov Git na správu konfigurácií infraštruktúry a aplikácií. Git repozitár v rámci GitOps je považovaný za jediný zdroj informácií o stave systému, pričom akékoľvek zmeny tohto stavu sú úplne sledovateľné a podliehajú auditu.

Myšlienka sledovateľnosti zmien v GitOps nie je nová; takýto prístup sa už dlho a prakticky všade aplikuje pri práci s pôvodným kódom aplikácií. GitOps jednoducho realizuje podobné funkcie (review kontroly, pull-requesty, tagy atď.) pri správe konfigurácií infraštruktúry a aplikácií a poskytuje podobné výhody ako pri správe pôvodného kódu.

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

• Deklaratívny popis systému sa uchováva v Git repozitári (konfiguračné súbory, monitorovanie atď.).
• Zmeny stavu sa vykonávajú prostredníctvom pull-requestov.
• Stav fungujúcich systémov sa zladí s údajmi v repozitári pomocou push-requestov Git.

Princípy GitOps

• Definície systémov sú popisované ako zdrojový kód.

Konfigurácia systémov je považovaná za kód, a preto ju možno ukladať a automaticky verzionovať v Git repozitári, ktorý slúži ako jediný zdroj pravdy. Takýto prístup umožňuje ľahko implementovať (rollout) a vrátiť (rollback) zmeny v systémoch.

• Požadovaný stav a konfigurácia systémov sú definované a verzionované v Gite.

Uchovávaním a verzionovaním požadovaného stavu systémov v Gite získavame možnosť ľahko implementovať a vrátiť zmeny v systémoch a aplikáciách. Takisto môžeme využiť Git mechanizmy zabezpečenia na kontrolu vlastníctva kódu a potvrdenia jeho autenticity.

• Zmeny v konfiguráciách môžu byť automaticky aplikované pomocou pull-requestov.

Použitím Gitových pull-requestů můžeme snadno spravovat, jak se změny aplikují na konfigurace v repozitáři. Například je můžeme předat k revizi ostatním členům týmu nebo je spustit přes CI testy a další.

A přitom není třeba všem rozdávat administrátorské pravomoci napravo a nalevo. Pro provedení commitu změn v konfiguraci stačí uživatelům odpovídající pravomoci v Git repozitáři, kde se tyto konfigurace ukládají.

• Odstranění problému nekontrolovatelného driftu konfigurací

Když je žádoucí stav systému uložen v Git repozitáři, zbývá nám pouze najít software, který by kontroloval, zda aktuální stav systému odpovídá jeho žádoucímu stavu. Pokud tomu tak není, měl by tento software – v závislosti na nastavení – buď samostatně odstranit nesoulad, nebo nás upozornit na drift konfigurací.

Modely GitOps pro OpenShift

On-Cluster Resource Reconciler

Podle tohoto modelu existuje v clusteru kontroler, který odpovídá za srovnání Kubernetes zdrojů (YAML soubory) v Git repozitáři s reálnými zdroji clusteru. Při zjištění nesrovnalostí kontroler zasílá upozornění a, možná, přijímá opatření k odstranění nesouladu. Tento model GitOps se používá v Anthos Config Management a Weaveworks Flux.

External Resource Reconciler (Push)

Tento model lze považovat za variantu předchozího, kdy máme jednoho nebo více kontrolerů odpovídajících za synchronizaci zdrojů v párech „Git repozitář – Kubernetes cluster“. Rozdíl je v tom, že v každém spravovaném clusteru nemusí být svůj vlastní samostatný kontroler. Pary „Git – k8s cluster“ jsou často definovány jako CRD popisy (custom resources definition), ve kterých lze popsat, jak by měl kontroler provádět synchronizaci. V rámci tohoto modelu kontrolery srovnávají Git repozitář, uvedený v CRD, se zdroji clusteru Kubernetes, které jsou také uvedeny v CRD, a provádějí příslušné akce na základě výsledků srovnávání. Tento model GitOps se používá v ArgoCD.

GitOps na platformě OpenShift

Administrace multiclusterové Kubernetes infrastruktury

S rozšiřováním Kubernetes a rostoucí popularitou strategii multi-cloud a periferního výpočetnictví (edge computing) se zvyšuje i průměrný počet clusterů OpenShift na jednoho zákazníka.

Napríklad pri používaní periférnych výpočtov môžu klastre jedného zákazníka byť nasadené v stovkách a dokonca tisícoch. V dôsledku toho musí spravovať niekoľko nezávislých alebo zladených klastrov OpenShift v verejnom cloude a na on-premise.

Pri tom je potrebné riešiť množstvo problémov, predovšetkým:

• Kontrolovať, či sú klastre v identickom stave (konfigurácie, monitorovanie, úložiská a pod.).
• Znova vytvárať (alebo obnovovať) klastre podľa známeho stavu.
• Vytvárať nové klastre podľa známeho stavu.
• Aplikovať zmeny na viacerých klastroch OpenShift.
• Späťrolovať zmeny na viacerých klastroch OpenShift.
• Prepojiť šablónizované konfigurácie s rôznymi prostrediami.

Konfigurácie aplikácií

V priebehu svojho životného cyklu aplikácie často prechádzajú reťazcom klastrov (dev, stage a pod.) predtým, ako sa dostanú do produkčného klastru. Okrem toho, kvôli požiadavkám na dostupnosť a škálovateľnosť, zákazníci často nasadzujú aplikácie naraz na viacerých klastroch on-premise alebo v niekoľkých regiónoch verejnej cloudovej platformy.

Pri tom je potrebné riešiť nasledujúce úlohy:

• Zabezpečiť pohyb aplikácií (binárky, konfigurácie a pod.) medzi klastrami (dev, stage a pod.).
• Aplikovať zmeny v aplikáciách (binárky, konfigurácie a pod.) na viacerých klastroch OpenShift.
• Späťrolovať zmeny v aplikáciách na úroveň predchádzajúceho známeho stavu.

Scenáre použitia OpenShift GitOps

1. Aplikovanie zmien z Git-repozitára

Administrátor klastru môže uchovávať konfigurácie klastru OpenShift v Git-repozitári a automaticky ich aplikovať, aby mohol bez zbytočného úsilia vytvárať nové klastre a uvádzať ich do stavu, ktorý je identický so známym stavom uloženým v Git-repozitári.

2. Synchronizácia s Secret Managerom

Administrátorovi sa určite zíde možnosť synchronizovať secret-objekty OpenShift s príslušným softvérom ako Vault, aby ich mohol spravovať pomocou špeciálne vytvorených nástrojov.

3. Kontrola driftu konfigurácií

Administrátor bude len rád, ak OpenShift GitOps sám identifikuje a upozorní na nezhody medzi reálnymi konfiguráciami a tými, ktoré sú stanovené v repozitári, aby bolo možné rýchlo reagovať na drift.

4. Oznámenia o odchýlkach konfigurácií

Prídu vhod, keď administrátor chce rýchlo získať informácie o prípadoch odchýlok konfigurácií, aby mohol rýchlo prijať vhodné opatrenia.

5. Ručná synchronizácia konfigurácií pri odchýlkach

Umožňuje administrátorovi synchronizovať klaster OpenShift s repozitárom Git v prípade odchýlok konfigurácií, aby rýchlo vrátil klaster do predchádzajúceho známeho stavu.

6. Automatická synchronizácia konfigurácií pri odchýlkach

Administrátor môže tiež nastaviť klaster OpenShift na automatickú synchronizáciu s repozitárom pri zistení odchýlok, aby konfigurácia klastrov vždy zodpovedala konfiguráciám v Gite.

7. Viac klastrov – jeden repozitár

Administrátor môže uchovávať v jednom repozitári Git konfigurácie viacerých rôznych klastrov OpenShift a selektívne ich aplikovať podľa potreby.

8. Hierarchia klastrových konfigurácií (dedenie)

Administrátor môže nastaviť hierarchiu klastrových konfigurácií v repozitári (stage, prod, app portfolio atď. s dedením). Inými slovami, môže definovať, ako by sa mali aplikovať konfigurácie – na jeden alebo na niekoľko klastrov.

Napríklad, ak administrátor nastaví v repozitári Git hierarchiu „Produkčné klastry (prod) → Klastre systému X → Produkčné klastry systému X“, na produkčné klastry systému X sa aplikuje kombinácia nasledujúcich konfigurácií:

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

9. Šablóny a prepisovanie konfigurácií

Administrátor môže prepísať súbor dedičných konfigurácií a ich hodnôt, napríklad aby lepšie nastavil konfiguráciu pre konkrétne klastry, na ktoré budú aplikované.

10. Selektívne include-y a exclude-y pre konfigurácie, konfigurácie aplikácií

Administrátor môže nastaviť podmienky pre aplikovanie alebo neaplikovanie rôznych konfigurácií na klastre s určitými charakteristikami.

11. Podpora šablón

Vývojárom sa zapáči možnosť vybrať, ako budú definované zdroje aplikácie (Helm Chart, čistý Kubernetes yaml atď.), aby mohli použiť najvhodnejší formát pre každú konkrétnu aplikáciu.

Nástroje GitOps na platforme OpenShift

ArgoCD

ArgoCD implementuje model External Resource Reconcile a ponúka centralizované UI na orchestráciu vzťahov medzi klastrami a Git repozitármi v schéme "jeden ku mnohým". Medzi nevýhody tejto aplikácie patrí nemožnosť spravovať aplikácie, keď ArgoCD nefunguje.

Oficiálna stránka

Flux

Flux implementuje model On-Cluster Resource Reconcile, a preto tu neexistuje centralizované riadenie repozitárom definícií, čo predstavuje slabé miesto. Na druhej strane, práve pre absenciu centralizácie je možné spravovať aplikácie aj v prípade zlyhania jedného klastra.

Oficiálna stránka

Inštalácia ArgoCD na OpenShift

ArgoCD ponúka vynikajúce rozhranie príkazového riadku a webovú konzolu, takže sa tu nebudeme venovať Flux a iným alternatívam.

Na nasadenie ArgoCD na platforme OpenShift 4 vykonajte nasledujúce kroky ako administrátor klastra:

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

Úprava ArgoCD Server tak, aby ho videl 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 admin hesla ArgoCD Server

# 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 vykonaní týchto krokov je možné pracovať s ArgoCD Server cez webovú konzolu ArgoCD WebUI alebo príkazový nástroj 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ď bola príležitosť na niečo zabudnutá. V prípade OpenShift túžba okamžite začať používať túto novú skvelú platformu často vytvára presne takú situáciu so správou a údržbou trás, nasadení a iných objektov OpenShift. Je však vždy šanca definitívne zmeškaná?

Pokračujeme v sérii článkov o GitOps, dnes ukážeme, ako transformovať ručne vytvorenú aplikáciu a jej zdroje na proces, v ktorom všetko spravuje nástroj GitOps. Na to najprv ručne nasadíme aplikáciu httpd. Na obrázku nižšie vidíte, ako vytvárame priestor mien, nasadenie a službu, a potom túto službu vystavíme, aby sme vytvorili trasu.

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 vytvorenú aplikáciu. Teraz ju treba previesť pod správu GitOps bez straty dostupnosti. Stručne povedané, funguje to takto:

• Vytvárame Git repozitár pre kód.
• Exportujeme naše aktuálne objekty a nahrávame ich do repozitára Git.
• Vyberáme a nasadzujeme nástroj GitOps.
• Pridávame do tohto nástroja náš repozitár.
• Definujeme aplikáciu v našom nástroji GitOps.
• Vykonávame skúšobný štart aplikácie pomocou nástroja GitOps.
• Synchronizujeme objekty pomocou nástroja GitOps.
• Aktivujeme čistenie (pruning) a automatickú synchronizáciu objektov.

Ako už bolo spomenuté predtým, článku, v GitOps existuje jeden a len jeden zdroj informácií o všetkých objektoch v klastroch Kubernetes – repozitár Git. Ďalej vychádzame z predpokladu, že vo vašej organizácii sa už používa Git-repozitár. Môže byť verejný alebo súkromný, ale musí byť prístupný klastrom Kubernetes. Môže to byť ten istý repozitár, ktorý sa používa pre kód aplikácií, alebo samostatný repozitár vytvorený špeciálne pre deployments. V repozitári sa odporúča mať prísne povolenia, pretože tam budú uložené objekty secret, trasy a iné citlivé na bezpečnosť veci.

V našom príklade vytvoríme nový verejný repozitár na GitHub. Môžeme ho nazvať akokoľvek, my používame názov blogpost.

Ak YAML súbory objektov neboli uložené lokálne alebo v Gite, bude potrebné využiť binárne súbory oc alebo kubectl. Na obrazovke nižšie požiadame o YAML pre náš priestor názvov, deployment, službu a trasu. Predtým sme skopírovali práve vytvorený repozitár a prešli do neho príkazom cd.

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 opravíme súbor deployment.yaml, aby sme odstránili pole, ktoré Argo CD nemôže synchronizovať.

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

Okrem toho musíme zmeniť trasu. Najprv definujeme 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

Tak, s súbormi sme sa vyrovnali, zostáva ich uložiť do Git-repozitára. Potom sa tento repozitár stáva jediným zdrojom informácií a akékoľvek ručné zmeny objektov by mali byť prísne zakázané.

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

Ďalej vychádzame z toho, že ArgoCD už máte nasadené (ako to urobiť – pozrite predchádzajúce príspevok). Preto pridáme do Argo CD náš vytvorený repozitár, ktorý obsahuje kód aplikácie z nášho príkladu. Len sa uistite, že uvádzate presne ten repozitár, ktorý ste vytvorili skôr.

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

Teraz vytvárame aplikáciu. Aplikácia určuje hodnoty, aby nástroj GitOps rozumel, ktorý repozitár a cesty použiť, ktorý OpenShift je potrebný na správu objektov, ako aj ktorá konkrétna vetva repozitára je potrebná a či by mala bežať automatická synchronizácia zdrojov.

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

Akonáhle je aplikácia zadaná v Argo CD, tento nástroj začína kontrolovať už nasadené objekty na súlad s definíciami v repozitári. 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 „Out of Sync“ (Nesynchronizované), pretože nie je žiadna label-štítok, ktorý by ArgoCD priradil.
Práve preto, keď neskôr spustíme synchronizáciu, opätovné nasadenie objektov sa nevykoná.

Teraz vykonáme skúšobný beh, 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ôžeme prejsť k synchronizácii.

argocd app sync simple-app

Po vykonaní príkazu argocd get nad našou aplikáciou by sme mali vidieť, že stav aplikácie sa zmenil na Healthy (Zdravé) alebo Synced (Synchronizované). To znamená, že všetky zdroje v repozitári Git teraz zodpovedajú tým zdrojom, 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:        
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

A teraz už môžeme zapnúť automatickú synchronizáciu a čistenie, aby sme zabezpečili, že nič nebude vytvorené manuálne a že zakaždým, keď je objekt vytvorený alebo aktualizovaný v repozitári, bude sa vykonávať nasadenie.

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

Takže sme úspešne previedli aplikáciu pod riadenie GitOps, ktorá pôvodne vôbec nepoužívala GitOps.

Zdroj: habr.com