Úvod do GitOps pro OpenShift

Dnes si povíme o principech a modelech GitOps a o tom, jak se tyto modely implementují na platformě OpenShift. Interaktivní příručka na toto téma je k dispozici na odkazu.

Stručně řečeno, GitOps je soubor praktických metod, jak používat pull-requesty Git k řízení konfigurací infrastruktury a aplikací. Gitový repozitář v rámci GitOps je považován za jediný zdroj informací o stavu systému, přičemž všechny změny tohoto stavu jsou plně sledovány a podléhají auditu.

Myšlenka sledování změn v GitOps není nová; tento přístup se již dlouho a prakticky běžně používá při práci se zdrojovým kódem aplikací. GitOps prostě implementuje podobné funkce (review-checky, pull-requesty, tagy atd.) při správě konfigurací infrastruktury a aplikací a poskytuje obdobné výhody, jako v případě správy zdrojového kódu.

Pro GitOps neexistuje žádná akademická definice nebo schválený soubor pravidel, pouze soubor principů, na kterých se tato praxe zakládá:

• Deklarativní popis systému je uložen v Git repozitáři (konfigurace, monitoring atd.).
• Změny stavu se provádějí prostřednictvím pull-requestů.
• Stav provozovaných systémů se uvádí do souladu s daty v repozitáři pomocí push-requestů Git.

Principy GitOps

• Definice systémů jsou popsány jako zdrojový kód

Konfigurace systémů je považována za kód, takže ji lze uchovávat a automaticky verzovat v Git repozitáři, který slouží jako jediný pravdivý zdroj. Tento přístup umožňuje snadné nasazování (rollout) a vracení (rollback) změn v systémech.

• Požadovaný stav a konfigurace systémů jsou definovány a verzovány v Gitu

Uchováváním a verzováním žádoucího stavu systémů v Gitu získáváme možnost snadno nasazovat a vracet změny v systémech a aplikacích. Můžeme také využívat Gitové bezpečnostní mechanismy pro kontrolu vlastnictví kódu a potvrzení jeho pravosti.

• Změny v konfiguracích mohou být automaticky aplikovány pomocí pull-requestů

Pomocí 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 ověření ostatním členům týmu nebo je spustit skrze CI testy.

A přitom není potřeba dávat administrátorské oprávnění na všechny strany. Aby mohli commitnout změny v konfiguraci, uživatelé potřebují odpovídající oprávnění v Git repozitáři, kde jsou tyto konfigurace uloženy.

• Řešení problému nekontrolovatelného driftu konfigurací

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

Modely GitOps pro OpenShift

On-Cluster Resource Reconciler

Podle tohoto modelu je v clusteru kontrolér, který odpovídá za porovnání Kubernetes zdrojů (YAML souborů) v Git repozitáři s reálnými zdroji clusteru. Při zjištění nesrovnalostí kontrolér rozesílá upozornění a může přijmout opatření k odstranění nesouladů. Tento model GitOps se používá v Anthos Config Management a Weaveworks Flux.

External Resource Reconciler (Push)

Tento model můžeme považovat za variantu předchozího, kdy máme jednoho nebo více kontrolérů, kteří odpovídají 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 nutně vlastní kontrolér. Přiřazení „Git – k8s cluster“ se často definuje jako CRD popisy (custom resources definition), v nichž lze popsat, jak by měl kontrolér provádět synchronizaci. V rámci tohoto modelu kontroléry porovnávají Git repozitář určený v CRD se zdroji Kubernetes clusteru, které jsou také definovány v CRD, a provádějí příslušné akce na základě výsledků porovnání. Tento model GitOps se používá v ArgoCD.

GitOps na platformě OpenShift

Administrace multi-clusterové Kubernetes infrastruktury

S rozšířením Kubernetes a rostoucí popularitou vícecloudových strategií a edge computingu se zvyšuje také průměrný počet clusterů OpenShift na jednoho zákazníka.

Například při využívání periferního výpočtu mohou být clustery jednoho zákazníka nasazovány stovkami a dokonce tisíci. V důsledku toho je nucen spravovat několik nezávislých nebo propojených clusterů OpenShift v veřejném cloudu a na místě.

Přitom je nutné vyřešit řadu problémů, zejména:

• Kontrolovat, zda jsou clustery v identickém stavu (konfigurace, monitorování, úložiště atd.).
• Znovu vytvářet (nebo obnovovat) clustery na známém stavu.
• Vytvářet nové clustery na známém stavu.
• Aplikovat změny na několika clusterech OpenShift.
• Vrátit změny na několika clusterech OpenShift.
• Propojovat šablonizované konfigurace s různými prostředími.

Konfigurace aplikace

Během svého životního cyklu aplikace často procházejí řadou clusterů (dev, stage atd.), než se dostanou do produkčního clusteru. Navíc vzhledem k požadavkům na dostupnost a škálovatelnost zákazníci často nasazují aplikace současně na několika clusterech on-premise nebo v několika regionech veřejné cloudové platformy.

Přitom se musí vyřešit následující úkoly:

• Zajišťovat pohyb aplikací (binární soubory, konfigurace atd.) mezi clustery (dev, stage atd.).
• Aplikovat změny v aplikacích (binární soubory, konfigurace atd.) na několika clusterech OpenShift.
• Vrátit změny v aplikacích na úroveň předchozího známého stavu.

Scénáře použití OpenShift GitOps

1. Aplikace změn z Git-repozitáře

Správce clusteru může uchovávat konfigurace clusteru OpenShift v Git-repozitáři a automaticky je aplikovat, aby bez zbytečných problémů vytvářel nové clustery a uváděl je do stavu, který je identický s známým stavem uloženým v Git-repozitáři.

2. Synchronizace s Secret Manager

Správci se také hodí možnost synchronizovat secret objekty OpenShift s odpovídajícím softwarem, jako je Vault, aby je mohl spravovat pomocí speciálně vytvořených nástrojů.

3. Kontrola odchylek konfigurací

Správce bude jen rád, pokud OpenShift GitOps sám identifikuje a varuje před rozdíly mezi reálnými konfiguracemi a těmi, které jsou nastaveny v repozitáři, aby bylo možné okamžitě reagovat na odchylky.

4. Oznámení o odchylkách konfigurací

Užitečné v případě, kdy administrátor chce rychle zjistit odchylky konfigurací, aby mohl okamžitě přijmout odpovídající opatření sám.

5. Ruční synchronizace konfigurací při odchylkách

Umožňuje administrátorovi synchronizovat cluster OpenShift s repozitářem Git v případě odchylky konfigurací, aby rychle vrátil cluster do předchozí známé podoby.

6. Automatická synchronizace konfigurací při odchylkách

Administrátor může také nastavit cluster OpenShift na automatickou synchronizaci s repozitářem při zjištění odchylky, aby konfigurace clusteru vždy odpovídala konfiguracím v Gitu.

7. Několik clusterů – jeden repozitář

Administrátor může uchovávat v jednom repozitáři Git konfigurace několika různých clusterů OpenShift a cíleně je aplikovat podle potřeby.

8. Hierarchie clusterových konfigurací (dědění)

Administrátor může v repozitáři nastavit hierarchii clusterových konfigurací (staging, produkce, portfolio aplikací atd. s děděním). Jinými slovy, může určit, jak mají být konfigurace aplikovány – na jeden nebo na více clusterů.

Například, pokud administrátor nastaví v Git repozitáři hierarchii „Produkční clustery (prod) → Clustery systému X → Produkční clustery systému X“, pak se na produkční clustery systému X použijí kombinace následujících konfigurací:

• Konfigurace platné pro všechny produkční clustery.
• Konfigurace pro cluster systému X.
• Konfigurace pro produkční cluster systému X.

9. Šablony a přepisování konfigurací

Administrátor může přepsat sadu zděděných konfigurací a jejich hodnot, například, aby jemněji vyladil konfiguraci pro určité clustery, na které budou aplikovány.

10. Vybrané zahrnutí a vyloučení konfigurací, konfigurace aplikací

Administrátor může nastavit podmínky pro aplikaci nebo nepoužití konkrétních konfigurací na clustery s určitými charakteristikami.

11. Podpora šablon

Vývojářům se hodí možnost vybrat, jak budou definovány zdroje aplikace (Helm Chart, čistý Kubernetes yaml atd.), aby bylo možné používat nejvhodnější formát pro každou konkrétní aplikaci.

Nástroje GitOps na platformě OpenShift

ArgoCD

ArgoCD implementuje model External Resource Reconcile a nabízí centralizované uživatelské rozhraní pro orchestraci vztahů mezi clustery a Git repozitáři podle schématu „jeden k mnoha“. Mezi nedostatky tohoto programu patří nemožnost spravovat aplikace při nefunkčním ArgoCD.

Oficiální web

Flux

Flux implementuje model On-Cluster Resource Reconcile, a proto zde neexistuje centralizované řízení repozitáře definic, což je slabé místo. Na druhou stranu, právě kvůli absenci centralizace zůstává možnost správy aplikací i při selhání jednoho clusteru.

Oficiální web

Instalace ArgoCD na OpenShift

ArgoCD nabízí vynikající příkazový řádek a webovou konzolu, proto se zde nebudeme zabývat Flux a dalšími alternativami.

Chcete-li nasadit ArgoCD na platformě OpenShift 4, proveďte následující kroky jako správce clusteru:

Nasazení komponent ArgoCD na platformě 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 Serveru, aby byl viditelný 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

Nasazení nástroje 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

Změna administrátorského hesla ArgoCD Serveru

# 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 provedení těchto kroků lze s ArgoCD Serverem pracovat prostřednictvím webové konzoly ArgoCD WebUI nebo nástroje příkazového řádku ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – nikdy není pozdě

‚Vlak odjel‘ – tak se říká o situaci, kdy byla příležitost něco udělat promeškána. V případě OpenShiftu často touha ihned začít využívat tuto novou skvělou platformu vytváří právě tuto situaci s řízením a údržbou routingů, deploymentů a dalších objektů OpenShift. Ale je vždy šance definitivně promeškána?

