Sot do të flasim për parimet dhe modelet e GitOps, si dhe se si këto modele realizohen në platformën OpenShift. Një udhëzues interaktiv mbi këtë temë është në dispozicion. .
Nëse flasim shkurtimisht, GitOps është një grup praktikash për të përdorur pull-requestët në Git për të menaxhuar konfigurimet e infrastrukturës dhe aplikacioneve. Repo-Git në kuadër të GitOps shihet si një burim i vetëm informacioni mbi gjendjen e sistemit, dhe çdo ndryshim i kësaj gjendjeje ndiqet plotësisht dhe mund të auditohet.
Ideja e ndjekjes së ndryshimeve në GitOps nuk është aspak e re; një qasje e tillë është përdorur prej kohësh dhe gjerësisht në punën me kodin burimor të aplikacioneve. GitOps thjesht zbaton funksione të ngjashme (kontrolli i rishikimit, pull-requestet, etiketat, etj.) kur menaxhon konfigurimet e infrastrukturës dhe aplikacioneve, duke ofruar përfitime të ngjashme si në menaxhimin e kodit burimor.
Për GitOps nuk ka një përkufizim akademik ose një set të miratuar rregullash, vetëm një grup parimesh mbi të cilat ndërtetë kjo praktikë:
- Përshkrimi deklarativ i sistemit ruhet në depon Git (konfigurot, monitorimi etj).
- Ndryshimet e gjendjes realizohen përmes kërkesave për tërheqje.
- Gjakë, sistemi i punës përputhet me të dhënat në depon përmes kërkesave push Git.
Parimet GitOps
- Përkufizimet e sistemeve përshkruhen si kod burimor.
Konfigurimi i sistemeve konsiderohet si kod, prandaj mund të ruhet dhe të versionohet automatikisht në depon Git, e cila shërben si burimi i vetëm i së vërtetës. Ky qasje lejon që të aplikojmë lehtësisht (rollout) dhe të anulojmë (rollback) ndryshime në sisteme.
- Gjendja e dëshiruar dhe konfigurimi i sistemeve përcaktohen dhe versionohen në Git.
Duke ruajtur dhe versionuar në Git gjendjen e dëshiruar të sistemeve, ne kemi mundësinë të aplikojmë dhe të anulojmë lehtësisht ndryshime në sisteme dhe aplikacione. Po ashtu, mund të përdorim mekanizmat e sigurisë të Git për të kontrolluar pronësinë e kodit dhe për të konfirmuar autenticitetin e tij.
- Ndryshimet në konfigurimet mund të aplikohen automatikisht përmes kërkesave për tërheqje.
Duke përdorim pull-request-et e Git-it, ne mund të menaxhojmë lehtësisht se si aplikohet ndryshimet në konfigurimet në depo. Për shembull, ato mund t'i dorëzohen për shqyrtim otros anëtarëve të ekipit ose të kalojnë përmes testeve CI.
Dhe nuk është e nevojshme të ndahen privilegjet administrative pa kriter. Për të kryer commit të ndryshimeve në konfigurim, përdoruesit mjaftojnë me autorizimet përkatëse në depo Git ku ruhen këto konfigurime.
- Zgjidhja e problemit të driftit të pakontrolluar të konfigurimeve
Kur gjendja e dëshiruar e sistemit ruhet në depo Git, ne vetëm duhet të gjejmë softin që do të monitoronte nëse gjendja aktuale e sistemit përputhet me gjendjen e saj të dëshiruar. Nëse jo, ky soft duhet - në varësi të cilësimeve - ose të zgjidhë vetë mospërputhshmërinë, ose të na njoftojë për driftin e konfigurimeve.
Modelet GitOps për OpenShift
On-Cluster Resource Reconciller
Sipas këtij modeli, në klaster ka një kontrolues që është përgjegjës për krahasimin e burimeve Kubernetes (skedarëve YAML) në depo Git me burimet reale të klasterit. Kur identifikohen disushtime, kontroluesi dërgon njoftime dhe, ndoshta, merr masa për të eliminuar moskonformitetet. Ky model GitOps përdoret në Anthos Config Management dhe Weaveworks Flux.
External Resource Reconciler (Push)
Ky model mund tĂ« konsiderohet si njĂ« lloj i mĂ«parshĂ«m, kur kemi njĂ« ose mĂ« shumĂ« kontrolues qĂ« janĂ« pĂ«rgjegjĂ«s pĂ«r sinkronizimin e burimeve nĂ« çiftet "depo Git â klaster Kubernetes". Dallimi kĂ«tu Ă«shtĂ« se nĂ« çdo klaster tĂ« menaxhuar nuk Ă«shtĂ« e nevojshme tĂ« ketĂ« kontrollues tĂ« veçantĂ«. Ăiftet "Git â klaster k8s" shpesh pĂ«rcaktohen si pĂ«rshkrime CRD (definisi burimesh tĂ« kĂ«rkuara), ku mund tĂ« pĂ«rshkruhet si duhet tĂ« kryejĂ« sinkronizimi. NĂ« kĂ«tĂ« model, kontroluesit krahasojnĂ« depo Git, tĂ« pĂ«rcaktuar nĂ« CRD, me burimet e klasterit Kubernetes, tĂ« cilat janĂ« gjithashtu tĂ« pĂ«rcaktuara nĂ« CRD, dhe kryejnĂ« veprime pĂ«rkatĂ«se sipas rezultateve tĂ« krahasimit. NĂ« veçanti, ky model GitOps pĂ«rdoret nĂ« ArgoCD.
GitOps në platformën OpenShift
Administrimi i infrastrukturës multiklastrale Kubernetes
Me përhapjen e Kubernetes dhe rritjen e popullaritetit të strategjive multicloud dhe llogaritjes periferike (edge computing), rritet gjithashtu numri mesatar i klastereve OpenShift për çdo klient.
Për shembull, duke përdorur llogaritjen periferike, klasterët e një klienti mund të vendosen me qindra e madje mijëra. Si rezultat, ata janë të detyruar të menaxhojnë disa klasterë të pavarur ose të harmonizuar OpenShift në cloud publik dhe në ambientin on-premise.
Këtu duhet të zgjidhen shumë probleme, veçanërisht:
- Kontrollimi që klasterët të jenë në gjendje identike (konfigurat, monitorimi, ruajtjet etj.)
- Rindërtimi (ose rikthimi) i klasterëve nga një gjendje e njohur.
- Krijimi i klasterëve të rinj nga një gjendje e njohur.
- Aplikimi i ndryshimeve në disa klasterë OpenShift.
- Rivendosja e ndryshimeve në disa klasterë OpenShift.
- Përputhja e konfigurimeve të template me mjedise të ndryshme.
Konfigurimet e aplikacioneve
Gjatë ciklit të tij të jetës, aplikacionet shpesh kalojnë përmes një zinxhiri klasterësh (dev, stage, etj.), para se të arrijnë në klasterin e prodhimit. Për më tepër, për shkak të kërkesave për disponueshmëri dhe shkallëzueshmëri, klientët shpesh vendosin aplikacione në disa klasterë on-premise ose në disa rajone të një platforme publike të cloud-it.
Në këtë proces përballen me detyrat e mëposhtme:
- Të sigurojnë lëvizjen e aplikacioneve (binarë, konfigurime, etj.) midis klasterëve (dev, stage, etj.).
- Të implementojnë ndryshime në aplikacione (binarë, konfigurime, etj.) në disa klasterë OpenShift.
- Të kthejnë ndryshimet në aplikacione deri në gjendjen e mëparshme të njohur.
Skemat e përdorimit të OpenShift GitOps
1. Aplikimi i ndryshimeve nga repo Git
AdministratorĂ«t e klasterĂ«ve mund tĂ« ruajnĂ« konfigurimet e klasterit OpenShift nĂ« njĂ« repo Git dhe tâi aplikojnĂ« automatikisht ato, pĂ«r tĂ« krijuar klasterĂ« tĂ« rinj pa mundim dhe pĂ«r tâi sjellĂ« ata nĂ« njĂ« gjendje tĂ« njĂ«jtĂ« me gjendjen e njohur qĂ« ruhet nĂ« repo Git.
2. Synhronizimi me Menaxherin e Sekreteve
Admini gjithashtu do të ketë nevojë për mundësinë për të sinkronizuar objektet sekrete të OpenShift me software të tillë si Vault, për t'i menaxhuar ato me mjete të krijuara posaçërisht për këtë qëllim.
3. Kontrolli i driftit të konfigurimeve
Admini do të jetë në përputhje nëse OpenShift GitOps identifikon dhe njofton për shpërhershmërinë midis konfigurimeve reale dhe atyre që janë caktuar në depo, për t'u përgjigjur shpejt ndaj driftit.
4. Njoftimet për driftin e konfigurimeve
Do të jenë të dobishme kur admini dëshiron të informohet shpejt për rastet e driftit të konfigurimeve, për të marrë masa të përkatshme vetë.
5. Sinkronizimi manual i konfigurimeve gjatë driftit
Lejon adminin të sinkronizojë klastrin OpenShift me depo Git në rast driftit të konfigurimeve, për të kthyer shpejt klastrin në një gjendje të njohur të mëparshme.
6. Autositësimi i konfigurimeve gjatë driftit
Admini gjithashtu mund të konfiguroni klastrin OpenShift për të sinkronizuar automatikisht me depo të zbuluar gjatë driftit, në mënyrë që konfigurimi i klastri të përputhet gjithmonë me konfigurimet në Git.
7. Disa klastere â njĂ« depo
Administratori mund të ruajë në një depo Git konfigurime nga disa klastere të ndryshme OpenShift dhe t'i përdorë ato sipas nevojës.
8. Hierarkia e konfigurimeve të klasterëve (trashëgimia)
Administratori mund tĂ« vendosĂ« njĂ« hierarki tĂ« konfigurimeve tĂ« klasterĂ«ve nĂ« depo (stage, prod, portofoli i aplikacioneve, etj. me trashĂ«gimi). Me fjalĂ« tĂ« tjera, ai mund tĂ« pĂ«rcaktojĂ« se si duhet tĂ« aplikohen konfigurimet â nĂ« njĂ« ose nĂ« disa klasterĂ«.
PĂ«r shembull, nĂ«se administratori vendos nĂ« depo Git hierarkinĂ« "Klastere prodhimi (prod) â Klasteret e sistemit X â Klasteret prodhimi tĂ« sistemit X", atĂ«herĂ« pĂ«r klasteret prodhimi tĂ« sistemit X aplikohet kombinimi i kĂ«tyre konfigurimeve:
- Konfigurimet e përbashkëta për të gjitha klasteret prodhimi.
- Konfigurimet për klasterin e sistemit X.
- Konfigurimet për klasterin prodhimi të sistemit X.
9. Shabllonat dhe ndryshimi i konfigurimeve
Administratori mund të ndryshojë një grup konfigurimesh të trashëguara dhe vlerave të tyre, për shembull, për ta rregulluar më hollësisht konfigurimin për klasteret specifike ku ato do të aplikohen.
10. Includet dhe exclude't selektive për konfigurimet, konfigurimet e aplikacioneve
Administratori mund të vendosë kushte për aplikimin ose mosaplikimin e konfiguracioneve të caktuara në klastera me karakteristika të caktuara.
11. Mbështetje për shabllone
Zhvilluesit do të kenë nevojë për mundësinë të zgjedhin se si do të përcaktohen burimet e aplikacionit (Helm Chart, yaml i pastër Kubernetes, etj.), për të përdorur formatin më të përshtatshëm për çdo aplikacion të veçantë.
Mjetet GitOps në platformën OpenShift
ArgoCD
ArgoCD implementon modelin External Resource Reconcile dhe ofron një UI të centralizuar për orkestrimin e marrëdhënieve midis klasterave dhe depozitave Git në një skemë "një në shumë". Një disavantazh i kësaj programi është pamundësia për të menaxhuar aplikacionet kur ArgoCD nuk funksionon.
Flux
Flux implementon modelin On-Cluster Resource Reconcile, dhe, si pasojë, nuk ka menaxhim të centralizuar për depozitën e përcaktimeve, që është një pikë e dobët. Nga ana tjetër, pikërisht për shkak të mungesës së centralizimit, mundësia për të menaxhuar aplikacionet ruhet edhe në rastin e dështimit të një klasteri.
Instalimi i ArgoCD në OpenShift
ArgoCD ofron një ndërfaqe të shkëlqyer të komandës dhe një konsolë web, kështu që këtu nuk do të shqyrtojmë Flux dhe alternativa të tjera.
Për të implementuar ArgoCD në platformën OpenShift 4, ndiqni hapat e mëposhtëm si administrator i klasterit:
Implementimi i komponenteve 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}')Modifikimi i ArgoCD Server për ta bërë të dukshëm për 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=RedirectImplementimi i 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/argocdNdryshimi i fjalëkalimit të administratorit të ArgoCD Server
# 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 konsolës web ArgoCD WebUI ose mjetit të komandës ArgoCD Cli.
GitOps â nuk Ă«shtĂ« kurrĂ« vonĂ«
"Treni ka ikur" â kĂ«shtu thonĂ« pĂ«r njĂ« situatĂ« kur njĂ« mundĂ«si pĂ«r tĂ« bĂ«rĂ« diçka Ă«shtĂ« humbur. NĂ« rastin e OpenShift, dĂ«shira pĂ«r tĂ« filluar menjĂ«herĂ« pĂ«rdorimin e kĂ«saj platforme tĂ« re dhe tĂ« shkĂ«lqyer shpesh krijon njĂ« situatĂ« tĂ« tillĂ« me menaxhimin dhe mirĂ«mbajtjen e ruteve, desplejimeve dhe objekteve tĂ« tjera OpenShift. Por a Ă«shtĂ« gjithmonĂ« rasti qĂ« mundĂ«sia Ă«shtĂ« humbur pĂ«rfundimisht?
Vazhdimi i serisĂ« sĂ« artikujve pĂ«r , sot jemi duke treguar se si tĂ« transformojmĂ« njĂ« aplikacion tĂ« krijuar manualisht dhe burimet e tij nĂ« njĂ« proces, ku gjithçka menaxhohet nga mjeti GitOps. PĂ«r kĂ«tĂ«, fillimisht do tĂ« nisim aplikacionin httpd me duar. NĂ« ekranin mĂ« poshtĂ« tregohet se si ne krijojmĂ« njĂ« hapĂ«sirĂ« emri, njĂ« deployÂment dhe njĂ« shĂ«rbim, dhe mĂ« pas e bĂ«jmĂ« expose pĂ«r 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-appPra, tani kemi një aplikacion të krijuar manualisht. Tani duhet ta kalojmë nën menaxhimin e GitOps pa humbur aksesin. Në përmbledhje, kjo bëhet si më poshtë:
- Krijojmë një depo Git për kodin.
- Eksportojmë objektet tona aktuale dhe i ngarkojmë ato në depo Git.
- Zgjedhim dhe nisemi me mjetin GitOps.
- Shtojmë në këtë mjet depo tonë.
- Definojmë aplikacionin në mjetin tonë GitOps.
- Kryejmë një provë të aplikacionit duke përdorur mjetin GitOps.
- Sinkronizojmë objektet me mjetin GitOps.
- Aktivizojmë pastrimin (pruning) dhe autosingronizimin e objekteve.
Siç Ă«shtĂ« thĂ«nĂ« mĂ« parĂ«, nĂ« GitOps ka njĂ« dhe vetĂ«m njĂ« burim informacioni pĂ«r tĂ« gjitha objektet nĂ« klasterin (t) Kubernetes â tregu Git. Ne e trajtojmĂ« si premisĂ« qĂ« nĂ« organizatĂ«n tuaj tashmĂ« po pĂ«rdoret njĂ« depo Git. Ajo mund tĂ« jetĂ« publike ose private, por patjetĂ«r duhet tĂ« jetĂ« e aksesueshme nga klasterĂ«t Kubernetes. Kjo mund tĂ« jetĂ« e njĂ«jta depo si pĂ«r kodin e aplikacioneve, ose njĂ« depo e veçantĂ« e krijuar veçmas pĂ«r shpĂ«rndarjet. NĂ« depo rekomandohet tĂ« ketĂ« leje tĂ« rrepta, pasi aty do tĂ« ruhen objektet sekrete, rrugĂ«t dhe gjĂ«ra tĂ« tjera ndjeshme pĂ«r sigurinĂ«.
Në shembullin tonë do të krijojmë një depo të re publike në GitHub. E bëjmë emrin sipas dëshirës, ne do të përdorim emrin blogpost.
Nëse skedarët YAML të objekteve nuk janë ruajtur lokal ose në Git, do të duhet të përdorim binarët oc ose kubectl. Në screenshot-in më poshtë po kërkojmë YAML për hapësirën tonë të emrave, shpërndarjen, shërbimin dhe rrugën. Para kësaj, ne klonuam depo-n e sapo krijuar dhe kaluam në të me komandën 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.yamlTani do ta ndryshojmë skedarin deployment.yaml, për të hequr fushën që Argo CD nuk mund ta sinkronizojë.
sed -i '/sgeneration: .*/d' deployment.yamlPërveç kësaj, duhet të ndryshojmë rrugën. Së pari, do të vendosim një variabël me shumë rreshta dhe pastaj do të zëvendësojmë ingress: null me përmbajtjen e kësaj variabël.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlTani që u morëm me skedarët, mbetet vetëm t'i ruajmë ato në një depo Git. Pas kësaj, ky depo bëhet burimi i vetëm i informacionit, dhe çdo ndryshim manual në objekte duhet të ndalohet rreptësisht.
git commit -am 'initial commit of objects'
git push origin masterMĂ« pas, ne supozojmĂ« se ArgoCD Ă«shtĂ« tashmĂ« i deploy-uar (si ta bĂ«ni kĂ«tĂ« â shihni mĂ« herĂ«t) ). Prandaj, do tĂ« shtojmĂ« nĂ« Argo CD depo-n qĂ« krijuam, qĂ« pĂ«rmban kodin e aplikacionit nga shembulli ynĂ«. VetĂ«m sigurohuni qĂ« tĂ« tregoni pikĂ«risht depo-n qĂ« krijuat mĂ« parĂ«.
argocd repo add https://github.com/cooktheryan/blogpostTani krijojmë një aplikacion. Aplikacioni vendos vlera, për të kuptuar mjetet GitOps se cilin depozitë dhe rrugë të përdorin, cilin OpenShift është e nevojshme për të menaxhuar objektet, si dhe cila degë specifike e depozitës kërkohet dhe nëse burimet duhet të janë në sinkronizim automatik.
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 aplikacioni është vendosur në Argo CD, ky mjet fillon të kontrollojë objektet e shpërndara për përputhshmërinë me definicionet në depozitë. Në shembullin tonë, sinkronizimi automatik dhe pastrimi janë të çaktivizuara, kështu që elementet nuk ndryshojnë për momentin. Vini re që në ndërfaqen e Argo CD aplikacioni ynë do të ketë statusin "Out of Sync" (Jo në sinkronizim), pasi nuk ka etiketë që vendos ArgoCD.
Kjo është arsyeja pse, kur më vonë të fillojmë sinkronizimin, rishpërndarja e objekteve nuk do të kryhet.
Tani do të bëjmë një provë për të siguruar që nuk ka gabime në skedarët tanë.
argocd app sync simple-app --dry-runNëse nuk ka gabime, atëherë mund të vazhdojmë me sinkronizimin.
argocd app sync simple-appPas pastrimit të komandës argocd get mbi aplikacionin tonë, ne duhet të shohim që statusi i aplikacionit të ketë ndryshuar në Healthy (I Shëndetshëm) ose Synced (Të Sinkronizuar). Kjo do të thotë se të gjitha burimet në depozitën Git tani përputhen me burimet që janë tashmë të implementuara.
argocd app get simple-app
Emri: simple-app
Projekti: default
Serveri: https://kubernetes.default.svc
Hapësira: simple-app
URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo: https://github.com/cooktheryan/blogpost.git
Objektivi: master
Rruga: .
Politika e Sinkronizimit: <asnjë>
Statusi i Sinkronizimit: Sinkronizuar me master (60e1678)
Statusi i Shëndetit: I Shëndetshëm
... Tani është koha të aktivizoni sinkronizimin automatik dhe pastrimin, për të garantuar që asgjë të mos krijohet manualisht dhe që çdo herë që objekti krijohet ose përditësohet në depozita, të realizohet implementimi.
argocd app set simple-app --sync-policy automated --auto-prune Pra, ne kemi kaluar me sukses në menaxhimin e aplikacionit në GitOps, që fillimisht nuk kishte përdorur aspiratat GitOps.
Burimi: habr.com
