Ievads GitOps OpenShift

Šodien mēs runāsim par GitOps principiem un modeļiem, kā arī par to, kā šie modeļi tiek īstenoti OpenShift platformā. Interaktīvas rokasgrāmatas šo tēmu apzināšanai ir pieejamas. caur saiti.

Ja īsi sakot, GitOps ir praktisku metožu kopums, kā izmantot Git pull pieprasījumus infrastruktūras un lietojumprogrammu konfigurāciju pārvaldībai. Git repozitorijs GitOps ietvaros tiek uzskatīts par vienīgu zināšanu avotu par sistēmas stāvokli, un jebkādas izmaiņas šajā stāvoklī tiek pilnībā uzskaitītas un var tikt auditētas.

Ideja par izmaiņu izsekojamību GitOps nav jauna; šī pieeja jau sen tiek plaši pielietota programmatūras avota kodā. GitOps vienkārši īsteno līdzīgas funkcijas (pārskati, pull pieprasījumi, birkas utt.) infrastruktūras un lietojumprogrammu konfigurāciju pārvaldībā un sniedz līdzīgus ieguvumus, kā tas ir avota koda pārvaldībā.

GitOps nav akademiska definīcija vai apstiprināts noteikumu kopums, bet gan principu kopums, uz kuru balstās šī prakse:

• Deklaratīvais sistēmas apraksts tiek glabāts Git repozitorijā (konfigurācijas, uzraudzība utt.).
• Stāvokļa izmaiņas tiek veiktas caur pull pieprasījumiem.
• Strādājošo sistēmu stāvoklis tiek pielāgots datiem repozitorijā, izmantojot Git push pieprasījumus.

GitOps principi

• Sistēmu definīcijas tiek aprakstītas kā avota kods

Sistēmu konfigurācija tiek uzskatīta par kodu, tādēļ to var glabāt un automātiski versiju vadīt Git repozitorijā, kas kalpo kā vienīgais patiesības avots. Šī pieeja ļauj viegli ieviest (rollout) un atcelt (rollback) izmaiņas sistēmās.

• Vēlamais stāvoklis un sistēmu konfigurācija tiek noteikta un versijā vadīta Git

Glabājot un versiju vadot Git vēlamo sistēmu stāvokli, mēs iegūstam iespēju viegli ieviest un atcelt izmaiņas sistēmās un lietojumprogrammās. Tāpat mēs varam izmantot Git mehānismus drošības nodrošināšanai, lai kontrolētu koda īpašumtiesības un autentiskumu.

• Izmaiņas konfigurācijās var automātiski piemērot, izmantojot pull pieprasījumus

Izmantojot Git pull pieprasījumus, mēs varam viegli pārvaldīt to, kā izmaiņas tiek piemērotas konfigurācijām repozitorijā. Piemēram, tās var nodot citu komandas dalībnieku pārbaudei vai palaist caur CI testiem un.

Un pie tam nav nepieciešams izsniegt administratora tiesības pa labi un pa kreisi. Lai veiktu izmaiņu commit konfigurācijās, lietotājiem ir nepieciešamas attiecīgas tiesības Git repozitorijā, kur šīs konfigurācijas tiek glabātas.

• Problemas ar nekontrolētu konfigurāciju novirzīšanos novēršana

Kad sistēmas vēlamais stāvoklis tiek glabāts Git repozitorijā, mums atliek tikai atrast programmatūru, kas kontrolē, vai pašreizējais sistēmas stāvoklis atbilst tās vēlamajam stāvoklim. Ja tas tā nav, šai programmatūrai – atkarībā no iestatījumiem – vai nu jānovērš neatbilstība pati, vai jāinformē mūs par konfigurāciju novirzīšanos.

GitOps modeļi OpenShift platformā

Datu resursu izlīdzinātājs uz klastera

Saskaņā ar šo modeli klasterī ir kontrolieris, kas atbild par Kubernetes resursu (YAML failu) salīdzināšanu Git repozitorijā ar reālajiem klastera resursiem. Atklājot neatbilstības, kontrolieris nosūta paziņojumus un, iespējams, veic darbības, lai novērstu neatbilstības. Šis GitOps modelis tiek izmantots Anthos Config Management un Weaveworks Flux.

Ārējais resursu izlīdzinātājs (Push)

