OpenShift үшін GitOps бағдарламасына кіріспе

Бүгін біз GitOps принциптері мен модельдері туралы, сондай-ақ бұл модельдер OpenShift платформасында қалай жүзеге асырылатыны туралы айтатын боламыз. Осы тақырып бойынша интерактивті нұсқаулық бар байланыс.

Қысқаша айтқанда, GitOps - бұл инфрақұрылым мен қолданба конфигурацияларын басқару үшін Git тарту сұрауларын пайдалануға арналған тәжірибелер жиынтығы. GitOps жүйесіндегі Git репозиторийі жүйенің күйі туралы ақпараттың жалғыз көзі ретінде қарастырылады және осы күйдегі кез келген өзгерістер толығымен бақыланатын және тексерілетін болады.

GitOps-те өзгерістерді бақылау идеясы мүлдем жаңа емес; бұл тәсіл қолданбаның бастапқы кодымен жұмыс істеу кезінде әмбебап дерлік бұрыннан қолданылған. GitOps жай ғана инфрақұрылымды және қолданба конфигурациясын басқаруда ұқсас мүмкіндіктерді (шолулар, тарту сұраулары, тегтер және т.б.) жүзеге асырады және бастапқы кодты басқару жағдайындағы сияқты ұқсас артықшылықтарды береді.

GitOps үшін академиялық анықтама немесе бекітілген ережелер жиынтығы жоқ, тек осы тәжірибеге негізделген принциптер жиынтығы:

• Жүйенің декларативті сипаттамасы Git репозиторийінде сақталады (конфигурациялар, мониторинг және т.б.).
• Күй өзгерістері тарту сұраулары арқылы жасалады.
• Жұмыс істеп тұрған жүйелердің күйі Git push сұраулары арқылы репозиторийдегі деректерге сәйкестендіріледі.

GitOps принциптері

• Жүйе анықтамалары бастапқы код ретінде сипатталады

Жүйе конфигурациясы код ретінде қарастырылады, сондықтан ол шындықтың жалғыз көзі ретінде қызмет ететін Git репозиторийінде сақталуы және автоматты түрде нұсқасы болуы мүмкін. Бұл тәсіл жүйелердегі өзгерістерді шығаруды және кері қайтаруды жеңілдетеді.

• Жүйелердің қалаған күйі мен конфигурациясы Git-те орнатылады және нұсқаланады

Git жүйесінде жүйелердің қалаған күйін сақтау және нұсқалау арқылы біз жүйелер мен қолданбаларға өзгертулерді оңай шығарып, кері қайтара аламыз. Сондай-ақ Git қауіпсіздік тетіктерін код иелігін басқару және оның түпнұсқалығын тексеру үшін пайдалана аламыз.

• Конфигурация өзгерістерін тарту сұраулары арқылы автоматты түрде қолдануға болады

Git тарту сұрауларын пайдалану арқылы біз репозиторийдегі конфигурацияларға өзгерістердің қалай қолданылатынын оңай басқара аламыз. Мысалы, оларды басқа топ мүшелеріне қарау үшін беруге немесе CI сынақтарынан өтуге және т.б.

Сонымен қатар, әкімші өкілеттіктерін солға және оңға бөлудің қажеті жоқ. Конфигурация өзгерістерін орындау үшін пайдаланушыларға сол конфигурациялар сақталған Git репозиторийінде сәйкес рұқсаттар ғана қажет.

• Конфигурациялардың бақыланбайтын дрейфі мәселесін шешу

Жүйенің қажетті күйі Git репозиторийінде сақталғаннан кейін, жүйенің ағымдағы күйі оның қалаған күйіне сәйкес келетініне кепілдік беретін бағдарламалық құралды табу ғана қалады. Егер олай болмаса, онда бұл бағдарламалық құрал - параметрлерге байланысты - сәйкессіздікті өздігінен жоюы немесе конфигурацияның дрейфі туралы бізге хабарлауы керек.

OpenShift үшін GitOps үлгілері

Кластердегі ресурстарды салыстырушы

Осы үлгіге сәйкес кластерде Git репозиторийіндегі Kubernetes ресурстарын (YAML файлдары) кластердің нақты ресурстарымен салыстыруға жауап беретін контроллері бар. Егер сәйкессіздіктер анықталса, контроллер хабарландырулар жібереді және сәйкессіздіктерді түзету үшін әрекет етуі мүмкін. Бұл GitOps үлгісі Anthos Config Management және Weaveworks Flux қолданбаларында қолданылады.

Сыртқы ресурстарды сәйкестендіру құралы (басу)

Бұл модельді «Git репозиторийі - Kubernetes кластері» жұптарындағы ресурстарды синхрондауға жауапты бір немесе бірнеше контроллерлер болған кезде алдыңғысының нұсқасы ретінде қарастыруға болады. Мұндағы айырмашылық әрбір басқарылатын кластердің жеке контроллері болуы міндетті емес. Git - k8s кластер жұптары көбінесе контроллердің синхрондауды орындау жолын сипаттай алатын CRD (пайдаланушы ресурс анықтамалары) ретінде анықталады. Бұл үлгіде контроллерлер CRD-да көрсетілген Git репозиторийін CRD-де де көрсетілген Kubernetes кластерінің ресурстарымен салыстырады және салыстыру нәтижелері бойынша сәйкес әрекеттерді орындайды. Атап айтқанда, бұл GitOps моделі ArgoCD-де қолданылады.

OpenShift платформасындағы GitOps

Көп кластерлі Kubernetes инфрақұрылымын басқару

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 диаграммасы, таза Kubernetes yaml және т.б.) анықталатынын таңдау мүмкіндігінен пайда көреді.

OpenShift платформасындағы GitOps құралдары

ArgoCD

ArgoCD сыртқы ресурстарды сәйкестендіру үлгісін жүзеге асырады және кластерлер мен Git репозиторийлері арасындағы бір-көп қатынастарын реттеу үшін орталықтандырылған UI ұсынады. Бұл бағдарламаның кемшіліктері ArgoCD жұмыс істемей тұрғанда қолданбаларды басқару мүмкін еместігін қамтиды.

Ресми сайт

ағыны

Flux On-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 серверімен ArgoCD WebUI веб консолі немесе ArgoCD Cli пәрмен жолы құралы арқылы жұмыс істеуге болады.
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 жүйесінде жаңа жалпыға ортақ репозиторий жасаймыз. Қалағаныңызша атай аласыз, біз блогпост атауын қолданамыз.

Егер 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 ықшам дискісіне мысалдағы қолданба кодын қамтитын өзіміз жасаған репозиторийді қосамыз. Тек бұрын жасаған репозиторийді нақты көрсеткеніңізге көз жеткізіңіз.

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 ықшам дискісінде қолданба көрсетілгеннен кейін құралдар жинағы бұрыннан орналастырылған нысандарды репозиторийдегі анықтамалармен салыстыра бастайды. Біздің мысалда автоматты синхрондау және тазалау өшірілген, сондықтан элементтер әлі өзгермейді. 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