🥇OpenShift-д зориулсан GitOps-ийн танилцуулга

Өнөөдөр бид GitOps-ийн зарчим, загваруудын талаар, мөн эдгээр загваруудыг OpenShift платформ дээр хэрхэн хэрэгжүүлж байгаа талаар ярих болно. Энэ сэдвээр интерактив гарын авлага бэлэн байна холбоос.

Товчхондоо, GitOps нь дэд бүтэц, хэрэглээний тохиргоог удирдахад Git татах хүсэлтийг ашиглах практикуудын багц юм. GitOps дахь Git репозиторийг системийн төлөв байдлын талаарх мэдээллийн нэг эх сурвалж гэж үздэг бөгөөд энэ төлөвт гарсан аливаа өөрчлөлтийг бүрэн хянах, шалгах боломжтой.

GitOps дахь өөрчлөлтийг хянах санаа нь шинэ зүйл биш бөгөөд энэ аргыг програмын эх кодтой ажиллахад бараг бүх нийтээр удаан хугацаанд ашиглаж ирсэн. GitOps нь дэд бүтэц, хэрэглээний тохиргооны удирдлагад ижил төстэй функцуудыг (шалгах, татах хүсэлт, шошго гэх мэт) зүгээр л хэрэгжүүлдэг бөгөөд эх кодын менежменттэй адил ашиг тусыг өгдөг.

GitOps-д зориулсан эрдэм шинжилгээний тодорхойлолт эсвэл батлагдсан дүрмийн багц байхгүй, зөвхөн энэ практик дээр суурилсан зарчмуудын багц:

Системийн тунхаглалыг Git репозиторид (тохиргоо, хяналт гэх мэт) хадгалдаг.
Төрийн өөрчлөлтийг татах хүсэлтээр хийдэг.
Ажиллаж байгаа системийн төлөвийг Git түлхэх хүсэлтийг ашиглан репозитор дахь өгөгдөлтэй нийцүүлнэ.

GitOps зарчмууд

Системийн тодорхойлолтыг эх код гэж тодорхойлдог

Системийн тохиргоог код гэж үздэг тул үүнийг Git репозиторид хадгалж, автоматаар хувилбар болгох боломжтой бөгөөд энэ нь үнэний нэг эх сурвалж болдог. Энэ арга нь системд өөрчлөлт оруулах, буцаахад хялбар болгодог.

Системийн хүссэн төлөв, тохиргоог Git-д тохируулж, хувилбар болгосон

Git-д системүүдийн хүссэн төлөвийг хадгалж, хувилбар болгосноор бид систем болон програмын өөрчлөлтийг хялбархан гаргаж, буцаах боломжтой. Бид мөн Git-ийн аюулгүй байдлын механизмуудыг ашиглан кодын эзэмшлийг хянах, жинхэнэ эсэхийг шалгах боломжтой.

Тохиргооны өөрчлөлтийг татах хүсэлтээр автоматаар хийж болно

Git татах хүсэлтийг ашигласнаар бид репозиторын тохиргоонд хэрхэн өөрчлөлт оруулахыг хялбархан хянах боломжтой. Жишээлбэл, тэдгээрийг багийн бусад гишүүдэд хянуулах эсвэл CI тестээр дамжуулан өгөх гэх мэтээр өгч болно.

Үүний зэрэгцээ админ эрх мэдлийг баруун, зүүн тийш хуваарилах шаардлагагүй болно. Тохиргооны өөрчлөлтийг хийхийн тулд хэрэглэгчид зөвхөн тэдгээр тохиргоог хадгалсан Git репозиторд зохих зөвшөөрөл хэрэгтэй.

Тохиргооны хяналтгүй шилжилтийн асуудлыг засах

Системийн хүссэн төлөвийг Git репозиторид хадгалсны дараа бидний хийх ёстой зүйл бол системийн одоогийн төлөвийг хүссэн төлөвтэй нь тааруулах программ хангамжийг олох явдал юм. Хэрэв тийм биш бол энэ програм хангамж нь тохиргооноос хамааран зөрүүг өөрөө арилгах эсвэл тохиргооны өөрчлөлтийн талаар бидэнд мэдэгдэх ёстой.

OpenShift-д зориулсан GitOps загварууд

Кластер дээрх нөөцийн тохируулагч