Šo modeli var uzskatīt par iepriekšējā variāciju, kad mums ir viens vai vairāki kontrolieri, kas atbild par resursu sinhronizāciju pāros "Git repozitorijs – Kubernetes klasteris". Atšķirība šeit ir tā, ka katrā pārvaldītajā klasterī nav obligāti jābūt savam atsevišķam kontrolierim. Pāri "Git – k8s klasteris" bieži tiek definēti kā CRD apraksti (custom resources definition), kuros var norādīt, kā kontrolierim jāveic sinhronizācija. Šī modeļa ietvaros kontrolieri salīdzina Git repozitoriju, kas norādīts CRD, ar Kubernetes klastera resursiem, kuri arī ir norādīti CRD, un veic attiecīgas darbības pēc salīdzināšanas rezultātiem. Īpaši šādu GitOps modeli izmanto ArgoCD.

GitOps OpenShift platformā

Mūlti-klasteru Kubernetes infrastruktūras administrēšana

Līdz ar Kubernetes izplatību un vairāku mākoņu stratēģiju popularizēšanu un malūdeņu skaitļošanu, pieaug arī vidējais OpenShift klasteru skaits uz vienu klientu.

Piemēram, izmantojot perifēriskos aprēķinus, viena pasūtītāja klasteri var tikt izvērsti simtos un pat tūkstošos. Tādējādi viņam ir jāvada vairāki neatkarīgi vai saskaņoti OpenShift klasteri publiskajā mākoņos un uz vietas.

Taču ir jārisina virkne problēmu, tostarp:

• Kontrolēt, ka klasteri atrodas identiskā stāvoklī (konfigurācijas, uzraudzība, krātuves u. c.)
• Atjaunot (vai atjaunot) klasterus no zināmā stāvokļa.
• Izveidot jaunus klasterus no zināmā stāvokļa.
• Veikt izmaiņas vairākos OpenShift klasteros.
• Atcelt izmaiņas vairākos OpenShift klasteros.
• Saistīt veidnēm pielāgotas konfigurācijas ar dažādām vidēm.

Lietojumprogrammu konfigurācijas

Savā dzīves ciklā lietojumprogrammas bieži iziet cauri klasteru ķēdēm (dev, stage utt.), pirms nokļūst ražošanas klasterī. Turklāt, ņemot vērā pieejamības un mērogojamības prasības, pasūtītāji bieži izvērš lietojumprogrammas vairākos klasteros uz vietas vai dažādās publiskā mākoņa platformas reģionos.

Šajā kontekstā ir jārisina sekojošas uzdevumi:

• Nodrošināt lietojumprogrammu (binarizācijas, konfigurācijas utt.) pārvietošanu starp klasteriem (dev, stage utt.).
• Veikt izmaiņas lietojumprogrammās (binarizācijas, konfigurācijas utt.) vairākos OpenShift klasteros.
• Atcelt izmaiņas lietojumprogrammās līdz iepriekšējā zināmā stāvokļa līmenim.

OpenShift GitOps lietošanas scenāriji

1. Izmaiņu piemērošana no Git-repozitorija

Klastera administrators var glabāt OpenShift klastera konfigurācijas Git-repozitorijā un automātiski tās piemērot, lai bez liekām pūlēm izveidotu jaunus klasterus un novestu tos stāvoklī, kas ir identisks zināmajam stāvoklim, kas glabājas Git-repozitorijā.

2. Saskaņošana ar Secret Manager

Administrators var izmantot iespēju sinhronizēt OpenShift noslēpumu objektus ar attiecīgajām programmatūrām, piemēram, Vault, lai tos pārvaldītu ar speciāli izveidotiem rīkiem.

3. Konfigurāciju novirzes kontrole

Administrators tikai iepriecinās, ja OpenShift GitOps pats atklās un brīdinās par atšķirībām starp reālajām konfigurācijām un tām, kas norādītas repozitorijā, lai varētu operatīvi reaģēt uz novirzi.

4. Konfigurāciju novērošanas paziņojumi

Noderēs gadījumā, ja administrators vēlas operatīvi uzzināt par konfigurāciju novirzēm, lai ātri pieņemtu atbilstošus pasākumus patstāvīgi.

5. Roku sinhronizācija konfigurācijām novirzes gadījumā

Ļauj administratoram sinhronizēt OpenShift klasteri ar Git krātuvi konfigurāciju novirzes gadījumā, lai ātri atgrieztu klasteri iepriekšējā zināmā stāvoklī.

6. Automātiskā sinhronizācija konfigurācijām novirzes gadījumā

Administrators arī var iestatīt OpenShift klasteri automātiskai sinhronizācijai ar krātuvi, kad tiek konstatēta novirze, lai klastera konfigurācija vienmēr atbilstu konfigurācijām Git'ā.

7. Vairāki klasteri – viena krātuve

Administrators var glabāt vienā Git krātuvē konfigurācijas vairākām dažādām OpenShift klasteru, izvēlēties un pielietot tās pēc nepieciešamības.

8. Klasteru konfigurāciju hierarhija (mantošana)

