🥇 Hyrje në GitOps për OpenShift

Sot do të flasim për parimet dhe modelet e GitOps, si dhe për mënyrën se si këto modele zbatohen në platformën OpenShift. Një udhëzues interaktiv për këtë temë është në dispozicion по ссылке.

Me pak fjalë, GitOps është një grup praktikash për përdorimin e kërkesave për tërheqje të Git për të menaxhuar infrastrukturën dhe konfigurimet e aplikacioneve. Depoja e Git në GitOps trajtohet si një burim i vetëm informacioni për gjendjen e sistemit dhe çdo ndryshim në këtë gjendje është plotësisht i gjurmueshëm dhe i auditueshëm.

Ideja e gjurmimit të ndryshimit në GitOps nuk është aspak e re; kjo qasje është përdorur prej kohësh pothuajse në mënyrë universale kur punoni me kodin burimor të aplikacionit. GitOps thjesht zbaton veçori të ngjashme (rishikime, kërkesa për tërheqje, etiketa, etj.) në menaxhimin e infrastrukturës dhe konfigurimit të aplikacionit dhe ofron përfitime të ngjashme si në rastin e menaxhimit të kodit burimor.

Nuk ka asnjë përkufizim akademik apo grup rregullash të miratuara për GitOps, vetëm një grup parimesh mbi të cilat është ndërtuar kjo praktikë:

Përshkrimi deklarativ i sistemit ruhet në depon e Git (konfigurimet, monitorimi, etj.).
Ndryshimet e gjendjes bëhen përmes kërkesave për tërheqje.
Gjendja e sistemeve të funksionimit është sjellë në përputhje me të dhënat në depo duke përdorur kërkesat pushuese Git.

Parimet e GitOps

Përkufizimet e sistemit përshkruhen si kod burimor

Konfigurimi i sistemeve trajtohet si kod, kështu që mund të ruhet dhe të versionohet automatikisht në një depo Git, e cila shërben si një burim i vetëm i së vërtetës. Kjo qasje e bën të lehtë vendosjen dhe rikthimin e ndryshimeve në sisteme.

Gjendja e dëshiruar dhe konfigurimi i sistemeve vendosen dhe versionohen në Git

Duke ruajtur dhe versionuar gjendjen e dëshiruar të sistemeve në Git, ne jemi në gjendje të nxjerrim dhe të kthejmë lehtësisht ndryshimet në sisteme dhe aplikacione. Ne gjithashtu mund të përdorim mekanizmat e sigurisë së Git për të kontrolluar pronësinë e kodit dhe për të verifikuar vërtetësinë e tij.

Ndryshimet e konfigurimit mund të aplikohen automatikisht nëpërmjet kërkesave për tërheqje

Duke përdorur kërkesat e tërheqjes së Git, ne mund të kontrollojmë lehtësisht se si zbatohen ndryshimet në konfigurimet në depo. Për shembull, ato mund t'u jepen anëtarëve të tjerë të ekipit për rishikim ose të kalojnë përmes testeve CI, etj.

Dhe në të njëjtën kohë, nuk ka nevojë të shpërndani fuqitë e administratorit majtas dhe djathtas. Për të kryer ndryshime të konfigurimit, përdoruesve u duhen vetëm lejet e duhura në depon e Git ku ruhen ato konfigurime.

Rregullimi i problemit të zhvendosjes së pakontrolluar të konfigurimeve

Pasi gjendja e dëshiruar e sistemit të ruhet në një depo Git, gjithçka që duhet të bëjmë është të gjejmë softuer që do të sigurojë që gjendja aktuale e sistemit të përputhet me gjendjen e dëshiruar. Nëse nuk është kështu, atëherë ky softuer duhet - në varësi të cilësimeve - ose të eliminojë mospërputhjen vetë, ose të na njoftojë për zhvendosjen e konfigurimit.

Modelet GitOps për OpenShift

Barazuesi i burimeve në grup

Sipas këtij modeli, grupi ka një kontrollues që është përgjegjës për krahasimin e burimeve Kubernetes (skedarët YAML) në depo Git me burimet reale të grupit. Nëse zbulohen mospërputhje, kontrolluesi dërgon njoftime dhe ndoshta ndërmerr veprime për të korrigjuar mospërputhjet. Ky model GitOps përdoret në Anthos Config Management dhe Weaveworks Flux.

Barazuesi i burimeve të jashtme (Push)