Энэ загварын дагуу кластер нь Git репозитор дахь Kubernetes нөөцүүдийг (YAML файлууд) кластерын бодит нөөцтэй харьцуулах үүрэгтэй хянагчтай. Хэрэв зөрчил илэрсэн бол хянагч мэдэгдэл илгээж, зөрүүг засах арга хэмжээ авах боломжтой. Энэхүү GitOps загварыг Anthos Config Management болон Weaveworks Flux-д ашигладаг.

Гадаад нөөцийн тохируулагч (Түлхэх)

"Git репозитор - Кубернетес кластер" хос дахь нөөцийг синхрончлох үүрэгтэй нэг буюу хэд хэдэн хянагчтай бол энэ загварыг өмнөх хувилбарын хувилбар гэж үзэж болно. Энд байгаа ялгаа нь удирддаг кластер бүр өөрийн гэсэн тусдаа хянагчтай байх албагүй. Git - k8s кластер хосууд нь ихэвчлэн CRD (захиалгат нөөцийн тодорхойлолт) гэж тодорхойлогддог бөгөөд энэ нь хянагч хэрхэн синхрончлол хийх ёстойг тайлбарлаж болно. Энэ загварын хүрээнд хянагч нар CRD-д заасан Git репозиторийг мөн CRD-д заасан Kubernetes кластерийн нөөцтэй харьцуулж, харьцуулалтын үр дүнд үндэслэн зохих үйлдлүүдийг гүйцэтгэдэг. Ялангуяа энэ GitOps загварыг ArgoCD-д ашигладаг.

OpenShift платформ дээрх GitOps

Олон кластерт Кубернетес дэд бүтцийн удирдлага

Kubernetes-ийн тархалт, олон үүлэн стратеги болон захын тооцоолол улам бүр түгээмэл болж байгаатай холбогдуулан нэг хэрэглэгчдэд ногдох OpenShift кластерын дундаж тоо мөн нэмэгдэж байна.

Жишээлбэл, захын тооцооллыг ашиглах үед нэг хэрэглэгчийн кластерыг хэдэн зуу, бүр мянгаар нь байрлуулж болно. Үүний үр дүнд тэрээр олон нийтийн үүлэн болон газар дээрх хэд хэдэн бие даасан эсвэл зохицуулалттай OpenShift кластеруудыг удирдахаас өөр аргагүй болдог.

Энэ тохиолдолд олон асуудлыг шийдвэрлэх шаардлагатай, тухайлбал:

Кластерууд ижил төлөвт байгаа эсэхийг хянах (тохиргоо, хяналт, хадгалалт гэх мэт).
Мэдэгдэж буй төлөвт суурилсан кластеруудыг дахин үүсгэх (эсвэл сэргээх).
Мэдэгдэж буй төлөвт тулгуурлан шинэ кластер үүсгэх.
Олон OpenShift кластерт өөрчлөлт оруулах.
Олон OpenShift кластер дээрх өөрчлөлтүүдийг буцаах.
Загварын тохиргоог өөр өөр орчинд холбох.

Хэрэглээний тохиргоо

Хэрэглээний амьдралын мөчлөгийн туршид програмууд нь үйлдвэрлэлийн кластерт дуусахаас өмнө кластеруудын гинжээр (хөгжүүлэгч, үе шат гэх мэт) дамждаг. Нэмж дурдахад хүртээмжтэй байдал, өргөтгөх чадварын шаардлагын улмаас үйлчлүүлэгчид олон нийтийн үүлэн платформын олон тооны кластер эсвэл олон бүс нутагт програмуудыг байршуулдаг.

Энэ тохиолдолд дараахь ажлуудыг шийдвэрлэх шаардлагатай.

Кластер (хөгжүүлэгч, үе шат гэх мэт) хооронд програмуудын хөдөлгөөнийг (хоёртын файл, тохиргоо гэх мэт) баталгаажуулна.
Хэд хэдэн OpenShift кластерт програмуудад (хоёртын файлууд, тохиргоонууд гэх мэт) өөрчлөлтүүдийг оруулаарай.
Аппликешнүүдийн өөрчлөлтийг өмнөх мэдэгдэж буй төлөв рүү буцаах.

OpenShift GitOps ашиглах тохиолдлууд

1. Git репозитороос өөрчлөлт оруулах