Administrators var iestatīt klasteru konfigurāciju hierarhiju krātuvē (staging, prod, aplikāciju portfelis utt.) ar mantošanu. Citiem vārdiem sakot, viņš var noteikt, kādā veidā konfigurācijas tiks piemērotas – vienam vai vairākiem klasteriem.

Piemēram, ja administrators iestata Git krātuvē hierarhiju "Produkcijas klasteri (prod) → X sistēmas klasteri → X sistēmas produkcijas klasteri", tad pie produkcijas klasteriem X sistēmā tiks piemērots sekojošo konfigurāciju apvienojums:

• Konfigurācijas, kas visiem produkcijas klasteriem ir kopīgas.
• Konfigurācijas X sistēmas klasterim.
• Konfigurācijas X sistēmas produkcijas klasterim.

9. Veidnēs un konfigurāciju pārdefinēšana

Administrators var pārdefinēt mantoto konfigurāciju un to vērtību kopumu, piemēram, lai precīzāk pielāgotu konfigurāciju noteiktiem klasteriem, kuriem tās tiek piemērotas.

10. Izvēles iekļaušana un izslēgšana konfigurācijām, lietojumprogrammu konfigurācijām

Administrators var noteikt nosacījumus, lai piemērotu vai nepiemērotu noteiktas konfigurācijas klasteriem ar konkrētām īpašībām.

11. Veidņu atbalsts

Izstrādātājiem noderēs iespēja izvēlēties, kā tiks noteikti lietojumprogrammas resursi (Helm Chart, tīrs Kubernetes YAML utt.), lai izmantotu vispiemērotāko formātu katrai konkrētai lietojumprogrammai.

GitOps rīki OpenShift platformā

ArgoCD

ArgoCD īsteno ārējo resursu saskaņošanas modeli un piedāvā centralizētu UI, lai koordinētu attiecības starp klasteriem un Git repozitorijiem pēc «viens pret daudziem» shēmas. Programmas trūkumi ietver to, ka, ja ArgoCD nestrādā, nav iespējas pārvaldīt lietotnes.

Oficiālā mājas lapa

Flux

Flux īsteno on-cluster resursu saskaņošanas modeli, tādēļ šeit nav centralizētas definīciju repozitorija pārvaldības, kas ir vājā vieta. No otras puses, tieši centralizācijas trūkuma dēļ iespēja pārvaldīt lietotnes paliek pieejama, pat ja viens klasteris ir neaktivizējies.

Oficiālā mājas lapa

ArgoCD uzstādīšana OpenShift

ArgoCD piedāvā lielisku komandrindas saskarni un tīmekļa konsoli, tādēļ šeit neapspriedīsim Flux un citas alternatīvas.

Lai izvietotu ArgoCD OpenShift 4 platformā, veiciet tālāk norādītās darbības kā klastera administrators:

ArgoCD komponentu izvietošana OpenShift platformā

# 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 Server pielāgošana, lai to varētu redzēt 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 rīka izvietošana

# 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 Server administratora paroles maiņ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

Pēc šo darbību veikšanas ar ArgoCD Server var strādāt caur ArgoCD WebUI tīmekļa konsoli vai ArgoCD Cli komandrindas rīku.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – nekad nav par vēlu

«Vilciens ir aizgājis» – tā saka par situāciju, kad iespēja kaut ko izdarīt ir izlaista. Gadījumā ar OpenShift vēlme nekavējoties sākt izmantot šo jauno foršo platformu bieži rada tieši tādu situāciju ar maršrutu, deploy­mentu un citu OpenShift objektu pārvaldību un apkalpošanu. Bet vai vienmēr iespēja ir zaudēta uz visiem laikiem?

Turpinot rakstu sēriju par GitOps, šodien mēs parādīsim, kā pārvērst manuāli izveidoto lietotni un tās resursus kādā procesā, kurā visu pārvalda GitOps rīki. Tam mēs vispirms manuāli izvietosim httpd lietotni. Zemāk redzamajā ekrānuzņēmumā ir parādīts, kā mēs izveidojam nosaukuma telpu, deploy­mentu un pakalpojumu, un pēc tam veicam expose šim pakalpojumam, lai izveidotu marš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

Tātad, mums ir manuāli izveidota lietotne. Tagad tā jāizvērš, lai tā būtu zem GitOps pārvaldības bez pieejamības zuduma. Īsumā, tas tiek darīts šādi:

• Izveidojam Git repozitoriju kodam.
• Eksportējam mūsu pašreizējos objektus un augšupielādējam tos Git repozitorijā.
• Izvēlamies un izvietojam GitOps rīkus.
• Pievienojam šim rīkam mūsu repozitoriju.
• Definējam lietojumprogrammu mūsu GitOps rīkā.
• Veicam izmēģinājuma palaišanu, izmantojot GitOps rīku.
• Sinhronizējam objektus, izmantojot GitOps rīku.
• Iekļaujam tīrīšanu (pruning) un automātisko sinhronizāciju objektiem.

