„OpenShift“ skirtos „GitOps“ įvadas

Šiandien kalbėsime apie GitOps principus ir modelius bei apie tai, kaip šie modeliai diegiami OpenShift platformoje. Yra interaktyvus vadovas šia tema по ссылке.

Trumpai tariant, „GitOps“ yra „Git pull“ užklausų naudojimo infrastruktūros ir programų konfigūracijoms tvarkyti praktikos rinkinys. „Git“ saugykla „GitOps“ yra traktuojama kaip vienas informacijos apie sistemos būseną šaltinis, o bet kokie šios būsenos pakeitimai yra visiškai atsekami ir tikrinami.

„GitOps“ pokyčių stebėjimo idėja jokiu būdu nėra nauja; šis metodas jau seniai naudojamas beveik visuotinai dirbant su programos šaltinio kodu. „GitOps“ tiesiog įdiegia panašias funkcijas (apžvalgas, ištraukimo užklausas, žymas ir kt.) infrastruktūros ir programų konfigūracijos valdyme ir suteikia panašią naudą kaip ir šaltinio kodo valdymo atveju.

Nėra akademinio apibrėžimo ar patvirtintų „GitOps“ taisyklių rinkinio, o tik principų rinkinys, kuriuo grindžiama ši praktika:

• Deklaratyvus sistemos aprašymas yra saugomas Git saugykloje (konfigūracijos, stebėjimas ir kt.).
• Būsenos pakeitimai atliekami naudojant ištraukimo užklausas.
• Veikiančių sistemų būsena suderinama su saugykloje esančiais duomenimis naudojant „Git push“ užklausas.

GitOps principai

• Sistemos apibrėžimai aprašomi kaip šaltinio kodas

Sistemos konfigūracija traktuojama kaip kodas, todėl ją galima saugoti ir automatiškai kurti versijas Git saugykloje, kuri yra vienas tiesos šaltinis. Šis metodas leidžia lengvai įdiegti ir atšaukti pakeitimus sistemose.

• Norima sistemų būsena ir konfigūracija yra nustatomos ir versijos Git

Išsaugodami ir sukūrę pageidaujamą sistemų būseną „Git“, galime lengvai įdiegti ir atšaukti sistemų ir programų pakeitimus. Taip pat galime naudoti „Git“ saugos mechanizmus, norėdami kontroliuoti kodo nuosavybę ir patikrinti jo autentiškumą.

• Konfigūracijos pakeitimai gali būti automatiškai taikomi naudojant ištraukimo užklausas

Naudodami „Git“ ištraukimo užklausas galime lengvai valdyti, kaip pakeitimai taikomi konfigūracijoms saugykloje. Pavyzdžiui, jie gali būti pateikti kitiems komandos nariams peržiūrėti arba atlikti CI testus ir pan.

Ir tuo pačiu metu nereikia paskirstyti administratoriaus galių į kairę ir į dešinę. Norint atlikti konfigūracijos pakeitimus, vartotojams tereikia atitinkamų leidimų „Git“ saugykloje, kurioje saugomos tos konfigūracijos.

• Nekontroliuojamo konfigūracijų dreifo problemos sprendimas

Kai norima sistemos būsena yra saugoma Git saugykloje, mums belieka rasti programinę įrangą, kuri užtikrins, kad esama sistemos būsena atitiktų jos norimą būseną. Jei taip nėra, ši programinė įranga turėtų, priklausomai nuo nustatymų, arba pati pašalinti neatitikimą, arba pranešti mums apie konfigūracijos nukrypimą.

„GitOps“ modeliai, skirti „OpenShift“.

Grupės išteklių suderinimo priemonė

Pagal šį modelį klasteris turi valdiklį, kuris yra atsakingas už Kubernetes išteklių (YAML failų) palyginimą Git saugykloje su tikrais klasterio ištekliais. Jei aptinkami neatitikimai, valdiklis siunčia pranešimus ir galbūt imasi veiksmų neatitikimams ištaisyti. Šis „GitOps“ modelis naudojamas „Anthos Config Management“ ir „Weaveworks Flux“.

Išorinių išteklių suderinimo priemonė (push)

Šį modelį galima laikyti ankstesnio variantu, kai porose „Git saugykla – Kubernetes klasteris“ turime vieną ar daugiau valdiklių, atsakingų už išteklių sinchronizavimą. Skirtumas yra tas, kad kiekvienas valdomas klasteris nebūtinai turi savo atskirą valdiklį. Git – k8s klasterių poros dažnai apibrėžiamos kaip CRD (pasirinktiniai išteklių apibrėžimai), kurie gali apibūdinti, kaip valdiklis turi atlikti sinchronizavimą. Šiame modelyje valdikliai lygina CRD nurodytą Git saugyklą su Kubernetes klasterio ištekliais, kurie taip pat nurodyti CRD, ir pagal palyginimo rezultatus atlieka atitinkamus veiksmus. Visų pirma, šis GitOps modelis naudojamas ArgoCD.

