🥇Uvod u GitOps za OpenShift

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

Uvod u GitOps za OpenShift

Ukratko, GitOps je skup praktičnih metoda korištenja pull zahtjeva Git-a za upravljanje konfiguracijama infrastrukture i aplikacija. Git repozitorij unutar GitOps-a se promatra kao jedinstveni izvor informacija o stanju sustava, pri čemu se sve promjene tog stanja potpuno prate i mogu se auditirati.

Ideja praćenja promjena u GitOps-u nije nova; takav pristup se već dugo i praktički svugdje koristi pri radu s izvorom koda aplikacija. GitOps jednostavno implementira slične funkcije (revizijske provjere, pull zahtjeve, oznake itd.) pri upravljanju konfiguracijama infrastrukture i aplikacija, pružajući slične pogodnosti kao u slučaju upravljanja izvorom koda.

Za GitOps ne postoji akademska definicija ili odobreni skup pravila, već skup principa na kojima se temelji ova praksa:

Deklarativni opis sustava pohranjuje se u Git repozitoriju (konfiguracije, nadzor itd.).
Promjene stanja se vrše putem pull zahtjeva.
Stanje radnih sustava usklađuje se s podacima u repozitoriju pomoću push zahtjeva Git-a.

Principi GitOps-a

Definicije sustava opisuju se kao izvorni kod

Konfiguracija sustava se promatra kao kod, stoga se može pohranjivati i automatski verzionirati u Git repozitoriju, koji služi kao jedini izvor istine. Ovaj pristup omogućava lako implementiranje (rollout) i vraćanje (rollback) promjena u sustavima.

Željeno stanje i konfiguracija sustava postavljaju se i verzioniraju u Git-u

Pohranjujući i verzionirajući u Git-u željeno stanje sustava, dobivamo mogućnost lako implementirati i vratiti promjene u sustavima i aplikacijama. Također možemo koristiti Git-ove mehanizme sigurnosti za kontrolu vlasništva nad kodom i potvrdu njegove autentičnosti.

Promjene u konfiguracijama mogu se automatski primjenjivati pomoću pull zahtjeva.

Koristeći Git pull zahtjeve, možemo lako upravljati načinom na koji se promjene primjenjuju na konfiguracije u repozitoriju. Na primjer, mogu se poslati na pregled drugim članovima tima ili ih pokrenuti kroz CI testove i drugo.

I pritom nije potrebno dodjeljivati administratorska ovlaštenja lijevo i desno. Da bi izvršili commit promjena u konfiguraciji, korisnicima su potrebna odgovarajuća ovlaštenja u Git repozitoriju u kojem se čuvaju te konfiguracije.

Rješavanje problema nekontroliranog driftanja konfiguracija

Kada se željeno stanje sustava čuva u Git repozitoriju, ostaje nam samo pronaći softver koji bi pratio da je trenutno stanje sustava u skladu s njegovim željenim stanjem. Ako to nije slučaj, softver bi trebao – ovisno o postavkama – ili samostalno riješiti neslaganje ili nas obavijestiti o driftanju konfiguracija.

GitOps modeli za OpenShift

On-Cluster Resource Reconciller

Prema ovom modelu, u klasteru postoji kontroler koji je zadužen za usporedbu Kubernetes resursa (YAML datoteka) u Git repozitoriju s aktualnim resursima klastera. Kada se otkriju neslaganja, kontroler šalje obavijesti i, možda, poduzima mjere za ispravljanje neslaganja. Ovaj GitOps model koristi se u Anthos Config Management i Weaveworks Flux.

Uvod u GitOps za OpenShift

External Resource Reconciler (Push)

Ovaj model se može smatrati varijantom prethodnog, kada imamo jedan ili više kontrolera zaduženih za sinhronizaciju resursa u parovima "Git repozitorij – Kubernetes klaster". Razlika je u tome što u svakom upravljanom klasteru ne mora nužno postojati odvojeni kontroler. Parovi "Git – k8s klaster" često se definiraju kao CRD opisi (custom resources definition), gdje se može opisati kako kontroler treba izvršiti sinhronizaciju. U okviru ovog modela, kontroleri uspoređuju Git repozitorij zadan u CRD-u s resursima klastera Kubernetes koji su također zadan u CRD-u i poduzimaju odgovarajuće mjere temeljem rezultata usporedbe. Konkretno, ovaj GitOps model koristi se u ArgoCD.

