Dnes si povíme o principech a modelech GitOps a také o tom, jak jsou tyto modely implementovány na platformě OpenShift. K tomuto tématu je k dispozici interaktivní průvodce .
Stručně řečeno, GitOps je sada postupů pro používání požadavků Git Pull ke správě konfigurace infrastruktury a aplikací. S úložištěm Git v GitOps se zachází jako s jediným zdrojem informací o stavu systému a jakékoli změny tohoto stavu jsou plně sledovatelné a auditovatelné.
Myšlenka sledování změn v GitOps není v žádném případě nová, tento přístup se již dlouho používá téměř univerzálně při práci se zdrojovým kódem aplikace. GitOps jednoduše implementuje podobné funkce (recenze, pull requesty, značky atd.) do správy konfigurace infrastruktury a aplikací a poskytuje podobné výhody jako v případě správy zdrojového kódu.
Neexistuje žádná akademická definice ani schválený soubor pravidel pro GitOps, pouze soubor principů, na kterých je tato praxe postavena:
- Deklarativní popis systému je uložen v úložišti Git (konfigurace, monitorování atd.).
- Změny stavu se provádějí prostřednictvím žádostí o stažení.
- Stav běžících systémů je uveden do souladu s daty v úložišti pomocí Git push requestů.
Principy GitOps
- Definice systému jsou popsány jako zdrojový kód
Konfigurace systému je považována za kód, takže může být uložena a automaticky verzována v úložišti Git, které slouží jako jediný zdroj pravdy. Tento přístup usnadňuje zavedení a vrácení změn v systémech.
- Požadovaný stav a konfigurace systémů jsou nastaveny a verzovány v Gitu
Díky ukládání a verzování požadovaného stavu systémů v Gitu jsme schopni snadno zavádět a vracet změny do systémů a aplikací. Můžeme také použít bezpečnostní mechanismy Git ke kontrole vlastnictví kódu a ověření jeho pravosti.
- Změny konfigurace mohou být automaticky aplikovány prostřednictvím požadavků na vyžádání
Pomocí požadavků Git pull můžeme snadno ovládat, jak se změny aplikují na konfigurace v úložišti. Mohou být například poskytnuty ostatním členům týmu ke kontrole nebo k provedení testů CI atd.
A zároveň není potřeba rozdělovat administrátorské pravomoci nalevo a napravo. K potvrzení změn konfigurace potřebují uživatelé pouze příslušná oprávnění v úložišti Git, kde jsou tyto konfigurace uloženy.
- Oprava problému s nekontrolovaným posunem konfigurací
Jakmile je požadovaný stav systému uložen v úložišti Git, zbývá nám pouze najít software, který zajistí, aby aktuální stav systému odpovídal jeho požadovanému stavu. Pokud tomu tak není, pak by měl tento software - v závislosti na nastavení - buď odstranit nesrovnalost sám, nebo nás upozornit na posun konfigurace.
Modely GitOps pro OpenShift
On-Cluster Resource Reconciler
Podle tohoto modelu má cluster řadič, který je zodpovědný za porovnávání prostředků Kubernetes (soubory YAML) v úložišti Git se skutečnými prostředky clusteru. Pokud jsou zjištěny nesrovnalosti, ovladač odešle upozornění a případně podnikne kroky k nápravě nesrovnalostí. Tento model GitOps se používá v Anthos Config Management a Weaveworks Flux.
Externí usměrňovač zdrojů (Push)
Tento model lze považovat za variaci předchozího, kdy máme jeden nebo více řadičů odpovědných za synchronizaci zdrojů ve dvojicích „Git repository - Kubernetes cluster“. Rozdíl je v tom, že každý spravovaný cluster nemusí mít nutně svůj samostatný řadič. Páry klastrů Git - k8s jsou často definovány jako CRD (vlastní definice prostředků), které mohou popisovat, jak by měl řadič provádět synchronizaci. V rámci tohoto modelu kontroloři porovnávají úložiště Git uvedené v CRD s prostředky clusteru Kubernetes, které jsou také specifikovány v CRD, a na základě výsledků porovnání provádějí příslušné akce. Konkrétně tento model GitOps se používá v ArgoCD.
GitOps na platformě OpenShift
Správa multiklastrové infrastruktury Kubernetes
S rozšířením Kubernetes a rostoucí oblibou multicloudových strategií a edge computingu se také zvyšuje průměrný počet clusterů OpenShift na zákazníka.
Například při použití edge computingu lze clustery jednoho zákazníka nasadit ve stovkách nebo dokonce tisících. V důsledku toho je nucen spravovat několik nezávislých nebo koordinovaných clusterů OpenShift ve veřejném cloudu a on-premise.
V tomto případě je třeba vyřešit mnoho problémů, zejména:
- Kontrola, zda jsou clustery v identickém stavu (konfigurace, monitorování, úložiště atd.)
- Znovu vytvořte (nebo obnovte) clustery na základě známého stavu.
- Vytvořte nové clustery na základě známého stavu.
- Zaveďte změny do více clusterů OpenShift.
- Vrácení změn ve více clusterech OpenShift.
- Propojte konfigurace podle šablony s různými prostředími.
Konfigurace aplikací
Během svého životního cyklu aplikace často procházejí řetězcem clusterů (dev, stage atd.), než skončí v produkčním clusteru. Navíc kvůli požadavkům na dostupnost a škálovatelnost zákazníci často nasazují aplikace do více on-premise clusterů nebo více oblastí veřejné cloudové platformy.
V tomto případě je třeba vyřešit následující úkoly:
- Zajištění pohybu aplikací (binární soubory, konfigurace atd.) mezi clustery (dev, stage atd.).
- Zaveďte změny aplikací (binární soubory, konfigurace atd.) v několika clusterech OpenShift.
- Vrátit změny v aplikacích do předchozího známého stavu.
Případy použití OpenShift GitOps
1. Použití změn z úložiště Git
Administrátor clusteru může ukládat konfigurace clusteru OpenShift v úložišti Git a automaticky je použít pro snadné vytváření nových clusterů a jejich uvedení do stavu identického se známým stavem uloženým v úložišti Git.
2. Synchronizace s Secret Manager
Správce bude také těžit ze možnosti synchronizovat tajné objekty OpenShift s vhodným softwarem, jako je Vault, aby je mohl spravovat pomocí nástrojů speciálně vytvořených pro tento účel.
3. Řízení driftových konfigurací
Administrátor bude pro, pouze pokud OpenShift GitOps sám identifikuje a varuje před nesrovnalostmi mezi skutečnými konfiguracemi a konfiguracemi uvedenými v úložišti, aby mohl rychle reagovat na drift.
4. Upozornění na posun konfigurace
Jsou užitečné v případě, kdy se chce administrátor rychle dozvědět o případech posunu konfigurace, aby mohl sám rychle přijmout vhodná opatření.
5. Ruční synchronizace konfigurací při driftování
Umožňuje správci synchronizovat cluster OpenShift s úložištěm Git v případě posunu konfigurace, aby se cluster rychle vrátil do předchozího známého stavu.
6.Automatická synchronizace konfigurací při driftování
Administrátor může také nakonfigurovat cluster OpenShift tak, aby se automaticky synchronizoval s úložištěm, když je zjištěn posun, takže konfigurace clusteru vždy odpovídá konfiguracím v Gitu.
7. Několik clusterů – jedno úložiště
Správce může uložit konfigurace několika různých clusterů OpenShift do jednoho úložiště Git a selektivně je použít podle potřeby.
8. Hierarchie konfigurací clusteru (dědičnost)
Správce může nastavit hierarchii konfigurací clusteru v úložišti (stage, produkt, portfolio aplikací atd. s dědičností). Jinými slovy, může určit, zda mají být konfigurace aplikovány na jeden nebo více clusterů.
Pokud například administrátor nastaví hierarchii „Produkční clustery (prod) → Klastry systému X → Produkční clustery systému X“ v úložišti Git, pak se na produkční clustery systému X použije kombinace následujících konfigurací:
- Konfigurace společné pro všechny produkční clustery.
- Konfigurace pro cluster System X.
- Konfigurace pro produkční cluster systému X.
9. Šablony a přepsání konfigurace
Administrátor může přepsat sadu zděděných konfigurací a jejich hodnot, například za účelem doladění konfigurace pro konkrétní clustery, na které budou použity.
10. Selektivní zahrnutí a vyloučení pro konfigurace, konfigurace aplikací
Administrátor může nastavit podmínky pro aplikaci či neaplikaci určitých konfigurací na clustery s určitými vlastnostmi.
11. Podpora šablon
Vývojáři budou těžit z možnosti vybrat si, jak budou definovány prostředky aplikace (Helm Chart, čistý Kubernetes yaml atd.), aby pro každou konkrétní aplikaci použili nejvhodnější formát.
Nástroje GitOps na platformě OpenShift
ArgoCD
ArgoCD implementuje model External Resource Reconcile a nabízí centralizované uživatelské rozhraní pro orchestraci vztahů one-to-many mezi clustery a repozitáři Git. Mezi nevýhody tohoto programu patří nemožnost spravovat aplikace, když ArgoCD nefunguje.
Proudění
Flux implementuje model On-Cluster Resource Reconcile a v důsledku toho neexistuje žádná centralizovaná správa úložiště definic, což je slabá stránka. Na druhou stranu právě kvůli chybějící centralizaci zůstává možnost spravovat aplikace i při výpadku jednoho clusteru.
Instalace ArgoCD na OpenShift
ArgoCD nabízí vynikající rozhraní příkazového řádku a webovou konzoli, takže se zde nebudeme zabývat Fluxem a dalšími alternativami.
Chcete-li nasadit ArgoCD na platformě OpenShift 4, postupujte jako správce clusteru takto:
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}')Vylepšení ArgoCD Serveru tak, aby jej bylo možné vidět pomocí 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=RedirectNasazení 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/argocdZměna hesla správce serveru 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 kroků můžete pracovat se serverem ArgoCD prostřednictvím webové konzole ArgoCD WebUI nebo nástroje příkazového řádku ArgoCD Cli.
GitOps – Nikdy není pozdě
„Vlak odjel“ - to se říká o situaci, kdy je příležitost něco udělat. V případě OpenShift touha okamžitě začít používat tuto skvělou novou platformu často vytváří přesně tuto situaci se správou a údržbou tras, nasazení a dalších objektů OpenShift. Je ale šance vždy zcela ztracena?
Pokračování série článků o , dnes vám ukážeme, jak přeměnit ručně vyrobenou aplikaci a její prostředky na proces, kde je vše spravováno nástroji GitOps. K tomu nejprve ručně nasadíme aplikaci httpd. Snímek obrazovky níže ukazuje, jak vytváříme obor názvů, nasazení a službu a poté tuto službu vystavíme k vytvoření 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-appTakže máme ručně vytvořenou aplikaci. Nyní je třeba jej převést pod správu GitOps bez ztráty dostupnosti. Ve zkratce to dělá toto:
- Vytvořte úložiště Git pro kód.
- Exportujeme naše aktuální objekty a nahrajeme je do úložiště Git.
- Výběr a nasazení nástrojů GitOps.
- Do této sady nástrojů přidáváme naše úložiště.
- Aplikaci definujeme v naší sadě nástrojů GitOps.
- Provádíme testovací provoz aplikace pomocí sady nástrojů GitOps.
- Objekty synchronizujeme pomocí sady nástrojů GitOps.
- Povolit ořezávání a automatickou synchronizaci objektů.
Jak již bylo zmíněno v předchozím , v GitOps existuje jeden a jediný zdroj informací o všech objektech v clusteru (klastrech) Kubernetes - úložiště Git. Dále vycházíme z předpokladu, že vaše organizace již používá úložiště Git. Může být veřejný nebo soukromý, ale musí být přístupný pro clustery Kubernetes. Může se jednat o stejné úložiště jako pro kód aplikace nebo o samostatné úložiště vytvořené speciálně pro nasazení. Doporučuje se mít přísná oprávnění v úložišti, protože tam budou uložena tajemství, cesty a další věci citlivé na zabezpečení.
V našem příkladu vytvoříme nové veřejné úložiště na GitHubu. Můžete tomu říkat, jak chcete, my používáme název blogpost.
Pokud soubory objektů YAML nebyly uloženy lokálně nebo v Gitu, budete muset použít binární soubory oc nebo kubectl. Na níže uvedeném snímku obrazovky požadujeme YAML pro náš jmenný prostor, nasazení, službu a trasu. Předtím jsme naklonovali nově vytvořené úložiště a cd do něj.
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.yamlNyní upravme soubor deployment.yaml, abychom odstranili pole, které Argo CD nemůže synchronizovat.
sed -i '/sgeneration: .*/d' deployment.yamlNavíc je potřeba změnit trasu. Nejprve nastavíme víceřádkovou proměnnou a poté nahradíme ingress: null obsahem této proměnné.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlSoubory jsme tedy vytřídili, zbývá je pouze uložit do úložiště Git. Poté se toto úložiště stane 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 ‘initial commit of objects’
git push origin masterDále vycházíme ze skutečnosti, že jste již nasadili ArgoCD (jak to udělat - viz předchozí ). Na Argo CD proto přidáme námi vytvořený repozitář obsahující kód aplikace z našeho příkladu. Jen se ujistěte, že jste zadali přesné úložiště, které jste vytvořili dříve.
argocd repo add https://github.com/cooktheryan/blogpostNyní vytvoříme aplikaci. Aplikace nastavuje hodnoty tak, aby sada nástrojů GitOps chápala, které úložiště a cesty použít, který OpenShift je potřeba ke správě objektů, která konkrétní větev úložiště je potřeba a zda se mají prostředky automaticky synchronizovat.
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
Jakmile je aplikace specifikována na disku Argo CD, sada nástrojů začne kontrolovat již nasazené objekty podle definic v úložišti. V našem příkladu je automatická synchronizace a čištění zakázáno, takže prvky se zatím nemění. Vezměte prosím na vědomí, že v rozhraní Argo CD bude mít naše aplikace stav „Out of Sync“, protože neexistuje žádný štítek, který by ArgoCD poskytoval.
To je důvod, proč když spustíme synchronizaci o něco později, objekty nebudou znovu rozmístěny.
Nyní proveďte zkušební provoz, abychom se ujistili, že v našich souborech nejsou žádné chyby.
argocd app sync simple-app --dry-runPokud nejsou žádné chyby, můžete přistoupit k synchronizaci.
argocd app sync simple-appPo spuštění příkazu argocd get v naší aplikaci bychom měli vidět, že se stav aplikace změnil na Healthy nebo Synced. To bude znamenat, že všechny prostředky v úložišti Git nyní odpovídají těm prostředků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: <none>
Sync Status: Synced to master (60e1678)
Health Status: Healthy
... Nyní můžete povolit automatickou synchronizaci a čištění, abyste zajistili, že se nic nevytvoří ručně a že pokaždé, když je objekt vytvořen nebo aktualizován do úložiště, dojde k nasazení.
argocd app set simple-app --sync-policy automated --auto-prune
Úspěšně jsme tedy dostali pod kontrolu GitOps aplikaci, která původně GitOps nijak nevyužívala.
Zdroj: www.habr.com