🥇 Pambuka kanggo GitOps kanggo OpenShift

Dina iki kita bakal ngomong babagan prinsip lan model GitOps, uga carane model kasebut diimplementasikake ing platform OpenShift. Pandhuan interaktif babagan topik iki kasedhiya link.

Cekakipun, GitOps minangka seperangkat praktik kanggo nggunakake panjalukan tarik Git kanggo ngatur infrastruktur lan konfigurasi aplikasi. Repositori Git ing GitOps dianggep minangka sumber siji informasi babagan negara sistem, lan owah-owahan apa wae ing negara kasebut bisa dilacak lan bisa diaudit.

Gagasan nglacak owah-owahan ing GitOps ora anyar; pendekatan iki wis suwe digunakake meh universal nalika nggarap kode sumber aplikasi. GitOps mung ngleksanakake fitur sing padha (review, panjaluk tarik, tag, lan sapiturute) ing manajemen infrastruktur lan konfigurasi aplikasi lan menehi keuntungan sing padha kaya ing manajemen kode sumber.

Ora ana definisi akademisi utawa aturan sing disetujoni kanggo GitOps, mung sawetara prinsip sing ditindakake praktik iki:

Katrangan deklaratif sistem disimpen ing repositori Git (configs, monitoring, etc.).
Owah-owahan negara digawe liwat panjalukan narik.
Kahanan sistem sing mlaku disedhiyakake karo data ing repositori nggunakake panjaluk push Git.

Prinsip GitOps

Definisi sistem diterangake minangka kode sumber

Konfigurasi sistem dianggep minangka kode supaya bisa disimpen lan diversi kanthi otomatis ing repositori Git, sing dadi sumber siji bebener. Pendekatan iki nggampangake rollout lan rollback owah-owahan ing sistem.

Status lan konfigurasi sistem sing dikarepake disetel lan diversi ing Git

Kanthi nyimpen lan nggawe versi sistem sing dikarepake ing Git, kita bisa kanthi gampang nggulung lan ngowahi owah-owahan menyang sistem lan aplikasi. Kita uga bisa nggunakake mekanisme keamanan Git kanggo ngontrol kepemilikan kode lan verifikasi keasliane.

Owah-owahan konfigurasi bisa ditrapake kanthi otomatis liwat panjalukan narik

Nggunakake panjalukan tarik Git, kita bisa gampang ngontrol carane owah-owahan ditrapake kanggo konfigurasi ing repositori. Contone, padha bisa diwenehi kanggo anggota tim liyane kanggo review utawa mbukak liwat tes CI, etc.

Lan ing wektu sing padha, ora perlu nyebarake kekuwatan admin kiwa lan tengen. Kanggo nindakake owah-owahan konfigurasi, pangguna mung butuh ijin sing cocog ing repositori Git ing ngendi konfigurasi kasebut disimpen.

Ndandani masalah drift konfigurasi sing ora dikendhaleni

Sawise kahanan sistem sing dikarepake disimpen ing repositori Git, sing kudu ditindakake yaiku golek piranti lunak sing bakal mesthekake yen kahanan sistem saiki cocog karo kahanan sing dikarepake. Yen ora, piranti lunak iki kudu - gumantung saka setelan - bisa ngilangi bedo dhewe, utawa menehi kabar babagan drift konfigurasi.

Model GitOps kanggo OpenShift

On-Cluster Reconciler Sumber Daya

Miturut model iki, kluster duwe pengontrol sing tanggung jawab kanggo mbandhingake sumber daya Kubernetes (file YAML) ing gudang Git karo sumber daya nyata kluster kasebut. Yen bedo dideteksi, controller ngirim kabar lan bisa uga njupuk tindakan kanggo mbenerake bedo. Model GitOps iki digunakake ing Anthos Config Management lan Weaveworks Flux.

Rekonsiliasi Sumber Daya Eksternal (Push)

Model iki bisa dianggep minangka variasi saka sing sadurunge, nalika kita duwe siji utawa luwih pengontrol sing tanggung jawab kanggo nyinkronake sumber daya ing pasangan "Git repositori - Kubernetes cluster". Bentenipun ing kene yaiku saben kluster sing dikelola ora kudu duwe pengontrol dhewe. Git - pasangan kluster k8s asring ditetepake minangka CRDs (definisi sumber daya khusus), sing bisa njlèntrèhaké carane controller kudu nindakake sinkronisasi. Ing model iki, pengontrol mbandhingake gudang Git sing ditemtokake ing CRD karo sumber daya kluster Kubernetes, sing uga ditemtokake ing CRD, lan nindakake tumindak sing cocog adhedhasar asil perbandingan. Utamane, model GitOps iki digunakake ing ArgoCD.

