🥇Uvod u GitOps za OpenShift

Danas ćemo govoriti o principima i modelima GitOpsa, kao io tome kako se ovi modeli implementiraju na OpenShift platformi. Dostupan je interaktivni vodič na ovu temu link.

Ukratko, GitOps je skup praksi za korištenje Git pull zahtjeva za upravljanje infrastrukturom i konfiguracijom aplikacija. Git spremište u GitOps-u se tretira kao jedan izvor informacija o stanju sistema, a sve promjene u ovom stanju su u potpunosti praćene i revidirane.

Ideja praćenja promjena u GitOps-u nikako nije nova; ovaj pristup se već dugo koristi gotovo univerzalno u radu s izvornim kodom aplikacije. GitOps jednostavno implementira slične funkcije (recenzije, zahtjevi za povlačenjem, oznake, itd.) u upravljanju infrastrukturom i konfiguracijom aplikacija i pruža slične prednosti kao u slučaju upravljanja izvornim kodom.

Ne postoji akademska definicija ili odobren skup pravila za GitOps, već samo skup principa na kojima je ova praksa izgrađena:

Deklarativni opis sistema je pohranjen u Git spremištu (konfiguracije, nadzor, itd.).
Promjene stanja se vrše putem zahtjeva za povlačenjem.
Stanje pokrenutih sistema se usklađuje sa podacima u spremištu pomoću Git push zahtjeva.

GitOps principi

Definicije sistema su opisane kao izvorni kod

Konfiguracija sistema se tretira kao kod tako da se može pohraniti i automatski verzionirati u Git spremištu, koje služi kao jedini izvor istine. Ovaj pristup olakšava uvođenje i vraćanje promjena u sistemima.

Željeno stanje i konfiguracija sistema su postavljeni i verzionisani u Gitu

Pohranjivanjem i verzioniranjem željenog stanja sistema u Gitu, u mogućnosti smo lako da uvedemo i vratimo promjene u sisteme i aplikacije. Također možemo koristiti Gitove sigurnosne mehanizme za kontrolu vlasništva koda i provjeru njegove autentičnosti.

Promjene konfiguracije mogu se automatski primijeniti putem zahtjeva za povlačenjem

Koristeći Git pull zahtjeve, možemo lako kontrolirati kako se promjene primjenjuju na konfiguracije u spremištu. Na primjer, mogu se dati drugim članovima tima na pregled ili proći kroz CI testove, itd.

A u isto vrijeme, nema potrebe za raspodjelom ovlasti administratora lijevo i desno. Da bi izvršili promjene konfiguracije, korisnicima su potrebne samo odgovarajuće dozvole u Git spremištu gdje su te konfiguracije pohranjene.

Rješavanje problema nekontroliranog odstupanja konfiguracija

Kada se željeno stanje sistema pohrani u Git spremište, sve što treba da uradimo je da pronađemo softver koji će osigurati da trenutno stanje sistema odgovara njegovom željenom stanju. Ako to nije slučaj, onda bi ovaj softver trebao - ovisno o postavkama - ili sam eliminirati neusklađenost ili nas obavijestiti o promjeni konfiguracije.

GitOps modeli za OpenShift

On-Cluster Resource Reconciler

Prema ovom modelu, klaster ima kontroler koji je odgovoran za upoređivanje Kubernetes resursa (YAML fajlova) u Git repozitorijumu sa stvarnim resursima klastera. Ako se otkriju odstupanja, kontrolor šalje obavještenja i eventualno poduzima radnje za ispravljanje neslaganja. Ovaj GitOps model se koristi u Anthos Config Management-u i Weaveworks Flux-u.

Reconciler vanjskih resursa (push)

