🥇Uvod v GitOps za OpenShift

Danes bomo govorili o načelih in modelih GitOps, pa tudi o tem, kako so ti modeli implementirani na platformo OpenShift. Na voljo je interaktivni vodnik o tej temi по ссылке.

Na kratko, GitOps je niz praks za uporabo zahtev Git pull za upravljanje infrastrukture in konfiguracij aplikacij. Repozitorij Git v GitOps se obravnava kot en sam vir informacij o stanju sistema, vse spremembe tega stanja pa so v celoti sledljive in revizijske.

Zamisel o sledenju spremembam v GitOps nikakor ni nova; ta pristop se že dolgo uporablja skoraj univerzalno pri delu z izvorno kodo aplikacije. GitOps preprosto implementira podobne funkcije (pregledi, zahteve za vleko, oznake itd.) v upravljanju konfiguracije infrastrukture in aplikacij ter zagotavlja podobne prednosti kot v primeru upravljanja izvorne kode.

Za GitOps ni nobene akademske definicije ali odobrenega nabora pravil, le nabor načel, na katerih temelji ta praksa:

Deklarativni opis sistema je shranjen v repozitoriju Git (konfiguracije, nadzor itd.).
Spremembe stanja se izvajajo z zahtevami za vleko.
Stanje delujočih sistemov se uskladi s podatki v repozitoriju z uporabo potisnih zahtev Git.

Načela GitOps

Sistemske definicije so opisane kot izvorna koda

Sistemska konfiguracija se obravnava kot koda, tako da jo je mogoče shraniti in samodejno spreminjati v repozitorij Git, ki služi kot en sam vir resnice. Ta pristop olajša uvajanje in povrnitev sprememb v sistemih.

Želeno stanje in konfiguracija sistemov sta nastavljena in verzirana v Gitu

S shranjevanjem in urejanjem različic želenega stanja sistemov v Gitu lahko enostavno uvedemo in povrnemo spremembe v sistemih in aplikacijah. Za nadzor lastništva kode in preverjanje njene pristnosti lahko uporabimo tudi Gitove varnostne mehanizme.

Spremembe konfiguracije se lahko samodejno uporabijo prek zahtev za vleko

Z uporabo zahtev za vleko Git lahko enostavno nadzorujemo, kako se spremembe uporabljajo za konfiguracije v skladišču. Na primer, lahko jih daste drugim članom ekipe v pregled ali opravite teste CI itd.

In hkrati ni treba razdeljevati skrbniških pooblastil levo in desno. Za objavo sprememb konfiguracije potrebujejo uporabniki le ustrezna dovoljenja v repozitoriju Git, kjer so te konfiguracije shranjene.

Odpravljanje težave z nenadzorovanim premikanjem konfiguracij

Ko je želeno stanje sistema shranjeno v repozitoriju Git, moramo le poiskati programsko opremo, ki bo zagotovila, da se trenutno stanje sistema ujema z njegovim želenim stanjem. Če temu ni tako, bi morala ta programska oprema – odvisno od nastavitev – sama odpraviti neskladje ali pa nas obvestiti o zamiku konfiguracije.

GitOps modeli za OpenShift

Usklajevalnik virov v gruči

Po tem modelu ima gruča krmilnik, ki je odgovoren za primerjavo virov Kubernetes (datoteke YAML) v repozitoriju Git z dejanskimi viri gruče. Če so zaznana neskladja, upravljavec pošlje obvestilo in morebiti ukrepa za odpravo neskladij. Ta model GitOps se uporablja v Anthos Config Management in Weaveworks Flux.

Usklajevalnik zunanjih virov (potisni)

Ta model lahko obravnavamo kot variacijo prejšnjega, ko imamo enega ali več krmilnikov, odgovornih za sinhronizacijo virov v parih “Git repository - Kubernetes cluster”. Razlika je v tem, da vsaka upravljana gruča nima nujno svojega ločenega krmilnika. Pari gruč Git - k8s so pogosto definirani kot CRD (definicije virov po meri), ki lahko opišejo, kako naj krmilnik izvaja sinhronizacijo. Znotraj tega modela krmilniki primerjajo repozitorij Git, določen v CRD, z viri gruče Kubernetes, ki so prav tako navedeni v CRD, in izvedejo ustrezna dejanja na podlagi rezultatov primerjave. Zlasti ta model GitOps se uporablja v ArgoCD.

