Uvod u GitOps za OpenShift

Danas ćemo govoriti o principima i modelima GitOps, kao i kako se ti modeli implementiraju na OpenShift platformi. Interaktivni vodič na ovu temu je dostupan. na povezavi.

Ukratko, GitOps je skup praktičnih metoda za upravljanje konfiguracijama infrastrukture i aplikacija korištenjem Git pull zahteva. Git repozitorij u okviru GitOps-a se smatra jednim jedinstvenim izvorom informacija o stanju sistema, pri čemu su sve promene ovog stanja potpuno praćene i podložne reviziji.

Ideja o praćenju promena u GitOps-u nije nova, ovaj pristup se već dugo i gotovo svuda primenjuje pri radu sa izvornih kodom aplikacija. GitOps jednostavno implementira slične funkcije (revizijske provere, pull zahteve, oznake i sl.) kod upravljanja konfiguracijama infrastrukture i aplikacija i pruža slične prednosti kao pri upravljanju izvorim kodom.

Za GitOps ne postoji akademska definicija ili odobren skup pravila, samo niz načela na kojima se ova praksa zasniva:

• Deklarativni opis sistema se čuva u Git repozitoriju (konfiguracije, monitoring itd.).
• Promene stanja se vrše kroz pull zahteve.
• Stanje operativnih sistema se usaglašava sa podacima u repozitoriju pomoću push zahteva Git-a.

Principi GitOps-a

• Definicije sistema se opisuju kao izvorni kod

Konfiguracija sistema se smatra kodom, stoga se može čuvati i automatski verzionisati u Git repozitoriju, koji služi kao jedini izvor istine. Ovaj pristup omogućava lako primenu (rollout) i povlačenje (rollback) promena u sistemima.

• Željeno stanje i konfiguracija sistema se definišu i verzioniraju u Gitu

Čuvajući i verzionirajući željeno stanje sistema u Gitu, dobijamo mogućnost lako da primenjujemo i povlačimo promene u sistemima i aplikacijama. Takođe možemo koristiti Git-ove sigurnosne mehanizme za kontrolu vlasništva nad kodom i potvrdu njegove autentičnosti.

• Promene u konfiguracijama se mogu automatski primeniti pomoću pull zahteva

Z uporabo Gitovih pull requestov lahko enostavno upravljamo, kako se spremembe uporabljajo pri konfiguracijah v repozitoriju. Na primer, lahko jih predamo v pregled drugim članom ekipe ali jih preverimo skozi CI teste.

In pri tem ni potrebno dodeliti admin pravic kar na vse strani. Za izvedbo commitov sprememb v konfiguracijah, uporabniki potrebujejo ustrezne pravice v Git repozitoriju, kjer so te konfiguracije shranjene.

• Reševanje problema nekontroliranega driftanja konfiguracij

Ko je želena stanje sistema shranjeno v Git repozitoriju, nam preostane le še najti programsko opremo, ki bi nadzorovala, ali trenutno stanje sistema ustreza njegovemu želenemu stanju. Če to ni tako, mora ta programska oprema – odvisno od nastavitev – bodisi samodejno odpraviti neskladje bodisi nas obvestiti o driftanju konfiguracij.

GitOps modeli za OpenShift

Reconciler virov v klasterju

Po tem modelu v klasterju obstaja kontroler, ki je odgovoren za primerjavo Kubernetes virov (YAML datotek) v Git repozitoriju z resničnimi viri klasterja. Pri odkrivanju neskladij kontroler pošilja obvestila in morda sprejema ukrepe za odpravo neskladij. Ta GitOps model se uporablja v Anthos Config Management in Weaveworks Flux.

Zunanji Reconciler virov (Push)

Ta model lahko obravnavamo kot različico prejšnjega, ko imamo enega ali več kontrolerjev, odgovarjajočih za sinhronizacijo virov v parih „Git repozitorij – Kubernetes klaster“. Razlika je v tem, da v vsakem upravljanem klasterju ni nujno, da je lasten kontroler. Pari „Git – klaster k8s“ so pogosto opredeljeni kot CRD opisi (opredelitev prilagojenih virov), kjer je mogoče opisati, kako bi moral kontroler izvesti sinhronizacijo. V okviru tega modela kontrolerji primerjajo Git repozitorij, določen v CRD, z viri Kubernetes klasterja, ki so prav tako določeni v CRD, in izvajajo ustrezne ukrepe na podlagi rezultatov primerjave. Ta GitOps model se uporablja v ArgoCD.