Кластерын администратор нь OpenShift кластерийн тохиргоог Git репозиторид хадгалж, автоматаар ашиглан шинэ кластеруудыг хялбархан үүсгэж, Git репозиторт хадгалагдсан мэдэгдэж буй төлөвтэй ижил төлөвт оруулах боломжтой.

2. Нууц менежертэй синхрончлол хийх

Администратор нь OpenShift нууц объектуудыг тусгайлан бүтээсэн хэрэгслүүдийг ашиглан удирдахын тулд Vault гэх мэт тохирох программ хангамжтай синхрончлох чадвараас ашиг тус хүртэх болно.

3. Дрифтийн тохиргоог хянах

Админ нь зөвхөн OpenShift GitOps нь бодит тохиргоо болон репозиторт заасан тохиргооны хоорондын зөрүүг тодорхойлж, сэрэмжлүүлснээр л дрифт хурдан хариу үйлдэл үзүүлэх болно.

4. Тохиргооны шилжилтийн талаарх мэдэгдэл

Эдгээр нь администратор өөрөө зохих арга хэмжээг хурдан авахын тулд тохиргооны шилжилтийн тохиолдлын талаар хурдан мэдэхийг хүсч байгаа тохиолдолд хэрэг болно.

5. Дрифт хийх үед тохиргоог гараар синхрончлох

Тохиргооны өөрчлөлт гарсан тохиолдолд OpenShift кластерыг Git репозитортой синхрончлохыг админд зөвшөөрч, кластерыг өмнөх мэдэгдэж байсан төлөв рүү хурдан буцаах боломжтой.

6.Дрифт хийх үед тохиргоог автоматаар синхрончлох

Администратор мөн OpenShift кластерыг зөрөх нь илэрсэн үед репозитортой автоматаар синхрончлохоор тохируулах боломжтой бөгөөд ингэснээр кластерийн тохиргоо нь Git-ийн тохиргоотой үргэлж таарч байх болно.

7. Хэд хэдэн кластер - нэг репозитор

Администратор нь хэд хэдэн өөр өөр OpenShift кластеруудын тохиргоог нэг Git репозиторт хадгалж, шаардлагатай бол сонгон хэрэглэж болно.

8. Кластерийн тохиргооны шатлал (өв залгамжлал)

Админ нь репозитор дахь кластерийн тохиргооны шатлалыг (үе шат, бүтээгдэхүүн, програмын багц гэх мэт өв залгамжлалтай) тохируулах боломжтой. Өөрөөр хэлбэл, тохиргоог нэг буюу хэд хэдэн кластерт хэрэглэх эсэхийг тодорхойлж болно.

Жишээлбэл, хэрэв администратор Git репозиторид "Үйлдвэрлэлийн кластерууд (бүтээгдэхүүн) → Систем X кластерууд → X системийн үйлдвэрлэлийн кластерууд" шатлалыг тохируулсан бол X системийн үйлдвэрлэлийн кластеруудад дараах тохиргооны хослолыг хэрэглэнэ.

Бүх үйлдвэрлэлийн кластерт нийтлэг байдаг тохиргоо.
Систем X кластерийн тохиргоо.
X системийн үйлдвэрлэлийн кластерийн тохиргоо.

9. Загварууд болон тохиргоог хүчингүй болгох

Администратор нь удамшсан тохиргооны багц болон тэдгээрийн утгыг дарж, жишээлбэл, тэдгээрийг ашиглах тодорхой кластеруудын тохиргоог нарийн тохируулах боломжтой.

10. Тохиргоо, хэрэглээний тохиргоонд оруулах, хасах сонголт

Администратор нь тодорхой шинж чанар бүхий кластерт тодорхой тохиргоог ашиглах эсвэл хэрэглэхгүй байх нөхцлийг тохируулж болно.

11. Загварын дэмжлэг

Хөгжүүлэгчид тодорхой програм бүрт хамгийн тохиромжтой форматыг ашиглахын тулд програмын нөөцийг хэрхэн тодорхойлох (Helm Chart, цэвэр Kubernetes yaml гэх мэт) сонгох чадвараас ашиг тус хүртэх болно.

OpenShift платформ дээрх GitOps хэрэгслүүд

ArgoCD