GitOps ing platform OpenShift

Administrasi infrastruktur Kubernetes multi-cluster

Kanthi panyebaran Kubernetes lan popularitas strategi multi-cloud lan komputasi pinggiran, jumlah rata-rata kluster OpenShift saben pelanggan uga saya tambah.

Contone, nalika nggunakake komputasi pinggiran, kluster siji customer bisa disebarake ing atusan utawa malah ewu. Akibaté, dheweke kepeksa ngatur sawetara klompok OpenShift sing independen utawa terkoordinasi ing awan umum lan ing papan.

Ing kasus iki, akeh masalah sing kudu ditanggulangi, utamane:

Ngontrol manawa klompok kasebut ana ing kahanan sing padha (konfigurasi, pemantauan, panyimpenan, lsp.)
Gawe maneh (utawa mulihake) kluster adhedhasar negara sing dikenal.
Nggawe klompok anyar adhedhasar negara dikenal.
Muter owah-owahan menyang macem-macem kluster OpenShift.
Muter maneh owah-owahan ing pirang-pirang kluster OpenShift.
Link konfigurasi templated kanggo lingkungan beda.

Konfigurasi Aplikasi

Sajrone siklus urip, aplikasi asring ngliwati rantai kluster (dev, panggung, lsp) sadurunge rampung ing kluster produksi. Kajaba iku, amarga syarat kasedhiyan lan skalabilitas, para pelanggan asring nyebarake aplikasi ing pirang-pirang kluster ing papan utawa sawetara wilayah ing platform awan umum.

Ing kasus iki, tugas ing ngisor iki kudu ditanggulangi:

Mesthekake gerakan aplikasi (biner, configs, etc.) antarane klompok (dev, stage, etc.).
Muter owah-owahan kanggo aplikasi (biner, configs, etc.) ing sawetara kluster OpenShift.
Muter maneh owah-owahan kanggo aplikasi menyang negara dikenal sadurunge.

Kasus Gunakake OpenShift GitOps

1. Nglamar owah-owahan saka repositori Git

Administrator kluster bisa nyimpen konfigurasi kluster OpenShift ing repositori Git lan kanthi otomatis ngetrapake kanggo nggawe kluster anyar kanthi gampang lan nggawa menyang negara sing padha karo negara sing disimpen ing gudang Git.

2. Sinkronisasi karo Manager Rahasia

Administrator uga bakal entuk manfaat saka kemampuan kanggo nyinkronake obyek rahasia OpenShift karo piranti lunak sing cocog kaya Vault supaya bisa ngatur nggunakake alat sing digawe khusus kanggo iki.

3. Kontrol konfigurasi drift

Admin mung bakal seneng yen OpenShift GitOps dhewe ngenali lan ngelingake babagan bedo antarane konfigurasi nyata lan sing ditemtokake ing gudang, supaya bisa cepet nanggapi drift.

4. Kabar babagan drift konfigurasi

Padha migunani ing kasus nalika administrator pengin cepet sinau babagan kasus konfigurasi drift supaya cepet njupuk ngukur cocok ing dhewe.

5. Sinkronisasi manual konfigurasi nalika drifting

Ngidini admin nyinkronake kluster OpenShift karo repositori Git yen ana konfigurasi drift, supaya kluster kasebut cepet bali menyang negara sing wis dingerteni sadurunge.

6.Sinkronisasi otomatis konfigurasi nalika drifting

Administrator uga bisa ngatur kluster OpenShift kanggo nyinkronake kanthi otomatis karo gudang nalika drift dideteksi, supaya konfigurasi kluster tansah cocog karo konfigurasi ing Git.

7. Sawetara klompok - siji gudang

Administrator bisa nyimpen konfigurasi sawetara kluster OpenShift sing beda-beda ing siji gudang Git lan kanthi selektif ngetrapake yen perlu.

8. Hierarki konfigurasi cluster (warisan)