„GitOps“ „OpenShift“ platformoje

Kelių klasterių Kubernetes infrastruktūros administravimas

Plintant Kubernetes ir augant kelių debesų strategijų ir kraštinių skaičiavimų populiarumui, vidutinis OpenShift klasterių skaičius vienam klientui taip pat didėja.

Pavyzdžiui, naudojant krašto skaičiavimą, vieno kliento klasterių gali būti įdiegta šimtai ar net tūkstančiai. Dėl to jis yra priverstas valdyti keletą nepriklausomų arba koordinuotų „OpenShift“ grupių viešajame debesyje ir vietoje.

Šiuo atveju reikia išspręsti daugybę problemų, visų pirma:

• Valdykite, ar klasteriai yra identiškos būsenos (konfigūracijos, stebėjimas, saugykla ir kt.)
• Atkurkite (arba atkurkite) grupes pagal žinomą būseną.
• Sukurkite naujas grupes pagal žinomą būseną.
• Išskleiskite kelių „OpenShift“ grupių pakeitimus.
• Atšaukti pakeitimus keliose OpenShift grupėse.
• Susiekite šablonines konfigūracijas su skirtingomis aplinkomis.

Programos konfigūracijos

Per savo gyvavimo ciklą programos dažnai pereina per klasterių grandinę (kurėjas, stadija ir t. t.), kol patenka į gamybos klasterį. Be to, dėl pasiekiamumo ir mastelio reikalavimų klientai dažnai diegia programas keliose vietinėse grupėse arba keliuose viešosios debesies platformos regionuose.

Tokiu atveju reikia išspręsti šias užduotis:

• Užtikrinti programų (dvejetainių, konfigūracijų ir kt.) judėjimą tarp grupių (kur, scenos ir kt.).
• Išskleiskite programų (dvejetainių, konfigūracijų ir kt.) pakeitimus keliose „OpenShift“ grupėse.
• Grąžinkite programų pakeitimus į ankstesnę žinomą būseną.

OpenShift GitOps naudojimo atvejai

1. Pakeitimų taikymas iš Git saugyklos

Klasterio administratorius gali saugoti „OpenShift“ klasterio konfigūracijas „Git“ saugykloje ir automatiškai jas pritaikyti, kad be vargo sukurtų naujus grupes ir įvestų į būseną, identišką žinomai „Git“ saugykloje saugomai būsenai.

2. Sinchronizavimas su Secret Manager

Administratoriui taip pat bus naudinga galimybė sinchronizuoti „OpenShift“ slaptus objektus su atitinkama programine įranga, tokia kaip „Vault“, kad galėtų juos valdyti naudojant specialiai tam sukurtus įrankius.

3. Dreifo konfigūracijų valdymas

Administratorius bus palankus tik tuo atveju, jei „OpenShift GitOps“ pati atpažins ir įspės apie realių ir saugykloje nurodytų konfigūracijų neatitikimus, kad galėtų greitai reaguoti į dreifą.

4. Pranešimai apie konfigūracijos poslinkį

Jie naudingi tuo atveju, kai administratorius nori greitai sužinoti apie konfigūracijos dreifo atvejus, kad pats galėtų greitai imtis atitinkamų priemonių.

5. Rankinis konfigūracijų sinchronizavimas dreifuojant

Leidžiama administratoriui sinchronizuoti OpenShift klasterį su Git saugykla konfigūracijos nukrypimo atveju, kad būtų greitai grąžinta klasterio ankstesnė žinoma būsena.

6.Automatinis konfigūracijų sinchronizavimas dreifuojant

Administratorius taip pat gali sukonfigūruoti OpenShift klasterį, kad jis automatiškai sinchronizuotųsi su saugykla, kai aptinkamas poslinkis, kad klasterio konfigūracija visada atitiktų Git konfigūracijas.

7. Keli klasteriai – viena saugykla

Administratorius gali saugoti kelių skirtingų „OpenShift“ grupių konfigūracijas vienoje „Git“ saugykloje ir pasirinktinai jas taikyti pagal poreikį.

8. Klasterių konfigūracijų hierarchija (paveldėjimas)