ArgoCD нь External Resource Reconcile загварыг хэрэгжүүлж, кластерууд болон Git репозиторуудын хооронд нэгээс олон харилцааг зохицуулах төвлөрсөн UI-г санал болгодог. Энэ програмын сул тал нь ArgoCD ажиллахгүй үед програмуудыг удирдах боломжгүй байдаг.

Албан ёсны вэб сайт

урсгал

Flux нь Cluster Resource Reconcile загварыг хэрэгжүүлдэг бөгөөд үүний үр дүнд тодорхойлолтын агуулахын төвлөрсөн удирдлага байхгүй байгаа нь сул тал юм. Нөгөөтэйгүүр, төвлөрөл байхгүй тул нэг кластер бүтэлгүйтсэн ч програмуудыг удирдах чадвар хэвээр байна.

Албан ёсны вэб сайт

OpenShift дээр ArgoCD суулгаж байна

ArgoCD нь командын мөрийн интерфейс болон вэб консолыг санал болгодог тул бид энд Flux болон бусад хувилбаруудыг авч үзэхгүй.

ArgoCD-г OpenShift 4 платформ дээр байрлуулахын тулд кластерын администраторын хувьд дараах алхмуудыг дагана уу:

ArgoCD бүрэлдэхүүн хэсгүүдийг 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}')

ArgoCD серверийг 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 хэрэгслийг ашиглаж байна

# 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 серверийн админ нууц үгийг сольж байна

# 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

Эдгээр алхмуудыг хийсний дараа та ArgoCD WebUI вэб консол эсвэл ArgoCD Cli командын мөрийн хэрэгслээр ArgoCD сервертэй ажиллах боломжтой.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Хэзээ ч оройтдоггүй

"Галт тэрэг явлаа" - тэд ямар нэгэн зүйл хийх боломжоо алдсан нөхцөл байдлын талаар ингэж хэлдэг. OpenShift-ийн хувьд энэхүү гайхалтай шинэ платформыг нэн даруй ашиглаж эхлэх хүсэл нь маршрут, байршуулалт болон бусад OpenShift объектуудын удирдлага, засвар үйлчилгээтэй яг ийм нөхцөл байдлыг бий болгодог. Гэхдээ боломж үргэлж бүрэн алдагддаг уу?

тухай цуврал нийтлэлээ үргэлжлүүлж байна GitOps, өнөөдөр бид гар хийцийн програм болон түүний нөөцийг хэрхэн бүх зүйлийг GitOps хэрэгслээр удирддаг процесс болгон хувиргах талаар харуулах болно. Үүнийг хийхийн тулд бид эхлээд httpd програмыг гараар байрлуулна. Доорх дэлгэцийн агшинд бид нэрийн орон зай, байршуулалт, үйлчилгээг хэрхэн бий болгож, дараа нь энэ үйлчилгээг хэрхэн харуулахыг харуулж байна.

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

Тиймээс бид гар аргаар хийсэн програмтай болсон. Одоо үүнийг GitOps удирдлагын дор ашиглах боломжоо алдахгүйгээр шилжүүлэх шаардлагатай байна. Товчхондоо үүнийг хийдэг:

Кодын хувьд Git репозитор үүсгэнэ үү.
Бид одоогийн объектуудаа экспортолж, Git репозитор руу байршуулдаг.
GitOps хэрэгслийг сонгох, ашиглах.
Бид энэ хэрэгсэлд өөрийн агуулахыг нэмдэг.
Бид програмыг GitOps хэрэгслийнхээ багцад тодорхойлдог.
Бид GitOps хэрэглүүрийг ашиглан програмын туршилтыг гүйцэтгэдэг.
Бид GitOps хэрэглүүрийг ашиглан объектуудыг синхрончилдог.
Объектуудын тайрах болон автомат синхрончлолыг идэвхжүүлэх.

Өмнө дурьдсанчлан нийтлэл, GitOps дээр Kubernetes кластер(ууд) дахь бүх объектын талаарх мэдээллийн цорын ганц эх сурвалж байдаг - Git репозитор. Дараа нь, бид танай байгууллага Git репозиторыг аль хэдийн ашиглаж байгаа гэсэн үндэслэлээс гарна. Энэ нь нийтийн болон хувийн байж болох ч Kubernetes кластерт хандах боломжтой байх ёстой. Энэ нь програмын кодтой ижил хадгалах газар эсвэл байршуулалтад зориулж тусгайлан үүсгэсэн тусдаа хадгалах газар байж болно. Нууц, чиглүүлэлт болон бусад аюулгүй байдлын мэдрэмтгий зүйлс тэнд хадгалагдах тул хадгалах газарт хатуу зөвшөөрөлтэй байхыг зөвлөж байна.