Pokračujeme v sérii článků o GitOps, dnes ukážeme, jak převést ručně vytvořenou aplikaci a její zdroje do jakéhosi procesu, kde všemu vládne nástroj GitOps. Nejprve ručně nasadíme aplikaci httpd. Na obrázku níže je znázorněno, jak vytváříme prostor názvů, deployment a službu, a poté odhalujeme tuto službu, abychom vytvořili 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čně vytvořenou aplikaci. Nyní ji musíme převést pod řízení GitOps bez ztráty dostupnosti. Stručně řečeno, dělá to takto:

• Vytváříme Git repozitář pro kód.
• Exportujeme naše aktuální objekty a nahráváme je do repozitáře Git.
• Vybereme a nasadíme nástroj GitOps.
• Přidáme do tohoto nástroje náš repozitář.
• Definujeme aplikaci v našem nástroji GitOps.
• Provedeme zkušební spuštění aplikace pomocí nástroje GitOps.
• Synchronizujeme objekty pomocí nástroje GitOps.
• Povolíme čištění (pruning) a automatickou synchronizaci objektů.

Jak již bylo zmíněno v předchozí článku, v GitOps existuje pouze jeden zdroj informací o všech objektech v klastrech Kubernetes – repozitář Git. Dále vycházíme z předpokladu, že ve vaší organizaci již používáte Git-repozitář. Může být veřejný nebo soukromý, ale musí být dostupný pro Kubernetes clustery. Může to být ten samý repozitář, který používáte pro kód aplikací, nebo samostatný repozitář vytvořený speciálně pro nasazení. V repozitáři se doporučuje mít přísná oprávnění, protože tam budou uloženy objekty secret, trasy a další citlivé informace.

V našem příkladu vytvoříme nový veřejný repozitář na GitHubu. Můžete ho nazvat jakkoliv, my používáme název blogpost.

Pokud YAML soubory objektů nebyly uloženy lokálně nebo v Gitu, musíte použít binární soubory oc nebo kubectl. Na obrázku níže žádáme o YAML pro naše jmenné prostory, nasazení, služby a trasy. Předtím jsme zkopírovali právě vytvořený repozitář a přešli do něj pomocí příkazu 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

Teď upravíme soubor deployment.yaml, abychom odstranili pole, které Argo CD nemůže synchronizovat.

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

Kromě toho je třeba změnit trasu. Nejdříve nastavíme vícerozměrnou proměnnou, a poté nahradíme ingress: null obsahem této proměnné.

export ROUTE=" ingress:                                                            
    - podmínky:
        - stav: 'True'
          typ: Admitted"

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

Takže, co se týče souborů, vyřešili jsme to, nyní je třeba je uložit do Git-repozitáře. Po tom se tento repozitář stává jediným zdrojem informací a jakékoli ruční změny objektů by měly být přísně zakázány.

git commit -am 'počáteční závazek objektů'
git push origin master

Dále vycházíme z toho, že ArgoCD již máte nasazené (jak to udělat – viz předchozí příspěvek). Proto přidáme do Argo CD náš vytvořený repozitář, obsahující kód aplikace z našeho příkladu. Jen se ujistěte, že uvádíte právě ten repozitář, který jste vytvořili dříve.

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

Nyní vytvoříme aplikaci. Aplikace určuje hodnoty, aby nástroje GitOps věděly, který repozitář a cesty používat, jaký OpenShift je potřeba pro správu objektů, a také která konkrétní větev repozitáře je potřebná a zda by měla probíhat automatická synchronizace zdrojů.

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

Poté, co je aplikace nastavena v Argo CD, tento nástroj začíná kontrolovat již nasazené objekty na shodu s definicemi v repozitáři. V našem příkladu je automatická synchronizace a úklid zakázána, takže prvky se prozatím nemění. Všimněte si, že v rozhraní Argo CD bude mít naše aplikace stav „Out of Sync“ (Není synchronizováno), protože neexistuje label, který označuje ArgoCD.
Proto, když později zahájíme synchronizaci, nedojde k opětovnému nasazení objektů.

Nyní provedeme zkušební spuštění, abychom se ujistili, že v našich souborech nejsou žádné chyby.

argocd app sync simple-app --dry-run

Pokud nejsou žádné chyby, můžeme přistoupit k synchronizaci.

argocd app sync simple-app

Po provedení příkazu argocd get nad naší aplikací bychom měli vidět, že stav aplikace se změnil na Healthy (Zdravý) nebo Synced (Synchronizováno). To znamená, že všechny zdroje v Git repozitáři nyní odpovídají těm zdrojům, které již byly nasazeny.

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 teď můžeme aktivovat automatickou synchronizaci a úklid, abychom zajistili, že nebude nic vytvářeno ručně a že pokaždé, když je objekt vytvořen nebo aktualizován v repozitáři, dojde k nasazení.

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

Tak, úspěšně jsme převedli aplikaci do správy GitOps, která původně GitOps vůbec nevyužívala.

Zdroj: habr.com