GitOps na platformi OpenShift

Upravljanje multi-klasterske Kubernetes infrastrukture

Z razširitvijo Kubernetes in naraščajočo priljubljenostjo multi-cloud strategij ter obrobnih izračunov (edge computing) se povečuje tudi povprečno število OpenShift klasterjev na vsakega naročnika.

Na primer, pri uporabi perifernih računalništva lahko strankini klasterji delujejo v stotinah ali celo tisočih. Zaradi tega mora upravljati več neodvisnih ali usklajenih klasterjev OpenShift v javnem oblaku in na lokaciji.

Ob tem je potrebno rešiti vrsto težav, zlasti:

• Nadzorovati, da so klasterji v identičnem stanju (konfiguracije, nadzor, shranjevanje itd.).
• Ponovno ustvariti (ali obnoviti) klasterje iz znanega stanja.
• Ustvariti nove klasterje iz znanega stanja.
• Izvesti spremembe na več klasterjih OpenShift.
• Razveljaviti spremembe na več klasterjih OpenShift.
• Povezati šablonirane konfiguracije z različnimi okolji.

Konfiguracije aplikacij.

V svojem življenjskem ciklu aplikacije pogosto preidejo skozi verigo klasterjev (dev, stage itd.), preden pridejo v produkcijski klaster. Poleg tega zaradi zahtev po razpoložljivosti in skalirnosti stranke pogosto razporejajo aplikacije hkrati na več klasterjih na lokaciji ali v več regijah javne oblačne platforme.

Ob tem je potrebno rešiti naslednje naloge:

• Zagotavljati premikanje aplikacij (binarni datoteke, konfiguracije itd.) med klasterji (dev, stage itd.).
• Izvesti spremembe v aplikacijah (binarni datoteke, konfiguracije itd.) v več klasterjih OpenShift.
• Razveljaviti spremembe v aplikacijah do ravni prejšnjega znanega stanja.

Uporabniški scenariji OpenShift GitOps.

1. Uveljavljanje sprememb iz Git-repozitorija.

Administrator klasterja lahko shranjuje konfiguracije klasterja OpenShift v Git-repozitoriju in jih samodejno uveljavlja, da brez težav ustvari nove klasterje in jih pripelje v stanje, identično znanemu stanju, ki je shranjeno v Git-repozitoriju.

2. Sinhronizacija s Secret Manager.

Administratorju bo prav tako koristno, da lahko sinhronizira secret-objekte OpenShift z ustreznimi programi, kot je Vault, da jih upravlja s pomočjo posebnih orodij, ki so namenjena temu.

3. Nadzor driftanja konfiguracij.

Administrator bo vesel, če bo OpenShift GitOps sam odkrival in opozarjal na razlike med dejanskimi konfiguracijami in tistimi, ki so določene v repozitoriju, da bi se lahko hitro odzval na drift.

4. Obvestila o driftu konfiguracij

So koristna, ko želi administrator hitro vedeti o primerih driftanja konfiguracij, da lahko hitro sprejme ustrezne ukrepe samostojno.

5. Ročna sinhronizacija konfiguracij ob driftu

Omogoča administratorju sinhronizacijo OpenShift klasterja z Git repozitorijem v primeru driftanja konfiguracij, da hitro vrne klaster v prejšnje znano stanje.

6. Avtomatska sinhronizacija konfiguracij ob driftu

Administrator lahko prav tako nastavi OpenShift klaster na samodejno sinhronizacijo z repozitorijem ob odkritju driftanja, da je konfiguracija klasterja vedno usklajena z nastavitvami v Gitu.

7. Več klasterjev – en repozitorij

Administrator lahko shrani konfiguracije več različnih OpenShift klasterjev v enem Git repozitoriju in jih izbirno uporablja po potrebi.