Uvod u GitOps za OpenShift

GitOps na OpenShift platformi

Upravljanje multiklasternom Kubernetes infrastrukturom

S širenjem Kubernetes-a i rastom popularnosti multicloud strategija i edge computing-a, povećava se i prosječan broj OpenShift klastera po klijentu.

Na primjer, prilikom korištenja perifernih računalnih sustava, klasteri jednog korisnika mogu se raspoređivati u stotinama, pa čak i tisućama. Kao rezultat toga, on je prisiljen upravljati s nekoliko neovisnih ili koordiniranih klastera OpenShift u javnom oblaku i on-premise.

Pri tome se mora riješiti mnoštvo problema, konkretno:

Kontrolirati da su klasteri u identičnom stanju (konfiguracije, nadzor, pohrane itd.)
Ponovno kreirati (ili vraćati) klastere prema poznatom stanju.
Kreirati nove klastere prema poznatom stanju.
Primijeniti promjene na nekoliko klastera OpenShift.
Povratiti promjene na nekoliko klastera OpenShift.
Uskladiti templatisane konfiguracije s različitim okruženjima.

Konfiguracije aplikacija

Tokom svog životnog ciklusa aplikacije često prolaze kroz niz klastera (dev, stage itd.) prije nego što dospjela u produkcijski klaster. Osim toga, zbog zahtjeva dostupnosti i skalabilnosti, korisnici često raspoređuju aplikacije odmah na nekoliko klastera on-premise ili u nekoliko regija javne oblačne platforme.

Pri tome se moraju riješiti sljedeći zadaci:

Osigurati kretanje aplikacija (binarne datoteke, konfiguracije itd.) između klastera (dev, stage itd.).
Primijeniti promjene u aplikacijama (binarne datoteke, konfiguracije itd.) na nekoliko klastera OpenShift.
Povratiti promjene u aplikacijama na razinu prethodnog poznatog stanja.

Scenariji korištenja OpenShift GitOps

1. Primjena promjena iz Git-repozitorija

Administrator klastera može pohranjivati konfiguracije klastera OpenShift u Git-repozitoriju i automatski ih primjenjivati kako bi bez dodatnih napora kreirali nove klastere i doveli ih u stanje identično poznatom stanju, koje se čuva u Git-repozitoriju.

2. Sinkronizacija s Secret Managerom

Administratoru će također koristiti mogućnost sinkronizacije secret-objekata OpenShift-a s odgovarajućim softverom poput Vault-a, kako bi njima upravljao putem posebno stvorenih alata.

3. Kontrola driftanja konfiguracija

Administrator će biti sretan ako OpenShift GitOps samo detektira i obavijesti o nesukladnostima između stvarnih konfiguracija i onih koje su zadane u repozitoriju, kako bi mogao pravovremeno reagirati na drift.

4. Obavijesti o odstupanju konfiguracija

Bit će korisne kada admin želi brzo saznati o slučajevima odstupanja konfiguracija kako bi brzo poduzeo odgovarajuće mjere.

5. Ručna sinkronizacija konfiguracija tijekom odstupanja

Omogućuje adminu da sinkronizira OpenShift klaster s Git repozitorijem u slučaju odstupanja konfiguracija kako bi brzo vratio klaster na prethodno poznato stanje.

6. Automatizirana sinkronizacija konfiguracija tijekom odstupanja

Admin također može postaviti OpenShift klaster na automatsku sinkronizaciju s repozitorijem prilikom otkrivanja odstupanja kako bi konfiguracija klastera uvijek odgovarala onima u Git-u.

7. Više klastera – jedan repozitorij

Admin može pohraniti u jednom Git repozitoriju konfiguracije više različitih OpenShift klastera i selektivno ih primjenjivati prema potrebi.