Ovaj model se može smatrati varijacijom prethodnog, kada imamo jedan ili više kontrolera odgovornih za sinhronizaciju resursa u parovima “Git repozitorijum - Kubernetes klaster”. Razlika je u tome što svaki upravljani klaster ne mora nužno imati svoj poseban kontroler. Git - k8s parovi klastera se često definišu kao CRD-ovi (prilagođene definicije resursa), koji mogu opisati kako kontroler treba da izvrši sinhronizaciju. U okviru ovog modela, kontrolori upoređuju Git spremište navedeno u CRD-u sa resursima Kubernetes klastera, koji su takođe navedeni u CRD-u, i izvode odgovarajuće akcije na osnovu rezultata poređenja. Konkretno, ovaj GitOps model se koristi u ArgoCD-u.

GitOps na OpenShift platformi

Administracija multi-cluster Kubernetes infrastrukture

Sa širenjem Kubernetesa i rastućom popularnošću multi-cloud strategija i rubnog računanja, prosječan broj OpenShift klastera po korisniku također raste.

Na primjer, kada se koristi rubno računanje, klasteri jednog korisnika mogu biti raspoređeni na stotine ili čak hiljade. Kao rezultat toga, on je primoran da upravlja nekoliko nezavisnih ili koordinisanih OpenShift klastera u javnom oblaku i lokalno.

U ovom slučaju potrebno je riješiti mnogo problema, a posebno:

Kontrolirajte da li su klasteri u identičnom stanju (konfiguracije, nadzor, skladištenje, itd.)
Ponovno kreiranje (ili vraćanje) klastera na osnovu poznatog stanja.
Kreirajte nove klastere na osnovu poznatog stanja.
Uvedite promjene u više OpenShift klastera.
Vratite promjene u više OpenShift klastera.
Povežite šablonske konfiguracije sa različitim okruženjima.

Konfiguracije aplikacije

Tokom svog životnog ciklusa, aplikacije često prolaze kroz lanac klastera (dev, stage, itd.) prije nego što završe u proizvodnom klasteru. Osim toga, zbog zahtjeva dostupnosti i skalabilnosti, korisnici često postavljaju aplikacije u više lokalnih klastera ili više regija javne platforme u oblaku.

U ovom slučaju potrebno je riješiti sljedeće zadatke:

Osigurajte kretanje aplikacija (binarne, konfiguracije, itd.) između klastera (dev, stage, itd.).
Ubacite promjene u aplikacije (binarne datoteke, konfiguracije, itd.) u nekoliko OpenShift klastera.
Vratite promjene aplikacija na prethodno poznato stanje.

OpenShift GitOps slučajevi upotrebe

1. Primjena promjena iz Git spremišta

Administrator klastera može pohraniti OpenShift konfiguracije klastera u Git spremište i automatski ih primijeniti kako bi bez napora kreirao nove klastere i doveo ih u stanje identično poznatom stanju pohranjenom u Git spremištu.

2. Sinhronizacija sa Secret Manager-om

Administrator će takođe imati koristi od mogućnosti da sinhronizuje OpenShift tajne objekte sa odgovarajućim softverom kao što je Vault kako bi upravljao njima koristeći alate posebno kreirane za ovo.

3. Kontrola drift konfiguracija

Administrator će biti za samo ako OpenShift GitOps sam identificira i upozori na neslaganje između stvarnih konfiguracija i onih navedenih u spremištu, tako da mogu brzo reagirati na drift.

4. Obavijesti o promjeni konfiguracije

Korisni su u slučaju kada administrator želi brzo saznati o slučajevima promjene konfiguracije kako bi brzo samostalno poduzeo odgovarajuće mjere.

5. Ručna sinhronizacija konfiguracija prilikom drifta

Dozvoljava administratoru da sinhronizuje OpenShift klaster sa Git repozitorijumom u slučaju promene konfiguracije, kako bi brzo vratio klaster u prethodno poznato stanje.

6.Auto-sinhronizacija konfiguracija prilikom drifta

Administrator također može konfigurirati OpenShift klaster da se automatski sinkronizira sa spremištem kada se otkrije odstupanje, tako da konfiguracija klastera uvijek odgovara konfiguracijama u Gitu.

7. Nekoliko klastera - jedno spremište

Administrator može pohraniti konfiguracije nekoliko različitih OpenShift klastera u jedno Git spremište i selektivno ih primijeniti po potrebi.