Ky model mund të konsiderohet si një variant i atij të mëparshmi, kur kemi një ose më shumë kontrollues përgjegjës për sinkronizimin e burimeve në çiftet "magazina Git - grupi Kubernetes". Dallimi këtu është se çdo grup i menaxhuar nuk ka domosdoshmërisht kontrolluesin e tij të veçantë. Çiftet e grupimeve Git - k8s shpesh përcaktohen si CRD (përkufizime të burimeve të personalizuara), të cilat mund të përshkruajnë se si kontrolluesi duhet të kryejë sinkronizimin. Brenda këtij modeli, kontrollorët krahasojnë depon e Git të specifikuar në CRD me burimet e grupit Kubernetes, të cilat specifikohen gjithashtu në CRD, dhe kryejnë veprimet e duhura bazuar në rezultatet e krahasimit. Në veçanti, ky model GitOps përdoret në ArgoCD.

GitOps në platformën OpenShift

Administrimi i infrastrukturës Kubernetes me shumë grupime

Me përhapjen e Kubernetes dhe popullaritetin në rritje të strategjive me shumë re dhe llogaritjes së skajeve, numri mesatar i grupimeve OpenShift për klient po rritet gjithashtu.

Për shembull, kur përdorni llogaritjen e skajshme, grupet e një klienti mund të vendosen në qindra apo edhe mijëra. Si rezultat, ai detyrohet të menaxhojë disa grupime të pavarura ose të koordinuara OpenShift në renë publike dhe në premisë.

Në këtë rast, shumë probleme duhet të zgjidhen, veçanërisht:

Kontrolloni që grupet të jenë në gjendje identike (konfigurime, monitorim, ruajtje, etj.)
Rikrijoni (ose rivendosni) grupe bazuar në një gjendje të njohur.
Krijoni grupime të reja bazuar në një gjendje të njohur.
Shpërndani ndryshime në grupe të shumta OpenShift.
Rikthe ndryshimet në grupe të shumta OpenShift.
Lidhni konfigurimet e shablloneve me mjedise të ndryshme.

Konfigurimet e aplikacionit

Gjatë ciklit të tyre jetësor, aplikacionet shpesh kalojnë përmes një zinxhiri grupimesh (dev, stadi, etj.) përpara se të përfundojnë në një grup prodhimi. Për më tepër, për shkak të kërkesave të disponueshmërisë dhe shkallëzueshmërisë, klientët shpesh vendosin aplikacione nëpër grupe të shumta në premisë ose rajone të shumta të një platforme publike cloud.

Në këtë rast, detyrat e mëposhtme duhet të zgjidhen:

Siguroni lëvizjen e aplikacioneve (binare, konfigurime, etj.) ndërmjet grupimeve (dev, stadi, etj.).
Shpërndani ndryshimet në aplikacione (binare, konfigurime, etj.) në disa grupe OpenShift.
Rikthe ndryshimet në aplikacione në një gjendje të mëparshme të njohur.

Rastet e përdorimit të OpenShift GitOps

1. Zbatimi i ndryshimeve nga depoja e Git

Një administrator grupi mund të ruajë konfigurimet e grupit OpenShift në një depo Git dhe t'i zbatojë ato automatikisht për të krijuar pa mundim grupime të reja dhe për t'i sjellë ato në një gjendje identike me gjendjen e njohur të ruajtur në depo Git.

2. Sinkronizimi me Menaxherin Sekret

Administratori do të përfitojë gjithashtu nga aftësia për të sinkronizuar objektet sekrete të OpenShift me softuerin e duhur si Vault në mënyrë që t'i menaxhojë ato duke përdorur mjete të krijuara posaçërisht për këtë.

3. Kontrolli i konfigurimeve të driftit

Administratori do të jetë në favor vetëm nëse vetë OpenShift GitOps identifikon dhe paralajmëron për mospërputhjet midis konfigurimeve reale dhe atyre të specifikuara në depo, në mënyrë që ata të mund t'i përgjigjen shpejt driftit.

4. Njoftimet rreth zhvendosjes së konfigurimit

Ato janë të dobishme në rastin kur administratori dëshiron të mësojë shpejt për rastet e zhvendosjes së konfigurimit në mënyrë që të marrë shpejt masat e duhura vetë.

5. Sinkronizimi manual i konfigurimeve gjatë lëvizjes

Lejon administratorin të sinkronizojë grupin OpenShift me depon e Git në rast të zhvendosjes së konfigurimit, për ta kthyer shpejt grupin në një gjendje të mëparshme të njohur.

6.Auto-sinkronizimi i konfigurimeve gjatë lëvizjes

Administratori mund të konfigurojë gjithashtu grupin OpenShift që të sinkronizohet automatikisht me depon kur zbulohet një zhvendosje, në mënyrë që konfigurimi i grupit të përputhet gjithmonë me konfigurimet në Git.

7. Disa grupime - një depo

Administratori mund të ruajë konfigurimet e disa grupeve të ndryshme OpenShift në një depo Git dhe t'i zbatojë ato në mënyrë selektive sipas nevojës.