Бидний жишээн дээр бид GitHub дээр шинэ нийтийн репозитор үүсгэх болно. Та дуртай бүхнээ нэрлэж болно, бид blogpost нэрийг ашигладаг.

Хэрэв YAML объектын файлууд дотоод эсвэл Git-д хадгалагдаагүй бол та oc эсвэл kubectl хоёртын файлуудыг ашиглах хэрэгтэй болно. Доорх дэлгэцийн агшинд бид нэрийн орон зай, байршуулалт, үйлчилгээ, маршрутын талаар YAML-г хүсч байна. Үүнээс өмнө бид шинээр үүсгэсэн репозитор болон 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

Одоо Argo CD-ийн синхрончлох боломжгүй талбарыг арилгахын тулд deployment.yaml файлыг засъя.

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

Үүнээс гадна маршрутыг өөрчлөх шаардлагатай. Бид эхлээд олон мөрт хувьсагчийг тохируулаад дараа нь ingress: null-г тухайн хувьсагчийн агуулгаар солино.

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

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

Тиймээс бид файлуудыг ангилсан бөгөөд зөвхөн Git репозиторыг хадгалахад л үлдлээ. Үүний дараа энэ агуулах нь мэдээллийн цорын ганц эх сурвалж болж, объектыг гараар өөрчлөхийг хатуу хориглоно.

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

Цаашид бид ArgoCD-г аль хэдийн суулгасан гэдгээс дүгнэж байна (үүнийг хэрхэн хийх вэ - өмнөх хэсгийг үзнэ үү бичлэг). Тиймээс бид өөрсдийн жишээн дээрх програмын кодыг агуулсан архивыг Argo CD-д нэмнэ. Та өмнө нь үүсгэсэн агуулахаа яг зааж өгсөн эсэхээ шалгаарай.

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

Одоо програмаа үүсгэцгээе. Уг програм нь GitOps хэрэглүүр нь аль репозитор, замыг ашиглах, объектыг удирдахад ямар OpenShift хэрэгтэй, репозиторын аль салбар шаардлагатай, нөөцийг автоматаар синхрончлох эсэхийг ойлгохын тулд утгыг тохируулдаг.

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 CD-д програмыг зааж өгсний дараа хэрэглүүр нь аль хэдийн байрлуулсан объектуудыг репозитор дахь тодорхойлолтуудтай харьцуулж шалгаж эхэлдэг. Бидний жишээн дээр автомат синхрончлол, цэвэрлэгээ идэвхгүй болсон тул элементүүд хараахан өөрчлөгдөөгүй байна. Argo CD интерфейс дээр ArgoCD-н өгсөн шошго байхгүй тул манай програм "Синкгүй" гэсэн статустай байх болно гэдгийг анхаарна уу.
Тиймээс бид синхрончлолыг хэсэг хугацааны дараа эхлүүлэхэд объектуудыг дахин байрлуулахгүй.

Одоо бидний файлуудад алдаа байхгүй эсэхийг шалгахын тулд туршилт хийцгээе.

argocd app sync simple-app --dry-run

Хэрэв алдаа байхгүй бол та синхрончлолыг үргэлжлүүлж болно.

argocd app sync simple-app

Манай программ дээр argocd get командыг ажиллуулсны дараа бид програмын статус Эрүүл эсвэл Синхрончлогдсон болж өөрчлөгдсөнийг харах болно. Энэ нь Git репозитор дахь бүх нөөц нь аль хэдийн байршуулсан нөөцтэй тохирч байна гэсэн үг юм.

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

Одоо та автоматаар синхрончлол болон цэвэрлэгээг идэвхжүүлж, гараар юу ч үүсгээгүй, объект үүсгэх эсвэл репозитор руу шинэчлэх бүрд байршуулалт хийгдэх болно.

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

Тиймээс бид GitOps-ийн хяналтан дор GitOps-ийг ямар ч байдлаар ашиглаагүй програмыг амжилттай авчирсан.

Эх сурвалж: www.habr.com

OpenShift-д зориулсан GitOps-ийн танилцуулга