Admin bisa nyetel hirarki konfigurasi cluster ing gudang (tataran, prod, portofolio app, etc. karo warisan). Ing tembung liyane, bisa nemtokake manawa konfigurasi kudu ditrapake ing siji utawa luwih klompok.

Contone, yen administrator nyetel hierarki "Kluster produksi (prod) → Kluster Sistem X → Kluster produksi sistem X" ing gudang Git, banjur kombinasi konfigurasi ing ngisor iki ditrapake kanggo kluster produksi sistem X:

Konfigurasi umum kanggo kabeh klompok produksi.
Konfigurasi kanggo kluster Sistem X.
Konfigurasi kanggo kluster produksi sistem X.

9. Cithakan lan konfigurasi overrides

Administrator bisa ngatasi set konfigurasi sing diwarisake lan nilai-nilai kasebut, contone, kanggo nyetel konfigurasi kanggo klompok tartamtu sing bakal ditrapake.

10. Selektif kalebu lan ora kalebu kanggo konfigurasi, konfigurasi aplikasi

Administrator bisa nyetel kahanan kanggo aplikasi utawa non-aplikasi konfigurasi tartamtu kanggo klompok karo ciri tartamtu.

11. Dhukungan Cithakan

Pangembang bakal entuk manfaat saka kemampuan kanggo milih carane sumber daya aplikasi bakal ditetepake (Helm Chart, Kubernetes yaml murni, etc.) kanggo nggunakake format sing paling cocok kanggo saben aplikasi tartamtu.

Alat GitOps ing platform OpenShift

ArgoCD

ArgoCD ngetrapake model Rekonsiliasi Sumber Daya Eksternal lan nawakake UI terpusat kanggo ngatur hubungan siji-kanggo-akeh antarane klompok lan repositori Git. Kerugian program iki kalebu ora bisa ngatur aplikasi nalika ArgoCD ora bisa digunakake.

Situs web resmi

mili

Flux ngetrapake model On-Cluster Resource Reconcile lan, minangka asil, ora ana manajemen terpusat saka repositori definisi, sing minangka titik lemah. Ing sisih liya, amarga kekurangan sentralisasi, kemampuan kanggo ngatur aplikasi tetep sanajan siji kluster gagal.

Situs web resmi

Nginstal ArgoCD ing OpenShift

ArgoCD nawakake antarmuka baris perintah lan konsol web sing apik banget, mula kita ora bakal nutupi Flux lan alternatif liyane ing kene.

Kanggo masang ArgoCD ing platform OpenShift 4, tindakake langkah iki minangka administrator kluster:

Masang komponen ArgoCD ing platform 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}')

Peningkatan Server ArgoCD supaya bisa dideleng dening 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

Nggunakake 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

Ngganti sandhi admin Server 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

Sawise ngrampungake langkah-langkah kasebut, sampeyan bisa nggarap Server ArgoCD liwat konsol web ArgoCD WebUI utawa alat baris perintah ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Ora Ana Kasep

"Sepur wis lunga" - iki sing diomongake babagan kahanan nalika kesempatan kanggo nindakake apa wae ora kejawab. Ing kasus OpenShift, kepinginan kanggo langsung nggunakake platform anyar sing keren iki asring nggawe kahanan iki kanthi manajemen lan pangopènan rute, penyebaran lan obyek OpenShift liyane. Nanging kasempatan tansah rampung ora kejawab?

Terusake seri artikel babagan GitOps, dina iki kita bakal nuduhake sampeyan carane ngowahi aplikasi gawean tangan lan sumber daya dadi proses sing kabeh diatur dening alat GitOps. Kanggo nindakake iki, kita bakal nggunakake aplikasi httpd kanthi manual. Gambar ing ngisor iki nuduhake carane nggawe namespace, penyebaran lan layanan, banjur mbukak layanan iki kanggo nggawe 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

Dadi, kita duwe aplikasi buatan tangan. Saiki kudu ditransfer ing manajemen GitOps tanpa kelangan kasedhiyan. Ing cendhak, iku nindakake iki:

Nggawe repositori Git kanggo kode kasebut.
Kita ngekspor obyek saiki lan upload menyang repositori Git.
Milih lan masang alat GitOps.
Kita nambah repositori kita menyang toolkit iki.
Kita nemtokake aplikasi ing toolkit GitOps kita.
Kita nindakake uji coba aplikasi nggunakake toolkit GitOps.
Kita nyinkronake obyek nggunakake toolkit GitOps.
Aktifake pruning lan sinkronisasi otomatis obyek.