8. Hierarhija klasterskih konfiguracij (dedovanje)

Administrator lahko določi hierarhijo klastrskih konfiguracij v repozitoriju (stage, prod, app portfolio itd. z dedovanjem). Z drugimi besedami, lahko določi, kako naj se konfiguracije uporabijo – za enega ali več klasterjev.

Na primer, če administrator v Git repozitoriju določi hierarhijo "Produkcijski klasterji (prod) → Klasterji sistema X → Produkcijski klasterji sistema X", potem se na produkcijske klasterje sistema X uporablja združevanje naslednjih konfiguracij:

• Konfiguracije, skupne vsem produkcijskim klasterjem.
• Konfiguracije za klaster sistema X.
• Konfiguracije za produkcijski klaster sistema X.

9. Predloge in preoblikovanje konfiguracij

Administrator lahko preoblikuje nabor podedovanih konfiguracij in njihovih vrednosti, na primer, da natančneje nastavi konfiguracijo za določene klasterje, za katere bodo uporabljene.

10. Izbirne vključitve in izključitve za konfiguracije, konfiguracije aplikacij

Administrator lahko določi pogoje za uporabo ali neuporabo določenih konfiguracij za klasterje z določenimi značilnostmi.

11. Podpora za predloge

Razvijalcem bo koristno, da izberejo, kako bodo opredeljeni viri aplikacije (Helm Chart, čisti Kubernetes YAML itd.), da bodo uporabili najustreznejši format za vsako posamezno aplikacijo.

GitOps orodja na platformi OpenShift

ArgoCD

ArgoCD implementira model External Resource Reconcile i nudi centralizirani UI za orkestraciju odnosa između klastera i Git repozitorija prema shemi 'jedan prema više'. Nedostaci ovog programa uključuju nemogućnost upravljanja aplikacijama kada ArgoCD ne radi.

Uradna spletna stran

Flux

Flux implementira model On-Cluster Resource Reconcile i, kao posledicu, ovde nema centralizovanog upravljanja repozitorijem definicija, što je slabost. S druge strane, upravo zbog nedostatka centralizacije, mogućnost upravljanja aplikacijama ostaje očuvana i pri kvaru jednog klastera.

Uradna spletna stran

Instalacija ArgoCD na OpenShift

ArgoCD pruža odličan komandni interfejs i web konzolu, stoga ovde nećemo razmatrati Flux i druge alternative.

Da biste postavili ArgoCD na OpenShift 4, pratite sledeće korake kao administrator klastera:

Postavljanje ArgoCD komponenti na 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}')

Modifikacija ArgoCD Server-a kako bi ga OpenShift Route mogao prepoznati

# 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

Postavljanje ArgoCD CLI alata

# 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

Promena administratorske lozinke ArgoCD Server-a

# 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

Nakon završetka ovih koraka, možete raditi sa ArgoCD Server-om putem ArgoCD WebUI ili ArgoCD CLI alata.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – nikada nije kasno

‘Voz je otišao’ – tako se govori o situaciji kada je prilika prokockana. U slučaju OpenShift-a, želja da odmah počnete koristiti ovu novu sjajnu platformu često stvara upravo takvu situaciju sa upravljanjem i održavanjem ruta, deploy-a i drugih OpenShift objekata. Ali da li je uvek prilika konačno prokockana?

Nastavljajući seriju članaka o GitOps, danas ćemo pokazati kako da prebacimo ručno kreiranu aplikaciju i njene resurse u proces kojim upravlja GitOps alat. Za to ćemo prvo ručno postaviti aplikaciju httpd. Na slici ispod je prikazano kako kreiramo prostor imena, deploy i servis, a potom obavljamo expose za ovaj servis kako bismo kreirali 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

Dakle, imamo ručno kreiranu aplikaciju. Sada je treba prevesti pod upravljanje GitOps bez gubitka dostupnosti. Ukratko, to radi na sledeći način:

• Kreiramo Git repozitorij za kod.
• Izvažamo naše trenutne objekte i učitavamo ih u Git repozitorij.
• Biramo i implementiramo alate GitOps.
• Dodajemo naš repozitorij u ovaj alat.
• Definišemo aplikaciju u našem GitOps alatu.
• Izvršavamo probni pokret aplikacije koristeći alat GitOps.
• Sinhronizujemo objekte sa alatom GitOps.
• Uključujemo čišćenje i automatsku sinhronizaciju objekata.

Kao što je već pomenuto, članku, u GitOps postoji jedan i jedini izvor informacija o svim objektima u Kubernetes klasteru/klausterima – Git repozitorij. Dalje pretpostavljamo da vaša organizacija već koristi Git repozitorij. On može biti javan ili privatan, ali mora biti dostupan Kubernetes klasterima. To može biti isti repozitorij koji se koristi za kod aplikacija, ili odvojeni repozitorij napravljen posebno za implementacije. U repozitoriju se preporučuje imati stroga prava, jer će sadržavati osjetljive objekte kao što su tajni ključevi, rute i druge sigurnosno osjetljive informacije.

U našem primeru, kreiraćemo novi javni repozitorij na GitHub-u. Možemo ga nazvati kako god želimo, koristimo ime blogpost.

Ako YAML datoteke objekata nisu bile sačuvane lokalno ili u Gitu, moraćemo koristiti binarne alate oc ili kubectl. Na slici ispod tražimo YAML za naš prostor imena, deployment, servis i rutu. Pre toga smo klonirali upravo kreirani repozitorij i prešli u njega komandom 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

Sada ćemo ispraviti datoteku deployment.yaml da uklonimo polje koje Argo CD ne može sinhronizovati.

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

Pored toga, potrebno je izmeniti rutu. Prvo ćemo postaviti višelinijsku promenljivu, a zatim zameniti ingress: null sadržajem te promenljive.

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

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

Dakle, sa datotekama smo rešeni, preostaje da ih sačuvamo u Git repozitorij. Nakon toga, ovaj repozitorij postaje jedini izvor informacija, i sve ručne promene objekata moraju biti strogo zabranjene.

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

Nato izhajamo iz tega, da je ArgoCD že nameščen (kako to narediti – glejte prejšnje objava). Zato bomo dodali v Argo CD našo ustvarjeno repositorij, ki vsebuje kodo aplikacije iz našega primera. Prepričajte se, da natančno navedete tisti repositorij, ki ste ga ustvarili prej.

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

Zdaj bomo ustvarili aplikacijo. Aplikacija določa vrednosti, da orodje GitOps razume, kateri repositorij in poti naj se uporabijo, katera OpenShift je potrebna za upravljanje objektov, ter katera konkretna veja repositorija je potrebna in ali naj se izvaja samodejna sinhronizacija virov.

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

Po tem, ko je aplikacija nastavljena v Argo CD, to orodje začne preverjati že nameščene objekte glede na definicije v repositoriju. V našem primeru sta samodejna sinhronizacija in čiščenje onemogočena, zato se elementi zaenkrat ne spreminjajo. Upoštevajte, da bo v vmesniku Argo CD naša aplikacija imela status „Out of Sync“ (Nesinhronizirano), saj ni label-oznake, ki jo dodeli ArgoCD.
Zato, ko bomo kasneje zagnali sinhronizacijo, ponovna namestitev objektov ne bo izvedena.

Sedaj izvedimo poskusni zagon, da se prepričamo, da v naših datotekah ni napak.

argocd app sync simple-app --dry-run

Če napak ni, lahko preidemo na sinhronizacijo.

argocd app sync simple-app

Po izvedbi ukaza argocd get nad našo aplikacijo bi morali videti, da se je status aplikacije spremenil v Healthy (Zdravo) ali Synced (Sinhronizirano). To bo pomenilo, da so vsi viri v repositoriju Git zdaj v skladu s tistimi viri, ki so že nameščeni.

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

Zdaj je mogoče vključiti samodejno sinhronizacijo in čiščenje, da zagotovimo, da se nič ne bo ustvarjalo ročno in da bo vsakič, ko se objekt ustvari ali posodobi v repositoriju, izvedena namestitev.

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

Tako, uspešno smo prešli na upravljanje aplikacije prek GitOps, ki sprva ni uporabljala GitOps.

Izvor: habr.com