8. Hijerarhija konfiguracija klastera (nasljeđivanje)

Administrator može postaviti hijerarhiju konfiguracija klastera u spremištu (stage, prod, app portfolio, itd. sa nasljeđivanjem). Drugim riječima, može odrediti da li konfiguracije treba primijeniti na jedan ili više klastera.

Na primjer, ako administrator postavi hijerarhiju “Proizvodni klasteri (prod) → Sistem X klasteri → Proizvodni klasteri sistema X” u Git spremištu, tada se kombinacija sljedećih konfiguracija primjenjuje na proizvodne klastere sistema X:

Konfiguracije zajedničke za sve proizvodne klastere.
Konfiguracije za System X klaster.
Konfiguracije za proizvodni klaster X sistema.

9. Predlošci i zaobilaženja konfiguracije

Administrator može nadjačati skup naslijeđenih konfiguracija i njihovih vrijednosti, na primjer, da fino podesi konfiguraciju za određene klastere na koje će se primijeniti.

10. Selektivno uključivanje i isključivanje za konfiguracije, konfiguracije aplikacije

Administrator može postaviti uslove za primjenu ili neprimjenu određenih konfiguracija na klastere sa određenim karakteristikama.

11. Podrška za šablone

Programeri će imati koristi od mogućnosti da odaberu kako će se resursi aplikacije definirati (Helm Chart, čisti Kubernetes yaml, itd.) kako bi koristili najprikladniji format za svaku specifičnu aplikaciju.

GitOps alati na OpenShift platformi

ArgoCD

ArgoCD implementira model External Resource Reconcile i nudi centralizirano korisničko sučelje za orkestriranje odnosa jedan-prema-više između klastera i Git spremišta. Nedostaci ovog programa uključuju nemogućnost upravljanja aplikacijama kada ArgoCD ne radi.

Službena web stranica

Tok

Flux implementira on-Cluster Resource Reconcile model i, kao rezultat, ne postoji centralizovano upravljanje spremištem definicija, što je slaba tačka. S druge strane, upravo zbog nedostatka centralizacije, ostaje mogućnost upravljanja aplikacijama čak i ako jedan klaster zakaže.

Službena web stranica

Instaliranje ArgoCD-a na OpenShift

ArgoCD nudi odličan interfejs komandne linije i web konzolu, tako da ovde nećemo pokrivati Flux i druge alternative.

Za implementaciju ArgoCD-a na OpenShift 4 platformi, slijedite ove korake kao administrator klastera:

Primena ArgoCD komponenti na OpenShift platformi

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

Poboljšanje ArgoCD servera tako da ga može vidjeti 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

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

Promjena lozinke administratora ArgoCD servera

# 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 sa ArgoCD serverom preko ArgoCD WebUI web konzole ili ArgoCD Cli alata komandne linije.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Nikad nije kasno

"Vlak je otišao" - tako kažu o situaciji kada je prilika da se nešto učini propuštena. U slučaju OpenShift-a, želja da se odmah počne koristiti ovu cool novu platformu često stvara upravo ovu situaciju sa upravljanjem i održavanjem ruta, implementacija i drugih OpenShift objekata. Ali da li je šansa uvek potpuno propuštena?

Nastavljamo seriju članaka o gitops, danas ćemo vam pokazati kako da transformišete ručno izrađenu aplikaciju i njene resurse u proces u kojem svime upravljaju GitOps alati. Da bismo to učinili, prvo ćemo ručno postaviti httpd aplikaciju. Snimak ekrana ispod pokazuje kako kreiramo imenski prostor, implementaciju i uslugu, a zatim izlažemo ovu uslugu za kreiranje rute.

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 izrađenu aplikaciju. Sada ga treba prenijeti pod GitOps upravljanje bez gubitka dostupnosti. Ukratko, radi ovo:

Kreirajte Git spremište za kod.
Izvozimo naše trenutne objekte i otpremamo ih u Git spremište.
Odabir i implementacija GitOps alata.
Dodali smo naše spremište ovom kompletu alata.
Definiramo aplikaciju u našem GitOps alatu.
Izvodimo probno pokretanje aplikacije pomoću GitOps alata.
Sinhroniziramo objekte koristeći GitOps alat.
Omogućite obrezivanje i automatsku sinkronizaciju objekata.

Kao što je spomenuto u prethodnom članak, u GitOps-u postoji jedan i jedini izvor informacija o svim objektima u Kubernetes klasteru(ima) - Git repozitorijum. Zatim polazimo od pretpostavke da vaša organizacija već koristi Git spremište. Može biti javna ili privatna, ali mora biti dostupna Kubernetes klasterima. Ovo može biti isto spremište kao za kod aplikacije, ili zasebno spremište kreirano posebno za implementacije. Preporučljivo je imati stroge dozvole u spremištu jer će tajne, rute i druge sigurnosno osjetljive stvari biti tamo pohranjene.

U našem primjeru, kreirat ćemo novo javno spremište na GitHubu. Možete ga nazvati kako god želite, mi koristimo naziv blogpost.

Ako YAML objektne datoteke nisu pohranjene lokalno ili u Gitu, onda ćete morati koristiti oc ili kubectl binarne datoteke. Na slici ispod tražimo YAML za naš imenski prostor, implementaciju, uslugu i rutu. Prije toga, klonirali smo novostvoreno spremište i cd u njega.

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 uredimo datoteku deployment.yaml da uklonimo polje koje Argo CD ne može sinkronizirati.

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

Osim toga, potrebno je promijeniti rutu. Prvo ćemo postaviti višelinijsku varijablu, a zatim zamijeniti ingress: null sa sadržajem te varijable.

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

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

Dakle, sredili smo fajlove, preostaje samo da ih sačuvamo u Git repozitorijum. Nakon toga ovo spremište postaje jedini izvor informacija, a bilo kakve ručne promjene objekata trebaju biti strogo zabranjene.

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

Dalje polazimo od činjenice da ste već postavili ArgoCD (kako to učiniti - pogledajte prethodni post). Stoga ćemo na Argo CD dodati spremište koje smo kreirali, koje sadrži kod aplikacije iz našeg primjera. Samo se pobrinite da navedete tačno spremište koje ste kreirali ranije.

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

Sada kreirajmo aplikaciju. Aplikacija postavlja vrijednosti tako da GitOps komplet alata razumije koje spremište i staze koristiti, koji je OpenShift potreban za upravljanje objektima, koja je specifična grana spremišta potrebna i da li se resursi trebaju automatski sinkronizirati.

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

Jednom kada je aplikacija specificirana na Argo CD-u, komplet alata počinje provjeravati već raspoređene objekte u odnosu na definicije u spremištu. U našem primjeru, automatska sinkronizacija i čišćenje su onemogućeni, tako da se elementi još uvijek ne mijenjaju. Imajte na umu da će u Argo CD interfejsu naša aplikacija imati status “Out of Sync” jer ne postoji oznaka koju ArgoCD pruža.
Zbog toga, kada malo kasnije započnemo sinhronizaciju, objekti se neće ponovo rasporediti.

Sada napravimo probni rad kako bismo bili sigurni da nema grešaka u našim datotekama.

argocd app sync simple-app --dry-run

Ako nema grešaka, možete nastaviti sa sinhronizacijom.

argocd app sync simple-app

Nakon pokretanja komande argocd get na našoj aplikaciji, trebali bismo vidjeti da se status aplikacije promijenio u Zdravo ili Sinhronizirano. To će značiti da svi resursi u Git spremištu sada odgovaraju onim resursima koji su već raspoređ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:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Sada možete omogućiti automatsku sinkronizaciju i čišćenje kako biste osigurali da se ništa ne kreira ručno i da će svaki put kada se objekt kreira ili ažurira u spremište, doći do implementacije.

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

Dakle, uspješno smo stavili aplikaciju pod GitOps kontrolu koja u početku nije ni na koji način koristila GitOps.

izvor: www.habr.com

Uvod u GitOps za OpenShift