8. Hijerarhija klasterskih konfiguracija (nasljeđivanje)

Admin može postaviti hijerarhiju klasterskih konfiguracija u repozitoriju (stage, prod, app portfolio itd. s nasljeđivanjem). Drugim riječima, može odrediti kako bi se konfiguracije trebale primjenjivati – na jedan ili više klastera.

Na primjer, ako admin postavi hijerarhiju u Git repozitoriju "Prodajni klasteri (prod) → Klasteri sustava X → Prodajni klasteri sustava X", tada se na prodajne klastere sustava X primjenjuju kombinacije sljedećih konfiguracija:

Konfiguracije koje su zajedničke za sve prodajne klastere.
Konfiguracije za klaster sustava X.
Konfiguracije za prodajni klaster sustava X.

9. Predlošci i prepisivanje konfiguracija

Admin može prepisati skup naslijeđenih konfiguracija i njihovih vrijednosti kako bi preciznije prilagodio konfiguraciju za određene klastere kojima će biti primijenjena.

10. Izvrsni include-i i exclude-i za konfiguracije, konfiguracije aplikacija

Admin može postaviti uvjete za primjenu ili neprimjenu određenih konfiguracija na klastere s određenim karakteristikama.

11. Podrška za predloške

Razvijat će cijeniti mogućnost odabira kako će se definirati resursi aplikacije (Helm Chart, čisti Kubernetes yaml itd.) kako bi koristili najprikladniji format za svaku pojedinu aplikaciju.

GitOps alati na OpenShift platformi

ArgoCD

ArgoCD implementira model External Resource Reconcile i nudi centralizirano UI za orkestraciju odnosa između klastera i Git repozitorija po shemi 'jedan prema mnogima'. Nedostatak ovog alata je nemogućnost upravljanja aplikacijama kada ArgoCD ne radi.

Službena stranica

Flux

Flux implementira model On-Cluster Resource Reconcile, i zbog toga ne postoji centralizirano upravljanje repozitorijem definicija, što predstavlja slabost. S druge strane, zbog nedostatka centralizacije, mogućnost upravljanja aplikacijama ostaje čak i kada jedan klaster otkaže.

Službena stranica

Instalacija ArgoCD na OpenShift

ArgoCD nudi odličan komandni interfejs i web konzolu, tako da ovdje nećemo razmatrati Flux i druge alternative.

Da biste implementirali ArgoCD na platformi OpenShift 4, slijedite sljedeće korake kao administrator klastera:

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

Modifikacija ArgoCD poslužitelja kako bi ga OpenShift Route prepoznao

# 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

Implementacija 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

Promjena administratorske lozinke ArgoCD poslužitelja

# 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 što završite ove korake, možete raditi s ArgoCD poslužiteljem putem ArgoCD WebUI ili ArgoCD CLI alata.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – nikad nije prekasno

"Vlak je otišao" – to se kaže o situaciji kada je prilika propuštena. U slučaju OpenShifta, želja da odmah počnete koristiti ovu novu sjajnu platformu često stvara upravo takvu situaciju s upravljanjem i održavanjem ruta, deploymenata i drugih objekata OpenShifta. No, je li uvijek prilika zaista propuštena?

Nastavljajući seriju članaka o GitOps, danas ćemo pokazati kako transformirati ručno stvorenu aplikaciju i njene resurse u proces koji upravlja GitOps alat. Za to ćemo prvo ručno implementirati aplikaciju httpd. Na slici ispod prikazano je kako stvaramo prostor imena, deployment i servis, a zatim izlažemo taj servis kako bismo stvorili rutu.

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 stvorenu aplikaciju. Sada je trebamo prevesti pod upravljanje GitOps bez gubitka dostupnosti. Ukratko, to radi ovako:

Stvaramo Git repozitorij za kod.
Izvozimo naše trenutne objekte i učitavamo ih u Git repozitorij.
Odabiremo i implementiramo GitOps alat.
Dodajemo naš repozitorij u ovaj alat.
Definiramo aplikaciju u našem GitOps alatu.
Izvodi se probno pokretanje aplikacije koristeći GitOps alat.
Sinkroniziramo objekte pomoću GitOps alata.
Aktiviramo čišćenje (pruning) i automatsku sinkronizaciju objekata.

