Bugun biz GitOps tamoyillari va modellari, shuningdek, ushbu modellar OpenShift platformasida qanday amalga oshirilishi haqida gaplashamiz. Ushbu mavzu bo'yicha interaktiv qo'llanma mavjud .
Xulosa qilib aytganda, GitOps infratuzilma va dastur konfiguratsiyalarini boshqarish uchun Git pull so'rovlaridan foydalanish bo'yicha amaliyotlar to'plamidir. GitOps-dagi Git ombori tizim holati haqida yagona ma'lumot manbai sifatida ko'rib chiqiladi va bu holatdagi har qanday o'zgarishlar to'liq kuzatilishi va tekshirilishi mumkin.
GitOps-da o'zgarishlarni kuzatish g'oyasi yangi emas, bu yondashuv dasturning manba kodi bilan ishlashda uzoq vaqtdan beri deyarli hamma joyda qo'llanilgan. GitOps infratuzilma va ilovalar konfiguratsiyasini boshqarishda oddiygina o'xshash xususiyatlarni (ko'rib chiqishlar, tortish so'rovlari, teglar va boshqalar) amalga oshiradi va manba kodini boshqarish misolida bo'lgani kabi o'xshash imtiyozlarni beradi.
GitOps uchun akademik ta'rif yoki tasdiqlangan qoidalar to'plami yo'q, faqat ushbu amaliyot asosida qurilgan tamoyillar to'plami:
- Tizimning deklarativ tavsifi Git omborida saqlanadi (konfiguratsiyalar, monitoring va boshqalar).
- Holatga o'zgartirishlar tortish so'rovlari orqali amalga oshiriladi.
- Ishlayotgan tizimlarning holati Git push so'rovlari yordamida ombordagi ma'lumotlarga moslashtiriladi.
GitOps tamoyillari
- Tizim ta'riflari manba kodi sifatida tavsiflanadi
Tizim konfiguratsiyasi kod sifatida ko'rib chiqiladi, shuning uchun u Git omborida saqlanishi va avtomatik ravishda versiyalanishi mumkin, bu haqiqatning yagona manbai bo'lib xizmat qiladi. Ushbu yondashuv tizimlardagi o'zgarishlarni ishga tushirish va qaytarishni osonlashtiradi.
- Tizimlarning kerakli holati va konfiguratsiyasi Git-da o'rnatiladi va versiyalanadi
Git-da tizimlarning kerakli holatini saqlash va versiyalash orqali biz tizimlar va ilovalardagi o'zgarishlarni osonlikcha chiqarib tashlashimiz va qaytarishimiz mumkin. Kod egaligini nazorat qilish va uning haqiqiyligini tekshirish uchun Gitning xavfsizlik mexanizmlaridan ham foydalanishimiz mumkin.
- Konfiguratsiya o'zgarishlari tortish so'rovlari orqali avtomatik ravishda qo'llanilishi mumkin
Git pull so'rovlaridan foydalanib, biz ombordagi konfiguratsiyalarga qanday o'zgarishlar qo'llanilishini osongina boshqarishimiz mumkin. Masalan, ular boshqa jamoa a'zolariga ko'rib chiqish yoki CI testlaridan o'tish uchun berilishi mumkin va hokazo.
Va shu bilan birga, administrator vakolatlarini chapga va o'ngga taqsimlashning hojati yo'q. Konfiguratsiya o'zgarishlarini amalga oshirish uchun foydalanuvchilarga faqat ushbu konfiguratsiyalar saqlanadigan Git omborida tegishli ruxsatlar kerak bo'ladi.
- Konfiguratsiyalarning nazoratsiz siljishi muammosini hal qilish
Tizimning kerakli holati Git omborida saqlanganidan so'ng, biz qilishimiz kerak bo'lgan narsa tizimning joriy holati uning kerakli holatiga mos kelishini ta'minlaydigan dasturiy ta'minotni topishdir. Agar bunday bo'lmasa, ushbu dastur sozlamalarga qarab yoki o'z-o'zidan nomuvofiqlikni bartaraf qilishi yoki konfiguratsiya o'zgarishi haqida bizga xabar berishi kerak.
OpenShift uchun GitOps modellari
Klasterdagi resurslarni moslashtiruvchi
Ushbu modelga ko'ra, klasterda Git omboridagi Kubernetes resurslarini (YAML fayllari) klasterning haqiqiy resurslari bilan solishtirish uchun mas'ul bo'lgan kontroller mavjud. Agar nomuvofiqliklar aniqlansa, boshqaruvchi bildirishnomalarni yuboradi va ehtimol nomuvofiqliklarni tuzatish uchun choralar ko'radi. Ushbu GitOps modeli Anthos Config Management va Weaveworks Flux-da qo'llaniladi.
Tashqi resurslarni moslashtiruvchi (Push)
"Git repository - Kubernetes klasteri" juftliklarida resurslarni sinxronlashtirish uchun mas'ul bo'lgan bir yoki bir nechta kontrollerlar mavjud bo'lganda, ushbu modelni avvalgisining o'zgarishi deb hisoblash mumkin. Bu erda farq shundaki, har bir boshqariladigan klaster o'zining alohida boshqaruvchisiga ega bo'lishi shart emas. Git - k8s klaster juftlari ko'pincha CRD (maxsus manba ta'riflari) sifatida aniqlanadi, ular boshqaruvchi sinxronizatsiyani qanday amalga oshirishi kerakligini tasvirlashi mumkin. Ushbu model doirasida kontrollerlar CRDda ko'rsatilgan Git omborini CRDda ham ko'rsatilgan Kubernetes klaster resurslari bilan solishtiradilar va taqqoslash natijalari asosida tegishli harakatlarni bajaradilar. Xususan, ushbu GitOps modeli ArgoCD da qo'llaniladi.
OpenShift platformasida GitOps
Ko'p klasterli Kubernetes infratuzilmasini boshqarish
Kubernetes-ning tarqalishi va ko'p bulutli strategiyalar va chekka hisoblashlarning mashhurligi oshib borishi bilan har bir mijozga OpenShift klasterlarining o'rtacha soni ham ortib bormoqda.
Misol uchun, chekka hisoblashlardan foydalanganda, bitta mijozning klasterlari yuzlab yoki hatto minglab joylashtirilishi mumkin. Natijada, u ommaviy bulutda va mahalliy joylarda bir nechta mustaqil yoki muvofiqlashtirilgan OpenShift klasterlarini boshqarishga majbur bo'ladi.
Bunday holda, ko'plab muammolarni hal qilish kerak, xususan:
- Klasterlarning bir xil holatda ekanligini nazorat qilish (konfiguratsiyalar, monitoring, saqlash va boshqalar).
- Ma'lum holat asosida klasterlarni qayta yarating (yoki tiklang).
- Ma'lum holat asosida yangi klasterlar yarating.
- O'zgarishlarni bir nechta OpenShift klasterlariga tarqating.
- Bir nechta OpenShift klasterlaridagi o'zgarishlarni orqaga qaytaring.
- Shablonli konfiguratsiyalarni turli muhitlarga bog'lang.
Ilova konfiguratsiyalari
Ilovalar hayot aylanish jarayonida ishlab chiqarish klasterida tugashidan oldin ko'pincha klasterlar zanjiridan (dev, bosqich va boshqalar) o'tadi. Bundan tashqari, mavjudlik va kengayish talablari tufayli mijozlar ko'pincha ilovalarni bir nechta mahalliy klasterlarda yoki ommaviy bulut platformasining bir nechta mintaqalarida joylashtiradilar.
Bunday holda, quyidagi vazifalarni hal qilish kerak:
- Klasterlar (dev, bosqich va boshqalar) o'rtasida ilovalarning (ikkilik, konfiguratsiyalar va boshqalar) harakatlanishini ta'minlash.
- Bir nechta OpenShift klasterlarida ilovalarga (ikkilik, konfiguratsiyalar va boshqalar) o'zgarishlar kiriting.
- Ilovalardagi o'zgarishlarni avvalgi ma'lum holatga qaytaring.
OpenShift GitOps foydalanish holatlari
1. Git omboridan o'zgarishlarni qo'llash
Klaster ma'muri OpenShift klaster konfiguratsiyasini Git omborida saqlashi va ularni osongina yangi klasterlarni yaratish va ularni Git omborida saqlangan ma'lum holatga o'xshash holatga keltirish uchun avtomatik ravishda qo'llashi mumkin.
2. Secret Manager bilan sinxronlash
Administrator, shuningdek, OpenShift maxfiy obyektlarini maxsus yaratilgan vositalar yordamida boshqarish uchun Vault kabi tegishli dasturiy ta'minot bilan sinxronlashtirish imkoniyatidan ham foyda oladi.
3. Drift konfiguratsiyasini boshqarish
Agar OpenShift GitOps o'zi haqiqiy konfiguratsiyalar va omborda ko'rsatilganlar o'rtasidagi nomuvofiqliklarni aniqlasa va ogohlantirsa, administrator faqat ular driftga tezda javob bera oladi.
4. Konfiguratsiya drifti haqida bildirishnomalar
Ular ma'mur o'z-o'zidan tegishli choralarni tezda ko'rish uchun konfiguratsiyani o'zgartirish holatlari haqida tezda bilib olishni xohlasa foydali bo'ladi.
5. Drift paytida konfiguratsiyalarni qo'lda sinxronlashtirish
Administratorga konfiguratsiya o'zgarishi holatlarida OpenShift klasterini Git ombori bilan sinxronlashtirish, klasterni oldingi ma'lum holatga tezda qaytarish imkonini beradi.
6.Driftingda konfiguratsiyalarni avtomatik sinxronlashtirish
Administrator shuningdek, OpenShift klasterini drift aniqlanganda ombor bilan avtomatik sinxronlash uchun sozlashi mumkin, shunda klaster konfiguratsiyasi har doim Git konfiguratsiyasiga mos keladi.
7. Bir nechta klasterlar - bitta ombor
Administrator bir nechta turli OpenShift klasterlarining konfiguratsiyalarini bitta Git omborida saqlashi va kerak bo'lganda ularni tanlab qo'llashi mumkin.
8. Klaster konfiguratsiyasi ierarxiyasi (meros)
Administrator omborda klaster konfiguratsiyasi ierarxiyasini o'rnatishi mumkin (bosqich, mahsulot, ilovalar portfeli va boshqalar meros bilan). Boshqacha qilib aytganda, konfiguratsiyalar bir yoki bir nechta klasterlarga qo'llanilishi kerakligini aniqlashi mumkin.
Misol uchun, agar ma'mur Git repozitariysida "Ishlab chiqarish klasterlari (mahsulot) → X tizimi klasterlari → X tizimining ishlab chiqarish klasterlari" ierarxiyasini o'rnatsa, X tizimining ishlab chiqarish klasterlariga quyidagi konfiguratsiyalar birikmasi qo'llaniladi:
- Barcha ishlab chiqarish klasterlari uchun umumiy konfiguratsiyalar.
- System X klasteri uchun konfiguratsiyalar.
- X tizimi ishlab chiqarish klasteri uchun konfiguratsiyalar.
9. Shablonlar va konfiguratsiyani bekor qilish
Administrator meros qilib olingan konfiguratsiyalar to'plamini va ularning qiymatlarini bekor qilishi mumkin, masalan, ular qo'llaniladigan muayyan klasterlar uchun konfiguratsiyani nozik sozlash.
10. Konfiguratsiyalar, dastur konfiguratsiyalari uchun tanlab kiritish va istisno qilish
Administrator ma'lum xususiyatlarga ega klasterlarga ma'lum konfiguratsiyalarni qo'llash yoki qo'llamaslik shartlarini o'rnatishi mumkin.
11. Shablonni qo'llab-quvvatlash
Dasturchilar har bir maxsus dastur uchun eng mos formatdan foydalanish uchun dastur resurslari qanday aniqlanishini tanlash imkoniyatidan (Helm Chart, sof Kubernetes yaml va boshqalar) foyda oladi.
OpenShift platformasida GitOps vositalari
ArgoCD
ArgoCD tashqi resurslarni muvofiqlashtirish modelini tatbiq etadi va klasterlar va Git omborlari o'rtasida birdan ko'p munosabatlarni tartibga solish uchun markazlashtirilgan foydalanuvchi interfeysini taklif qiladi. Ushbu dasturning kamchiliklari ArgoCD ishlamayotgan paytda ilovalarni boshqarishning mumkin emasligini o'z ichiga oladi.
oqib
Flux On-Cluster Resource Reconcile modelini amalga oshiradi va natijada ta'riflar omborini markazlashtirilgan boshqarish mavjud emas, bu zaif nuqtadir. Boshqa tomondan, markazlashtirishning yo'qligi sababli, ilovalarni boshqarish qobiliyati bitta klaster ishlamay qolsa ham saqlanib qoladi.
OpenShift-da ArgoCD-ni o'rnatish
ArgoCD mukammal buyruq qatori interfeysi va veb-konsolni taklif etadi, shuning uchun biz bu erda Flux va boshqa alternativalarni qamrab olmaymiz.
ArgoCD-ni OpenShift 4 platformasida joylashtirish uchun klaster administratori sifatida quyidagi amallarni bajaring:
ArgoCD komponentlarini OpenShift platformasida joylashtirish
# 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 serverini OpenShift Route orqali ko'rish uchun takomillashtirish
# 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=RedirectArgoCD Cli vositasini o'rnatish
# 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/argocdArgoCD Server administrator parolini o'zgartirish
# 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
Ushbu amallarni bajarganingizdan so'ng, ArgoCD WebUI veb-konsoli yoki ArgoCD Cli buyruq qatori vositasi orqali ArgoCD Server bilan ishlashingiz mumkin.
GitOps - Hech qachon kech emas
"Poyezd ketdi" - ular biror narsa qilish imkoniyati o'tkazib yuborilgan vaziyat haqida shunday deyishadi. OpenShift misolida, ushbu ajoyib yangi platformadan darhol foydalanishni boshlash istagi ko'pincha marshrutlarni, joylashtirishlarni va boshqa OpenShift ob'ektlarini boshqarish va ularga xizmat ko'rsatish bilan aynan shunday vaziyatni yaratadi. Ammo imkoniyat har doim butunlay yo'qoladimi?
haqida maqolalar turkumini davom ettiramiz , bugun biz sizga qanday qilib qo'lda ishlangan dastur va uning resurslarini GitOps vositalari tomonidan boshqariladigan jarayonga aylantirishni ko'rsatamiz. Buning uchun avval httpd ilovasini qo'lda joylashtiramiz. Quyidagi skrinshotda nomlar maydoni, joylashtirish va xizmatni qanday yaratishimiz va keyin marshrut yaratish uchun ushbu xizmatni ochishimiz ko'rsatilgan.
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-appShunday qilib, bizda qo'lda tayyorlangan dastur mavjud. Endi uni GitOps boshqaruvi ostida mavjudlikni yo'qotmasdan o'tkazish kerak. Qisqasi, u shunday qiladi:
- Kod uchun Git omborini yarating.
- Biz joriy ob'ektlarimizni eksport qilamiz va ularni Git omboriga yuklaymiz.
- GitOps vositalarini tanlash va joylashtirish.
- Biz o'z omborimizni ushbu asboblar to'plamiga qo'shamiz.
- Biz dasturni GitOps asboblar to'plamida aniqlaymiz.
- Biz GitOps asboblar to'plamidan foydalangan holda dasturni sinovdan o'tkazamiz.
- Biz GitOps asboblar to'plamidan foydalangan holda ob'ektlarni sinxronlashtiramiz.
- Ob'ektlarni kesish va avtomatik sinxronlashni yoqish.
Avval aytib o'tilganidek , GitOps-da Kubernetes klaster(lar)idagi barcha ob'ektlar haqida bitta va bitta ma'lumot manbai - Git ombori mavjud. Keyinchalik, tashkilotingiz allaqachon Git repozitoriyasidan foydalanadi degan asosga asoslanamiz. U ommaviy yoki shaxsiy bo'lishi mumkin, lekin u Kubernetes klasterlari uchun ochiq bo'lishi kerak. Bu dastur kodi bilan bir xil ombor yoki joylashtirish uchun maxsus yaratilgan alohida ombor bo'lishi mumkin. Omborda qat'iy ruxsatlarga ega bo'lish tavsiya etiladi, chunki u erda sirlar, marshrutlar va boshqa xavfsizlikka sezgir narsalar saqlanadi.
Bizning misolimizda biz GitHub-da yangi ommaviy omborni yaratamiz. Siz uni xohlaganingizcha chaqirishingiz mumkin, biz blogpost nomidan foydalanamiz.
Agar YAML ob'ekt fayllari mahalliy yoki Git-da saqlanmagan bo'lsa, siz oc yoki kubectl ikkilik fayllaridan foydalanishingiz kerak bo'ladi. Quyidagi skrinshotda biz nomlar maydoni, joylashtirish, xizmat ko'rsatish va marshrutimiz uchun YAML so'rayapmiz. Bundan oldin biz yangi yaratilgan omborni va CDni unga klonladik.
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.yamlEndi Argo CD sinxronlashtira olmaydigan maydonni olib tashlash uchun deployment.yaml faylini tahrir qilaylik.
sed -i '/sgeneration: .*/d' deployment.yamlBundan tashqari, marshrutni o'zgartirish kerak. Biz birinchi navbatda ko'p qatorli o'zgaruvchini o'rnatamiz va keyin ingress: null o'zgaruvchining mazmuni bilan almashtiramiz.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlShunday qilib, biz fayllarni saralab oldik, faqat ularni Git omboriga saqlash qoladi. Shundan so'ng, ushbu ombor yagona ma'lumot manbai bo'lib qoladi va ob'ektlarni qo'lda o'zgartirishni qat'iyan taqiqlash kerak.
git commit -am ‘initial commit of objects’
git push origin masterBundan tashqari, biz ArgoCD-ni allaqachon o'rnatganligingizdan kelib chiqamiz (buni qanday qilish kerak - oldingi ). Shuning uchun biz Argo CD-ga o'zimiz yaratgan, misolimizdagi dastur kodini o'z ichiga olgan omborni qo'shamiz. Ilgari yaratilgan omborni aniq belgilab qo'yganingizga ishonch hosil qiling.
argocd repo add https://github.com/cooktheryan/blogpostEndi dasturni yaratamiz. Ilova qiymatlarni o'rnatadi, shunda GitOps asboblar to'plami qaysi ombor va yo'llardan foydalanish kerakligini, ob'ektlarni boshqarish uchun qaysi OpenShift kerakligini, omborning qaysi bo'limiga ehtiyoj borligini va resurslarni avtomatik sinxronlashtirish kerakligini tushunadi.
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
Argo kompakt diskida dastur ko'rsatilgandan so'ng, asboblar to'plami allaqachon o'rnatilgan ob'ektlarni ombordagi ta'riflarga nisbatan tekshirishni boshlaydi. Bizning misolimizda avtomatik sinxronlash va tozalash o'chirilgan, shuning uchun elementlar hali o'zgarmaydi. Iltimos, Argo CD interfeysida ilovamiz “Sinxronizatsiyadan tashqari” holatiga ega bo'lishini unutmang, chunki ArgoCD taqdim etadigan yorliq yo'q.
Shuning uchun biz sinxronlashni biroz keyinroq boshlaganimizda, ob'ektlar qayta joylashtirilmaydi.
Endi fayllarimizda xatolik yo'qligiga ishonch hosil qilish uchun sinovdan o'taylik.
argocd app sync simple-app --dry-runHech qanday xato bo'lmasa, siz sinxronlashtirishga o'tishingiz mumkin.
argocd app sync simple-appIlovamizda argocd get buyrug'ini ishga tushirganimizdan so'ng, dastur holati Sog'lom yoki Sinxronlashtirilganga o'zgarganligini ko'rishimiz kerak. Bu endi Git omboridagi barcha resurslar allaqachon joylashtirilgan resurslarga mos kelishini anglatadi.
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
... Endi siz qo'lda hech narsa yaratilmasligini va har safar ob'ekt yaratilganda yoki omborga yangilanganda, joylashtirish sodir bo'lishini ta'minlash uchun avtomatik sinxronlash va tozalashni yoqishingiz mumkin.
argocd app set simple-app --sync-policy automated --auto-prune
Shunday qilib, biz GitOps nazorati ostida GitOps-dan hech qanday tarzda foydalanmagan dasturni muvaffaqiyatli olib chiqdik.
Manba: www.habr.com