GitOps na platformi OpenShift

Upravljanje večgručne infrastrukture Kubernetes

S širjenjem Kubernetesa in naraščajočo priljubljenostjo strategij v več oblakih ter robnega računalništva se povečuje tudi povprečno število gruč OpenShift na stranko.

Na primer, pri uporabi robnega računalništva je mogoče gruče ene stranke namestiti na stotine ali celo tisoče. Posledično je prisiljen upravljati več neodvisnih ali usklajenih gruč OpenShift v javnem oblaku in na mestu uporabe.

V tem primeru je treba rešiti veliko težav, zlasti:

Nadzorujte, ali so gruče v enakem stanju (konfiguracije, nadzor, shranjevanje itd.)
Ponovno ustvarite (ali obnovite) gruče na podlagi znanega stanja.
Ustvarite nove gruče na podlagi znanega stanja.
Uvedite spremembe v več gruč OpenShift.
Razveljavite spremembe v več gručah OpenShift.
Povežite konfiguracije s predlogami z različnimi okolji.

Konfiguracije aplikacij

V svojem življenjskem ciklu gredo aplikacije pogosto skozi verigo gruč (dev, faza itd.), preden končajo v produkcijski gruči. Poleg tega stranke zaradi zahtev glede razpoložljivosti in razširljivosti pogosto nameščajo aplikacije v več lokalnih gruč ali več regij javne platforme v oblaku.

V tem primeru je treba rešiti naslednje naloge:

Zagotovite premikanje aplikacij (binarnih datotek, konfiguracij itd.) med gručami (dev, stage itd.).
Uvedite spremembe aplikacij (binarnih datotek, konfiguracij itd.) v več gručah OpenShift.
Povrnitev sprememb aplikacij na prejšnje znano stanje.

Primeri uporabe OpenShift GitOps

1. Uporaba sprememb iz repozitorija Git

Skrbnik gruče lahko shrani konfiguracije gruče OpenShift v repozitorij Git in jih samodejno uporabi za enostavno ustvarjanje novih gruč in jih spravi v stanje, ki je enako znanemu stanju, shranjenemu v repozitoriju Git.

2. Sinhronizacija s Secret Managerjem

Skrbniku bo koristila tudi možnost sinhronizacije skrivnih predmetov OpenShift z ustrezno programsko opremo, kot je Vault, da jih lahko upravlja z orodji, ki so posebej ustvarjena za to.

3. Nadzor konfiguracij zanašanja

Skrbnik bo podprl samo, če OpenShift GitOps sam prepozna in opozori na neskladja med dejanskimi konfiguracijami in tistimi, ki so navedene v skladišču, tako da se lahko hitro odzovejo na odmik.

4. Obvestila o premiku konfiguracije

Uporabni so v primeru, ko se želi skrbnik hitro seznaniti s primeri zamika konfiguracije, da lahko sam hitro sprejme ustrezne ukrepe.

5. Ročna sinhronizacija konfiguracij pri driftanju

Omogoča skrbniku, da sinhronizira gručo OpenShift z repozitorijem Git v primeru zamika konfiguracije, da hitro vrne gručo v prejšnje znano stanje.

6.Samodejna sinhronizacija konfiguracij pri driftanju

Skrbnik lahko tudi konfigurira gručo OpenShift za samodejno sinhronizacijo z repozitorijem, ko je zaznan premik, tako da se konfiguracija gruče vedno ujema s konfiguracijami v Gitu.

7. Več grozdov - en repozitorij

Skrbnik lahko shrani konfiguracije več različnih gruč OpenShift v enem repozitoriju Git in jih po potrebi selektivno uporabi.

8. Hierarhija konfiguracij gruče (dedovanje)