Administratorius saugykloje gali nustatyti klasterio konfigūracijų hierarchiją (etapas, gaminys, programos portfelis ir kt. su paveldėjimu). Kitaip tariant, jis gali nustatyti, ar konfigūracijos turėtų būti taikomos vienai ar daugiau grupių.

Pavyzdžiui, jei administratorius Git saugykloje nustato hierarchiją „Gamybos klasteriai (gamyba) → Sistemos X klasteriai → X sistemos gamybos klasteriai“, tada X sistemos gamybos klasteriams taikomas šių konfigūracijų derinys:

• Konfigūracijos, bendros visoms gamybos grupėms.
• Sistemos X klasterio konfigūracijos.
• X sistemos gamybos klasterio konfigūracijos.

9. Šablonų ir konfigūracijos nepaisymas

Administratorius gali nepaisyti paveldėtų konfigūracijų ir jų reikšmių rinkinio, pavyzdžiui, norėdamas tiksliai sureguliuoti konkrečių grupių, kurioms jos bus taikomos, konfigūraciją.

10. Atrankinis įtraukimas ir neįtraukimas konfigūracijų, taikomųjų programų konfigūracijoms

Administratorius gali nustatyti tam tikrų konfigūracijų taikymo arba netaikymo sąlygas tam tikrų savybių klasteriams.

11. Šablonų palaikymas

Kūrėjai turės naudos iš galimybės pasirinkti, kaip bus apibrėžiami programos ištekliai (Helm diagrama, grynas Kubernetes yaml ir kt.), kad kiekvienai konkrečiai programai būtų naudojamas tinkamiausias formatas.

„GitOps“ įrankiai „OpenShift“ platformoje

ArgoCD

„ArgoCD“ įgyvendina išorinių išteklių suderinimo modelį ir siūlo centralizuotą vartotojo sąsają, skirtą „vienas su daugeliu“ ryšiams tarp grupių ir „Git“ saugyklų organizuoti. Šios programos trūkumai yra nesugebėjimas valdyti programų, kai ArgoCD neveikia.

Oficiali svetainė

Fliusas

„Flux“ įgyvendina „On-Cluster Resource Concile“ modelį, todėl nėra centralizuoto apibrėžimų saugyklos valdymo, o tai yra silpnoji vieta. Kita vertus, būtent dėl ​​centralizacijos stokos, galimybė valdyti programas išlieka net ir vienam klasteriui sugedus.

Oficiali svetainė

„ArgoCD“ diegimas „OpenShift“.

ArgoCD siūlo puikią komandų eilutės sąsają ir žiniatinklio konsolę, todėl čia neapžvelgsime Flux ir kitų alternatyvų.

Norėdami įdiegti „ArgoCD“ „OpenShift 4“ platformoje, atlikite šiuos veiksmus kaip klasterio administratorius:

ArgoCD komponentų diegimas OpenShift platformoje

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

ArgoCD serverio patobulinimas, kad jį būtų galima matyti naudojant „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

„ArgoCD Cli“ įrankio diegimas

# 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

ArgoCD serverio administratoriaus slaptažodžio keitimas

# 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

Atlikę šiuos veiksmus, galite dirbti su „ArgoCD Server“ naudodami „ArgoCD WebUI“ žiniatinklio konsolę arba „ArgoCD Cli“ komandų eilutės įrankį.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – niekada nevėlu

„Traukinys išvažiavo“ - taip jie sako apie situaciją, kai praleidžiama galimybė ką nors padaryti. „OpenShift“ atveju noras nedelsiant pradėti naudoti šią šaunią naują platformą dažnai sukuria būtent tokią situaciją tvarkant ir prižiūrint maršrutus, diegimus ir kitus „OpenShift“ objektus. Bet ar visada galimybė visiškai prarasta?

Tęsiant straipsnių ciklą apie „GitOps“, šiandien parodysime, kaip rankomis sukurtą programą ir jos išteklius paversti procesu, kuriame viską valdo GitOps įrankiai. Norėdami tai padaryti, pirmiausia rankiniu būdu įdiegsime httpd programą. Toliau pateiktoje ekrano kopijoje parodyta, kaip sukuriame vardų erdvę, diegimą ir paslaugą, o tada atskleidžiame šią paslaugą, kad sukurtume maršrutą.

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

Taigi turime rankų darbo programą. Dabar jį reikia perkelti į „GitOps“ valdymą neprarandant pasiekiamumo. Trumpai tariant, tai daro taip:

• Sukurkite kodui skirtą Git saugyklą.
• Eksportuojame esamus objektus ir įkeliame juos į Git saugyklą.
• GitOps įrankių pasirinkimas ir diegimas.
• Prie šio įrankių rinkinio pridedame savo saugyklą.
• Programą apibrėžiame „GitOps“ įrankių rinkinyje.
• Atliekame bandomąjį programos paleidimą naudodami GitOps įrankių rinkinį.
• Sinchronizuojame objektus naudodami GitOps įrankių rinkinį.
• Įgalinti objektų genėjimą ir automatinį sinchronizavimą.

Kaip minėta ankstesniame straipsnis, GitOps yra vienas ir vienintelis informacijos šaltinis apie visus Kubernetes klasteryje (-iuose) esančius objektus – Git saugyklą. Toliau darome prielaidą, kad jūsų organizacija jau naudoja „Git“ saugyklą. Jis gali būti viešas arba privatus, bet turi būti pasiekiamas Kubernetes klasteriams. Tai gali būti ta pati saugykla kaip ir programos kodui, arba atskira saugykla, sukurta specialiai diegimams. Saugykloje rekomenduojama turėti griežtus leidimus, nes ten bus saugomos paslaptys, maršrutai ir kiti saugai jautrūs dalykai.

Mūsų pavyzdyje mes sukursime naują viešą saugyklą „GitHub“. Galite vadinti jį kaip norite, mes naudojame pavadinimą tinklaraščio įrašas.

Jei YAML objekto failai nebuvo saugomi vietoje arba Git, turėsite naudoti dvejetainius oc arba kubectl failus. Žemiau esančioje ekrano kopijoje prašome YAML mūsų vardų erdvės, diegimo, paslaugos ir maršruto. Prieš tai mes klonavome naujai sukurtą saugyklą ir kompaktinį diską į 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.yaml

Dabar redaguosime failą deployment.yaml, kad pašalintume lauką, kurio Argo CD negali sinchronizuoti.

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

Be to, reikia keisti maršrutą. Pirmiausia nustatysime kelių eilučių kintamąjį, o tada ingress: null pakeisime to kintamojo turiniu.

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

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

Taigi, mes sutvarkėme failus, belieka juos išsaugoti „Git“ saugykloje. Po to ši saugykla tampa vieninteliu informacijos šaltiniu, o bet kokie rankiniai objektų pakeitimai turėtų būti griežtai uždrausti.

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

Toliau mes remiamės tuo, kad jau įdiegėte ArgoCD (kaip tai padaryti - žr paštu). Todėl į Argo kompaktinį diską įtrauksime mūsų sukurtą saugyklą, kurioje yra programos kodas iš mūsų pavyzdžio. Tiesiog įsitikinkite, kad nurodėte tikslią saugyklą, kurią sukūrėte anksčiau.

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

Dabar sukurkime programą. Programa nustato reikšmes taip, kad „GitOps“ įrankių rinkinys suprastų, kurią saugyklą ir kelius naudoti, kuris „OpenShift“ reikalingas objektams valdyti, kuri konkreti saugyklos šaka reikalinga ir ar ištekliai turi būti sinchronizuojami automatiškai.

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

Kai programa nurodoma Argo kompaktiniame diske, įrankių rinkinys pradeda tikrinti jau įdiegtus objektus pagal saugykloje esančius apibrėžimus. Mūsų pavyzdyje automatinis sinchronizavimas ir valymas išjungti, todėl elementai dar nesikeičia. Atkreipkite dėmesį, kad Argo CD sąsajoje mūsų programa turės būseną „Out of Sync“, nes nėra „ArgoCD“ pateiktos etiketės.
Štai kodėl kai pradėsime sinchronizuoti šiek tiek vėliau, objektai nebus perskirstyti.

Dabar atlikime bandomąjį paleidimą, kad įsitikintume, jog failuose nėra klaidų.

argocd app sync simple-app --dry-run

Jei klaidų nėra, galite pereiti prie sinchronizavimo.

argocd app sync simple-app

Paleidę komandą argocd get mūsų programoje, turėtume pamatyti, kad programos būsena pasikeitė į Sveika arba Sinchronizuota. Tai reikš, kad visi Git saugyklos ištekliai dabar atitinka tuos išteklius, kurie jau buvo įdiegti.

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

Dabar galite įjungti automatinį sinchronizavimą ir valymą, kad užtikrintumėte, jog niekas nebūtų sukurtas rankiniu būdu ir kad kiekvieną kartą, kai objektas sukuriamas arba atnaujinamas į saugyklą, bus įdiegta.

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

Taigi, mes sėkmingai įdiegėme programą, kuri valdo „GitOps“, kuri iš pradžių niekaip nenaudojo „GitOps“.

Šaltinis: www.habr.com