Kā jau iepriekš minēts, rakstāGitOps ir viens un vienīgais informācijas avots par visiem objektiem Kubernetes klasterī(ās) – Git repozitorijs. Turpmāk pieņemam, ka jūsu organizācijā jau tiek izmantots Git repozitorijs. Tam var būt publiska vai privāta piekļuve, bet tas noteikti ir jābūt pieejamam Kubernetes klasteriem. Tas var būt identisks repozitorijam, kuru izmantojat lietojumprogrammu kodam, vai arī atsevišķs repozitorijs, kas izveidots īpaši izvietošanai. Ieteicams repozitorijā ieviest stingras atļaujas, jo tur tiks glabāti slepenie objekti, ceļi un citi drošības ziņā jūtīgi priekšmeti.

Mūsu piemērā mēs izveidosim jaunu publisku repozitoriju GitHub. To var nosaukt kā vēlaties, mēs izmantojam nosaukumu blogpost.

Ja YAML objekta faili netika glabāti lokāli vai Git, nāksies izmantot oc vai kubectl bināros failus. Zemāk redzamajā ekrānšāviņā mēs pieprasām YAML mūsu nosaukuma telpai, izvietošanai, pakalpojumam un ceļam. Pirms tam mēs noklonējām tikko izveidoto repozitoriju un pārgājām tajā ar komandu 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

Tagad pielāgosim failu deployment.yaml, lai no tā izdzēstu lauku, kuru Argo CD nevar sinhronizēt.

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

Turklāt jāizmaina ceļš. Vispirms mēs iestatīsim daudzrindu mainīgo, pēc tam aizvietosim ingress: null ar šīs mainīgās saturu.

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

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

Tātad, ar failiem esam tikuši skaidrībā, tagad jāsaglabā tos Git repozitorijā. Pēc tam šis repozitorijs kļūst par vienīgo informācijas avotu, un jebkādas roku veiktas izmaiņas objektos ir stingri aizliegtas.

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

Tālāk mēs iznākam no tā, ka ArgoCD jums jau ir izvērsts (kā to izdarīt – skatiet iepriekšējo ziņa). Tāpēc pievienosim Argo CD mūsu izveidoto repozitoriju, kurā ir lietojumkoda piemērs. Tikai pārliecinieties, ka norādāt tieši to repozitoriju, kuru izveidojāt iepriekš.

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

Tagad izveidosim lietojumprogrammu. Lietojumprogramma nosaka vērtības, lai GitOps rīki saprastu, kuru repozitoriju un ceļus izmantot, kurš OpenShift nepieciešams objektiem, kā arī kāda konkrēta repozitorija zara nepieciešama un vai resursu automātiskā sinhronizācija jāveic.

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

Pēc tam, kad lietojumprogramma ir iestatīta Argo CD, šis rīks sāk pārbaudīt jau izvērstos objektus atbilstībai definīcijām repozitorijā. Mūsu piemērā automātiskā sinhronizācija un tīrīšana ir atslēgta, tāpēc elementi pagaidām nemainās. Lūdzu, ņemiet vērā, ka Argo CD saskarnē mūsu lietojumprogrammai būs statuss „Out of Sync” (Nesinhronizēts), jo nav label-atzīmes, kuru izveido ArgoCD.
Tāpēc, kad mēs drīz uzsāksim sinhronizāciju, atkārtota objektu izvēršana netiks veikta.

Tagad veiksim izmēģinājuma palaišanu, lai pārliecinātos, ka mūsu failos nav kļūdu.

argocd app sync simple-app --dry-run

Ja kļūdu nav, varam pāriet uz sinhronizāciju.

argocd app sync simple-app

Pēc komandas argocd get izpildes mūsu lietojumprogrammai, mums vajadzētu redzēt, ka lietojumprogrammas statuss ir mainījies uz Healthy (Vesels) vai Synced (Sinhronizēts). Tas nozīmēs, ka visi resursi repozitorijā Git tagad atbilst tiem resursiem, kas jau ir izvērsti.

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

Tagad jau varam ieslēgt automātisko sinhronizāciju un tīrīšanu, lai garantētu, ka nekas netiks izveidots manuāli un ka katru reizi, kad objekts tiek izveidots vai atjaunināts repozitorijā, tiek veikta izvēršana.

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

Tātad mēs sekmīgi esam pārgājuši uz GitOps pārvaldību lietotnei, kas sākotnēji nemaz neizmantoja GitOps.

Avots: habr.com