Kao što je već rečeno u prethodnoj članku, u GitOps postoji samo jedan izvor informacija o svim objektima u Kubernetes klasteru(ima) – Git repozitorij. Dalje pretpostavljamo da vaša organizacija već koristi Git repozitorij. Može biti javni ili privatni, ali mora biti dostupan Kubernetes klasterima. To može biti isti repozitorij kao i za kod aplikacija, ili odvojeni repozitorij kreiran posebno za implementacije. Preporučuje se postavljanje stroge autorizacije u repozitoriju, jer će tu biti pohranjeni osjetljivi objekti, poput tajni, ruta i drugih sigurnosno osjetljivih podataka.

U našem primjeru stvorit ćemo novi javni repozitorij na GitHub-u. Možete ga nazvati kako želite, mi koristimo naziv blogpost.

Ako YAML datoteke objekata nisu pohranjene lokalno ili u Gitu, moraćete koristiti binarne datoteke oc ili kubectl. Na slici ispod tražimo YAML za naš prostor imena, deployment, uslugu i rutu. Prije toga smo klonirali upravo stvoreni repozitorij i prešli u njega naredbom 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 urediti datoteku deployment.yaml kako bismo uklonili polje koje Argo CD ne može sinkronizirati.

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

Osim toga, treba izmijeniti rutu. Prvo postavljamo višelinijsku varijablu, a zatim zamjenjujemo ingress: null s sadržajem te varijable.

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

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

Dakle, kad smo se pozabavili datotekama, ostaje ih sačuvati u Git repozitorij. Nakon toga, taj repozitorij postaje jedini izvor informacija, a svake ručne promjene objekata trebaju biti strogo zabranjene.

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

Nastavljamo na temelju pretpostavke da je ArgoCD već implementiran (kako to učiniti – vidite prethodni post). Stoga dodajemo u Argo CD našu kreiranu repozitorij, koja sadrži kod aplikacije iz našeg primjera. Samo se pobrinite da navedete upravo onaj repozitorij koji ste ranije stvorili.

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

Sada kreiramo aplikaciju. Aplikacija definira vrijednosti kako bi GitOps alati razumjeli koji repozitorij i putanje koristiti, koji OpenShift je potreban za upravljanje objektima, te koja konkretna grana repozitorija je potrebna, i treba li se automatski sinkronizirati resursi.

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

Nakon što je aplikacija definirana u Argo CD, ovaj alat počinje provjeravati već implementirane objekte kako bi se osiguralo da odgovaraju definicijama u repozitoriju. U našem primjeru, automatska sinkronizacija i čišćenje su isključeni, stoga se objekti još uvijek ne mijenjaju. Imajte na umu da će u sučelju Argo CD naša aplikacija imati status „Out of Sync“ (Nije sinkronizirano), budući da nema label-oznake koju postavlja ArgoCD.
Zato, kada kasnije pokrenemo sinkronizaciju, ponovno implementiranje objekata se neće izvršiti.

Sada ćemo izvršiti probnu akciju kako bismo provjerili da li u našim datotekama nema grešaka.

argocd app sync simple-app --dry-run

Ako nema grešaka, možemo prijeći na sinkronizaciju.

argocd app sync simple-app

Nakon izvršenja komande argocd get nad našom aplikacijom, trebali bismo vidjeti da se status aplikacije promijenio u Healthy (Zdrav) ili Synced (Sinkronizirano). To će značiti da su svi resursi u Git repozitoriju sada u skladu s onim resursima koji su već implementirani.

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

Sada možemo uključiti automatsku sinkronizaciju i čišćenje kako bismo osigurali da se ništa ne stvara ručno te da će se svaki put kada se objekt kreira ili ažurira u repozitoriju izvršiti implementacija.

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

Dakle, uspješno smo prebacili aplikaciju pod kontrolu GitOps koja isprva nije koristila GitOps.

Izvor: habr.com