Skrbnik lahko nastavi hierarhijo konfiguracij gruče v repozitoriju (stopnja, izdelek, portfelj aplikacij itd. z dedovanjem). Z drugimi besedami, lahko določi, ali je treba konfiguracije uporabiti za eno ali več gruč.

Na primer, če skrbnik nastavi hierarhijo »Produkcijske gruče (prod) → Sistem X gruče → Proizvodne gruče sistema X« v repozitoriju Git, potem se za proizvodne gruče sistema X uporabi kombinacija naslednjih konfiguracij:

Konfiguracije, ki so skupne vsem proizvodnim grozdom.
Konfiguracije za gručo System X.
Konfiguracije za proizvodno gručo sistema X.

9. Predloge in preglasitve konfiguracije

Skrbnik lahko preglasi nabor podedovanih konfiguracij in njihovih vrednosti, da na primer natančno prilagodi konfiguracijo za določene gruče, za katere bodo uporabljene.

10. Selektivno vključi in izključi za konfiguracije, konfiguracije aplikacij

Skrbnik lahko nastavi pogoje za uporabo ali neuporabo določenih konfiguracij za gruče z določenimi lastnostmi.

11. Podpora za predloge

Razvijalcem bo koristila možnost, da izberejo, kako bodo definirani viri aplikacije (Helm Chart, čisti Kubernetes yaml itd.), da lahko uporabijo najprimernejši format za vsako posamezno aplikacijo.

Orodja GitOps na platformi OpenShift

ArgoCD

ArgoCD implementira model External Resource Reconcile in ponuja centraliziran uporabniški vmesnik za orkestriranje odnosov ena proti mnogo med gručami in repozitoriji Git. Slabosti tega programa vključujejo nezmožnost upravljanja aplikacij, ko ArgoCD ne deluje.

Uradna spletna stran

Flux

Flux implementira model On-Cluster Resource Reconcile in posledično ni centraliziranega upravljanja repozitorija definicij, kar je šibka točka. Po drugi strani pa prav zaradi pomanjkanja centralizacije ostane možnost upravljanja aplikacij tudi, če ena gruča odpove.

Uradna spletna stran

Namestitev ArgoCD na OpenShift

ArgoCD ponuja odličen vmesnik ukazne vrstice in spletno konzolo, zato tukaj ne bomo obravnavali Fluxa in drugih alternativ.

Za namestitev ArgoCD na platformo OpenShift 4 sledite tem korakom kot skrbnik gruče:

Namestitev komponent ArgoCD na platformi 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}')

Izboljšava strežnika ArgoCD, tako da ga je mogoče videti z 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

Namestitev orodja ArgoCD Cli

# 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

Spreminjanje skrbniškega gesla strežnika 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

Ko dokončate te korake, lahko delate s strežnikom ArgoCD prek spletne konzole ArgoCD WebUI ali orodja ukazne vrstice ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Nikoli ni prepozno

"Vlak je odšel" - tako pravijo o situaciji, ko je priložnost, da bi nekaj naredili, zamujena. V primeru OpenShift želja po takojšnjem začetku uporabe te kul nove platforme pogosto ustvari točno to situacijo z upravljanjem in vzdrževanjem poti, uvajanj in drugih objektov OpenShift. Toda ali je priložnost vedno popolnoma zamujena?

Nadaljevanje serije člankov o GitOps, vam bomo danes pokazali, kako ročno izdelano aplikacijo in njene vire spremeniti v proces, kjer vse upravljajo orodja GitOps. Da bi to naredili, bomo najprej ročno namestili aplikacijo httpd. Spodnji posnetek zaslona prikazuje, kako ustvarimo imenski prostor, uvedbo in storitev ter nato izpostavimo to storitev, da ustvarimo pot.

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

Imamo torej ročno izdelano aplikacijo. Zdaj ga je treba prenesti pod upravljanje GitOps brez izgube razpoložljivosti. Na kratko, naredi to:

Ustvarite repozitorij Git za kodo.
Izvozimo trenutne objekte in jih naložimo v repozitorij Git.
Izbira in namestitev orodij GitOps.
Temu kompletu orodij dodamo naš repozitorij.
Aplikacijo definiramo v našem kompletu orodij GitOps.
Izvedemo testni zagon aplikacije z orodjem GitOps.
Sinhroniziramo objekte z orodjem GitOps.
Omogoči obrezovanje in samodejno sinhronizacijo predmetov.