8. Hierarkia e konfigurimeve të grupimeve (trashëgimia)

Administratori mund të vendosë një hierarki të konfigurimeve të grupimeve në depo (faza, prod, portofoli i aplikacioneve, etj. me trashëgimi). Me fjalë të tjera, mund të përcaktojë nëse konfigurimet duhet të aplikohen në një ose më shumë grupime.

Për shembull, nëse një administrator vendos hierarkinë "Grupet e prodhimit (prod) → grupimet e sistemit X → grupimet e prodhimit të sistemit X" në depon e Git, atëherë një kombinim i konfigurimeve të mëposhtme zbatohet në grupimet e prodhimit të sistemit X:

Konfigurimet e zakonshme për të gjitha grupimet e prodhimit.
Konfigurimet për grupin System X.
Konfigurimet për grupin e prodhimit të sistemit X.

9. Modelet dhe konfigurimet anashkalohen

Administratori mund të anashkalojë një grup konfigurimesh të trashëguara dhe vlerat e tyre, për shembull, për të rregulluar mirë konfigurimin për grupe specifike në të cilat do të aplikohen.

10. Përfshirja dhe përjashtimi selektiv për konfigurimet, konfigurimet e aplikacioneve

Administratori mund të vendosë kushtet për aplikimin ose mosaplikimin e konfigurimeve të caktuara në grupe me karakteristika të caktuara.

11. Mbështetja e shabllonit

Zhvilluesit do të përfitojnë nga aftësia për të zgjedhur se si do të përcaktohen burimet e aplikacionit (Helm Chart, pastër Kubernetes yaml, etj.) në mënyrë që të përdorin formatin më të përshtatshëm për çdo aplikacion specifik.

Mjetet GitOps në platformën OpenShift

ArgoCD

ArgoCD zbaton modelin External Resource Reconcile dhe ofron një UI të centralizuar për orkestrimin e marrëdhënieve një-në-shumë midis grupimeve dhe depove Git. Disavantazhet e këtij programi përfshijnë pamundësinë për të menaxhuar aplikacionet kur ArgoCD nuk funksionon.

Faqja zyrtare

Gradient

Flux zbaton një model të Pajtimit të Burimeve On-Cluster dhe, si rezultat, nuk ka një menaxhim të centralizuar të depove të përkufizimeve, që është një pikë e dobët. Nga ana tjetër, pikërisht për shkak të mungesës së centralizimit, aftësia për të menaxhuar aplikacionet mbetet edhe nëse një grup dështon.

Faqja zyrtare

Instalimi i ArgoCD në OpenShift

ArgoCD ofron një ndërfaqe të shkëlqyeshme të linjës komanduese dhe tastierë në internet, kështu që ne nuk do të mbulojmë Flux dhe alternativat e tjera këtu.

Për të vendosur ArgoCD në platformën OpenShift 4, ndiqni këto hapa si administrator grupi:

Vendosja e komponentëve ArgoCD në platformën 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}')

Përmirësimi i Serverit ArgoCD në mënyrë që të mund të shihet nga 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

Vendosja e ArgoCD Cli Tool

# 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

Ndryshimi i fjalëkalimit të administratorit të Serverit 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

Pas përfundimit të këtyre hapave, mund të punoni me ArgoCD Server përmes tastierës së internetit ArgoCD WebUI ose mjetit të linjës së komandës ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Asnjëherë nuk është vonë

"Treni është larguar" - kështu thonë ata për një situatë kur humbet mundësia për të bërë diçka. Në rastin e OpenShift, dëshira për të filluar menjëherë përdorimin e kësaj platforme të re të lezetshme shpesh krijon pikërisht këtë situatë me menaxhimin dhe mirëmbajtjen e rrugëve, vendosjeve dhe objekteve të tjera OpenShift. Por a është gjithmonë një shans i humbur plotësisht?

Vazhdimi i serisë së artikujve rreth GitOps, sot do t'ju tregojmë se si të transformoni një aplikacion të punuar me dorë dhe burimet e tij në një proces ku gjithçka menaxhohet nga mjetet GitOps. Për ta bërë këtë, së pari do të vendosim manualisht aplikacionin httpd. Pamja e ekranit më poshtë tregon se si krijojmë një hapësirë emri, vendosje dhe shërbim, dhe më pas e ekspozojmë këtë shërbim për të krijuar një rrugë.

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

Pra, ne kemi një aplikacion të punuar me dorë. Tani duhet të transferohet nën menaxhimin e GitOps pa humbje të disponueshmërisë. Me pak fjalë, ai bën këtë:

Krijoni një depo Git për kodin.
Ne eksportojmë objektet tona aktuale dhe i ngarkojmë ato në depo Git.
Përzgjedhja dhe vendosja e mjeteve GitOps.
Ne shtojmë depon tonë në këtë paketë veglash.
Ne e përcaktojmë aplikacionin në paketën tonë të veglave GitOps.
Ne kryejmë një provë të aplikacionit duke përdorur paketën e veglave GitOps.
Ne sinkronizojmë objektet duke përdorur paketën e veglave GitOps.
Aktivizo krasitjen dhe sinkronizimin automatik të objekteve.

Siç u përmend në të mëparshmen artikull, në GitOps ekziston një dhe vetëm një burim informacioni për të gjitha objektet në grup(et) Kubernetes - depoja e Git. Më pas, ne vazhdojmë nga premisa që organizata juaj tashmë përdor një depo Git. Mund të jetë publik ose privat, por duhet të jetë i aksesueshëm për grupimet Kubernetes. Ky mund të jetë i njëjti depo si për kodin e aplikacionit, ose një depo e veçantë e krijuar posaçërisht për vendosje. Rekomandohet të keni leje strikte në depo pasi sekretet, rrugët dhe gjëra të tjera të ndjeshme ndaj sigurisë do të ruhen atje.

Në shembullin tonë, ne do të krijojmë një depo të re publike në GitHub. Mund ta quani si të doni, ne përdorim emrin blogpost.

Nëse skedarët e objektit YAML nuk janë ruajtur në nivel lokal ose në Git, atëherë do t'ju duhet të përdorni binarët oc ose kubectl. Në pamjen e mëposhtme të ekranit, ne po kërkojmë YAML për hapësirën tonë të emrave, vendosjen, shërbimin dhe itinerarin tonë. Para kësaj, ne klonuam depon e sapokrijuar dhe cd në të.

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

Tani le të modifikojmë skedarin deployment.yaml për të hequr fushën që Argo CD nuk mund ta sinkronizojë.

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

Përveç kësaj, rruga duhet të ndryshohet. Fillimisht do të vendosim një variabël me shumë rreshta dhe më pas do të zëvendësojmë ingress: null me përmbajtjen e asaj ndryshore.

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

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

Pra, ne i kemi renditur skedarët, gjithçka që mbetet është t'i ruajmë në depon e Git. Pas së cilës kjo depo bëhet burimi i vetëm i informacionit dhe çdo ndryshim manual i objekteve duhet të ndalohet rreptësisht.

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

Më tej ne vazhdojmë nga fakti që ju keni vendosur tashmë ArgoCD (si ta bëni këtë - shih më parë post). Prandaj, ne do të shtojmë në CD Argo deponimin që krijuam, që përmban kodin e aplikacionit nga shembulli ynë. Vetëm sigurohuni që të specifikoni depon e saktë që keni krijuar më parë.

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

Tani le të krijojmë aplikacionin. Aplikacioni vendos vlerat në mënyrë që paketa e veglave GitOps të kuptojë se cilat depo dhe shtigje duhet të përdoren, cilat OpenShift nevojitet për të menaxhuar objektet, cila degë specifike e depove nevojitet dhe nëse burimet duhet të sinkronizohen automatikisht.

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

Pasi një aplikacion specifikohet në CD-në Argo, paketa e veglave fillon të kontrollojë objektet tashmë të vendosura kundrejt përkufizimeve në depo. Në shembullin tonë, sinkronizimi automatik dhe pastrimi janë çaktivizuar, kështu që elementët nuk ndryshojnë ende. Ju lutemi vini re se në ndërfaqen Argo CD aplikacioni ynë do të ketë statusin "Jashtë sinkronizuar" sepse nuk ka asnjë etiketë që ofron ArgoCD.
Kjo është arsyeja pse kur të fillojmë sinkronizimin pak më vonë, objektet nuk do të rishpërndahen.

Tani le të bëjmë një provë për t'u siguruar që nuk ka gabime në skedarët tanë.

argocd app sync simple-app --dry-run

Nëse nuk ka gabime, atëherë mund të vazhdoni me sinkronizimin.

argocd app sync simple-app

Pasi të ekzekutojmë komandën argocd get në aplikacionin tonë, duhet të shohim që statusi i aplikacionit ka ndryshuar në Healthy ose Synced. Kjo do të thotë që të gjitha burimet në depo Git tani korrespondojnë me ato burime që tashmë janë vendosur.

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

Tani mund të aktivizoni sinkronizimin automatik dhe pastrimin për të siguruar që asgjë nuk krijohet manualisht dhe se sa herë që një objekt krijohet ose përditësohet në depo, do të ndodhë një vendosje.

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

Pra, ne kemi sjellë me sukses një aplikacion nën kontrollin e GitOps që fillimisht nuk përdorte në asnjë mënyrë GitOps.

Burimi: www.habr.com

Hyrje në GitOps për OpenShift