Kaya sing wis kasebut ing sadurunge artikel, ing GitOps ana siji lan mung siji sumber informasi babagan kabeh obyek ing cluster (s) Kubernetes - gudang Git. Sabanjure, kita nerusake saka premis manawa organisasi sampeyan wis nggunakake repositori Git. Bisa dadi umum utawa pribadi, nanging kudu bisa diakses kluster Kubernetes. Iki bisa dadi gudang sing padha karo kode aplikasi, utawa gudang kapisah sing digawe khusus kanggo panyebaran. Disaranake duwe ijin sing ketat ing gudang amarga rahasia, rute, lan barang sing sensitif keamanan liyane bakal disimpen ing kana.

Ing conto kita, kita bakal nggawe repositori umum anyar ing GitHub. Sampeyan bisa nelpon apa wae sing disenengi, kita nggunakake jeneng blogpost.

Yen file obyek YAML ora disimpen sacara lokal utawa ing Git, sampeyan kudu nggunakake binari oc utawa kubectl. Ing gambar ing ngisor iki, kita njaluk YAML kanggo ruang jeneng, panyebaran, layanan lan rute. Sadurunge iki, kita kloning repositori sing mentas digawe lan cd menyang.

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

Saiki ayo ngowahi file deployment.yaml kanggo mbusak kolom sing ora bisa diselarasake karo CD Argo.

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

Kajaba iku, rute kasebut kudu diganti. Pisanan kita bakal nyetel variabel multiline banjur ngganti ingress: null karo isi variabel kasebut.

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

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

Dadi, kita wis ngurutake file kasebut, sing isih ana yaiku nyimpen menyang repositori Git. Sawise gudang iki dadi siji-sijine sumber informasi, lan owah-owahan manual kanggo obyek kudu dilarang banget.

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

Luwih kita nerusake saka kasunyatan manawa sampeyan wis masang ArgoCD (carane nindakake iki - deleng sadurunge kirim). Mulane, kita bakal nambah menyang CD Argo repositori sing digawe, ngemot kode aplikasi saka conto kita. Priksa manawa sampeyan nemtokake repositori sing tepat sing digawe sadurunge.

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

Saiki ayo nggawe aplikasi kasebut. Aplikasi kasebut nyetel nilai supaya toolkit GitOps mangertos repositori lan path sing digunakake, OpenShift dibutuhake kanggo ngatur obyek, cabang repositori tartamtu sing dibutuhake, lan manawa sumber daya kudu disinkronake kanthi otomatis.

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

Sawise aplikasi kasebut ing CD Argo, toolkit wiwit mriksa obyek sing wis disebarake marang definisi ing gudang. Ing conto kita, sinkronisasi otomatis lan ngresiki dipateni, mula unsur kasebut durung owah. Elinga yen ing antarmuka CD Argo, aplikasi kita bakal duwe status "Out of Sync" amarga ora ana label sing diwenehake ArgoCD.
Iki kok nalika kita miwiti sinkronisasi sethitik mengko, obyek ora bakal redeployed.

Saiki ayo nglakoni uji coba kanggo mesthekake yen ora ana kesalahan ing file kita.

argocd app sync simple-app --dry-run

Yen ora ana kesalahan, sampeyan bisa nerusake menyang sinkronisasi.

argocd app sync simple-app

Sawise mbukak printah argocd njaluk ing aplikasi kita, kita kudu ndeleng manawa status aplikasi wis diganti dadi Sehat utawa Disinkronake. Iki tegese kabeh sumber daya ing repositori Git saiki cocog karo sumber daya sing wis disebarake.

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

Saiki sampeyan bisa ngaktifake sinkronisasi otomatis lan ngresiki kanggo mesthekake yen ora ana sing digawe kanthi manual lan saben obyek digawe utawa dianyari menyang repositori, penyebaran bakal kedadeyan.

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

Dadi, kita wis sukses nggawa aplikasi ing kontrol GitOps sing wiwitane ora nggunakake GitOps kanthi cara apa wae.

Source: www.habr.com

Pambuka kanggo GitOps kanggo OpenShift