Kot omenjeno v prejšnjem članek, v GitOps obstaja en in samo en vir informacij o vseh objektih v gruči(-ah) Kubernetes – repozitorij Git. Nato izhajamo iz predpostavke, da vaša organizacija že uporablja repozitorij Git. Lahko je javna ali zasebna, vendar mora biti dostopna gručam Kubernetes. To je lahko isti repozitorij kot za kodo aplikacije ali ločen repozitorij, ustvarjen posebej za uvedbe. Priporočljivo je, da imate v repozitoriju stroga dovoljenja, saj bodo tam shranjene skrivnosti, poti in druge varnostno občutljive stvari.

V našem primeru bomo ustvarili novo javno skladišče na GitHubu. Lahko ga imenujete kakor koli želite, mi uporabljamo ime blogpost.

Če objektne datoteke YAML niso bile shranjene lokalno ali v Gitu, boste morali uporabiti binarne datoteke oc ali kubectl. Na spodnjem posnetku zaslona zahtevamo YAML za naš imenski prostor, uvajanje, storitev in pot. Pred tem smo vanj klonirali novo ustvarjeno skladišče in 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

Zdaj pa uredimo datoteko deployment.yaml, da odstranimo polje, ki ga Argo CD ne more sinhronizirati.

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

Poleg tega je treba spremeniti traso. Najprej bomo nastavili večvrstično spremenljivko in nato zamenjali ingress: null z vsebino te spremenljivke.

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

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

Datoteke smo torej razvrstili, ostalo je le še, da jih shranimo v repozitorij Git. Po tem postane ta repozitorij edini vir informacij, kakršne koli ročne spremembe objektov pa bi morale biti strogo prepovedane.

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

Nadalje izhajamo iz dejstva, da ste že namestili ArgoCD (kako to storiti - glejte prejšnji post). Zato bomo CD-ju Argo dodali repozitorij, ki smo ga ustvarili in vsebuje kodo aplikacije iz našega primera. Prepričajte se, da navedete natančen repozitorij, ki ste ga ustvarili prej.

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

Sedaj pa ustvarimo aplikacijo. Aplikacija nastavi vrednosti, tako da komplet orodij GitOps razume, kateri repozitorij in poti naj uporabi, kateri OpenShift je potreben za upravljanje predmetov, katera posebna veja repozitorija je potrebna in ali naj se viri samodejno sinhronizirajo.

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

Ko je aplikacija navedena na CD-ju Argo, komplet orodij začne preverjati že nameščene objekte glede na definicije v skladišču. V našem primeru sta samodejna sinhronizacija in čiščenje onemogočena, zato se elementi še ne spremenijo. Upoštevajte, da bo imela naša aplikacija v vmesniku Argo CD status »Out of Sync«, ker ArgoCD ne ponuja oznake.
Zato, ko začnemo sinhronizacijo malo kasneje, objekti ne bodo ponovno razporejeni.

Zdaj pa naredimo poskusni zagon, da se prepričamo, da v naših datotekah ni napak.

argocd app sync simple-app --dry-run

Če ni napak, lahko nadaljujete s sinhronizacijo.

argocd app sync simple-app

Po zagonu ukaza argocd get v naši aplikaciji bi morali videti, da se je status aplikacije spremenil v Zdravo ali Sinhronizirano. To bo pomenilo, da vsi viri v repozitoriju Git zdaj ustrezajo tistim virom, ki so že bili razporejeni.

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

Zdaj lahko omogočite samodejno sinhronizacijo in čiščenje, da zagotovite, da se nič ne ustvari ročno in da bo vsakič, ko je predmet ustvarjen ali posodobljen v repozitorij, prišlo do uvedbe.

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

Tako smo uspešno spravili aplikacijo pod nadzor GitOps, ki sprva na noben način ni uporabljala GitOps.

Vir: www.habr.com

Uvod v GitOps za OpenShift