🥇Увядзенне ў GitOps для OpenShift

Сёння мы раскажам аб прынцыпах і мадэлях GitOps, а таксама аб тым, як гэтыя мадэлі рэалізуюцца на платформе OpenShift. Інтэрактыўнае кіраўніцтва на гэтую тэму даступна па спасылцы.

Калі сцісла, то GitOps - гэта набор практычных метадаў выкарыстання pull-запытаў Git для кіравання канфігурацыямі інфраструктуры і прыкладанняў. Git-рэпазітар у рамках GitOps разглядаецца як адна адзіная крыніца звестак аб стане сістэмы, прычым любыя змены гэтага стану цалкам адсочваюцца і паддаюцца аўдыту.

Ідэя з адсочваннем змен у GitOps зусім не новая, такі падыход ужо даўно і практычна паўсюдна ўжываецца пры працы з зыходным кодам прыкладанняў. GitOps проста рэалізуе аналагічныя функцыі (review-праверкі, pull-запыты, тэгі і т. д.) пры кіраванні канфігурацыямі інфраструктуры і прыкладанняў і дае аналагічныя перавагі, як у выпадку кіравання зыходным кодам.

Для GitOps няма нейкага акадэмічнага вызначэння ці зацверджанага збору правіл, толькі збор прынцыпаў, на якіх будуецца гэтая практыка:

Дэкларатыўнае апісанне сістэмы захоўваецца ў рэпазітары Git (канфігі, маніторынг і т. д).
Змяненні стану выконваюцца праз pull-запыты.
Стан якія працуюць сістэм прыводзіцца ў адпаведнасць з дадзенымі ў рэпазітары з дапамогай push-запытаў Git.

Прынцыпы GitOps

Азначэнні сістэм апісваюцца як зыходны код

Канфігурацыя сістэм разглядаецца як код, таму яе можна захоўваць і аўтаматычна версіяваць у рэпазітары Git, які служыць адзінай крыніцай ісціны. Такі падыход дазваляе лёгка накатваць (rollout) і адкатваць (rollback) змены ў сістэмах.

Жаданае стан і канфігурацыя сістэм задаюцца і версіянуюцца ў Git

Захоўваючы і версіянуючы ў Git жаданае стан сістэм, мы атрымліваем магчымасць лёгка накатваць і адкочваць змены ў сістэмах і прыкладаннях. Таксама мы можам выкарыстоўваць Git'аўскія механізмы бяспекі для кантролю валодання кодам і пацверджання яго сапраўднасці.

Змены ў канфігурацыях могуць аўтаматычна прымяняцца з дапамогай pull-запытаў.

Выкарыстоўваючы Git'аўскія pull-запыты, мы можам лёгка кіраваць тым, як змены прымяняюцца да канфігурацый у рэпазітары. Напрыклад, іх можна аддаць на праверку іншым удзельнікам каманды ці прагнаць праз тэсты CI і інш.

І пры гэтым не трэба раздаваць адмінскія паўнамоцтвы направа і налева. Каб выканаць commit змен у канфігурацыі, карыстачы досыць адпаведных паўнамоцтваў у рэпазітары Git, дзе захоўваюцца гэтыя канфігурацыі.

Устараненне праблемы некантралюемага дрыфту канфігурацый

Калі жаданае стан сістэмы захоўваецца ў рэпазітары Git, нам застаецца толькі знайсці софт, які б кантраляваў, што бягучы стан сістэмы адпавядае яе жаданаму стану. Калі гэта не так, то гэты софт павінен - у залежнасці ад налад - альбо самастойна ўхіліць неадпаведнасць, альбо апавясціць нас аб дрыфце канфігурацый.

Мадэлі GitOps для OpenShift

On-Cluster Resource Reconciller

Паводле гэтай мадэлі ў кластары ёсць кантролер, які адказвае за параўнанне Kubernetes-рэсурсаў (файлаў YAML) у Git-рэпазітары з рэальнымі рэсурсамі кластара. Пры выяўленні разыходжанняў кантролер рассылае апавяшчэнні і, магчыма, прымае меры для ўхілення неадпаведнасцяў. Гэтая мадэль GitOps выкарыстоўваецца ў Anthos Config Management і Weaveworks Flux.

External Resource Reconciler (Push)

Гэтую мадэль можна разглядаць як разнавіднасць папярэдняй, калі ў нас ёсць адзін ці некалькі кантролераў, якія адказваюць за сінхранізацыю рэсурсаў у парах «рэпазітар Git – кластар Kubernetes». Адрозненне ж тут у тым, што ў кожным кіраваным кластары неабавязкова павінен быць свой асобны кантролер. Пары "Git - кластар k8s" часта вызначаюцца як CRD-апісанні (custom resources definition), у якіх можна апісаць, як кантролер павінен выконваць сінхранізацыю. У рамках гэтай мадэлі кантролеры параўноўваюць Git-рэпазітар, зададзены ў CRD, з рэсурсамі кластара Kubernetes, якія таксама зададзены ў CRD, і выконваюць адпаведныя дзеянні па выніках параўнання. У прыватнасці, такая мадэль GitOps выкарыстоўваецца ў ArgoCD.

GitOps на платформе OpenShift

Адміністраванне мультыкластарнай Kubernetes-інфраструктуры

З распаўсюджваннем Kubernetes і ростам папулярнасці мультыхмарных стратэгій і перыферыйных вылічэнняў (edge computing) павялічваецца і сярэдняя колькасць кластараў OpenShift у разліку на аднаго заказчыка.

Напрыклад, пры выкарыстанні перыферыйных вылічэнняў кластары аднаго замоўца могуць разгортвацца сотнямі і нават тысячамі. У выніку ён змушаны кіраваць некалькімі незалежнымі ці ўзгодненымі кластарамі OpenShift у публічным воблаку і on-premise.

Пры гэтым даводзіцца вырашаць масу праблем, у прыватнасці:

Кантраляваць, што кластары знаходзяцца ў ідэнтычным стане (канфігі, маніторынг, сховішчы і г. д.)
Паўторна ствараць (ці аднаўляць) кластары па вядомым стане.
Ствараць новыя кластары па вядомым стане.
Накатваць змены на некалькіх кластарах OpenShift.
Адкочваць змен на некалькіх кластарах OpenShift.
Ўвязваць шаблонізаваныя канфігурацый з рознымі асяроддзямі.

Канфігурацыі прыкладання

Падчас свайго жыццёвага цыклу прыкладанні часта праходзяць праз ланцужок кластараў (dev, stage і т. д.), перш чым патрапіць у прадакшн-кластар. Акрамя таго, з-за патрабаванняў даступнасці і маштабаванасці заказчыкі часта разгортваюць прыкладанні адразу на некалькіх кластарах on-premise або ў некалькіх рэгіёнах публічнай хмарнай платформы.

Пры гэтым даводзіцца вырашаць наступныя задачы:

Забяспечваць рух прыкладанняў (бінарнікі, канфігі і т. д) паміж кластарам (dev, stage і т. д.).
Накатваць змены ў дадатках (бінарнікі, канфігі і г. д) у некалькіх кластарах OpenShift.
Адкочваць змены ў дадатках да ўзроўню папярэдняй вядомага стану.

Сцэнары выкарыстання OpenShift GitOps

1. Ужыванне змен з Git-рэпазітара

Адміністратар кластара можа захоўваць канфігурацыі кластара OpenShift у Git-рэпазітары і аўтаматычна ўжываць іх, каб без лішніх намаганняў ствараць новыя кластары і прыводзіць іх у стан, ідэнтычны вядомаму стану, якое захоўваецца ў Git-рэпазітары.

2. Сінхранізацыя з Secret Manager

Адміну таксама спатрэбіцца магчымасць сінхранізаваць secret-аб'екты OpenShift з якое адпавядае ПА накшталт Vault, каб кіраваць імі з дапамогай адмыслова створаных для гэтага прылад.

3. Кантроль дрыфту канфігурацый

Адмін будзе толькі за, калі OpenShift GitOps будзе сам выяўляць і папярэджваць аб разыходжаннях паміж рэальнымі канфігурацыямі і тымі, што зададзены ў рэпазітары, каб можна было аператыўна рэагаваць на дрыфце.

4. Апавяшчэнні аб дрыфце канфігурацый

Спатрэбяцца ў тым выпадку, калі адмін хоча аператыўна даведвацца пра выпадкі дрыфту канфігурацый, каб хутка прымаць адпаведныя меры самастойна.

5. Ручная сінхранізацыя канфігурацый пры дрыфце

Дазваляе адміну сінхранізаваць кластар OpenShift з рэпазітаром Git у выпадку дрыфту канфігурацый, каб хутка вярнуць кластар да папярэдняга вядомага стану.

6.Аўтасіхранізацыя канфігурацый пры дрыфце

Адмін таксама можа наладзіць кластар OpenShift на аўтаматычную сінхранізацыю з рэпазітаром пры выяўленні дрыфту, каб канфігурацыя кластара заўсёды адпавядала канфігамі ў Git'е.

7. Некалькі кластараў - адзін рэпазітар

Адмін можа захоўваць у адным рэпазітары Git канфігурацыі адразу некалькіх розных кластараў OpenShift і выбарачна ўжываць іх па меры патрэбы.

8. Іерархія кластарных канфігурацый (успадкоўванне)

Адмін можа задаць іерархію кластарных канфігурацый у рэпазітары (stage, prod, app portfolio і т. д з атрыманнем у спадчыну). Інакш кажучы, ён можа вызначаць, як павінны прымяняцца канфігурацыі - да аднаго або да некалькіх кластарам.

Напрыклад, калі адмін задае ў Git рэпазітары іерархію «Прадакшн кластары (prod) → Кластары сістэмы X → Прадакшн кластары сістэмы X», то да прадакшн-кластараў сістэмы X ужываецца аб'яднанне наступных канфігаў:

Канфігі, агульныя для ўсіх прадакшн-кластэраў.
Канфігі для кластара сістэмы X.
Канфігі для прадакшн-кластара сістэмы X.

9. Шаблоны і перавызначэнне канфігурацый

Адмін можа перавызначыць набор атрыманых у спадчыну канфігаў і іх значэнняў, напрыклад, каб танчэй наладзіць канфігурацыю для пэўных кластараў, да якога яны будуць прымяняцца.

10. Выбарчыя include'ы і exclude'ы для канфігурацый, канфігурацыі прыкладанняў

Адмін можа задаць умовы прымянення або непрымянення тых ці іншых канфігурацый да кластараў з пэўнымі характарыстыкамі.

11. Падтрымка шаблонаў

Распрацоўнікам спатрэбіцца магчымасць выбіраць, як будуць вызначацца рэсурсы прыкладання (Helm Chart, чысты Kubernetes'аўскі yaml і т. д), каб выкарыстоўваць найболей падыходны фармат для кожнага пэўнага прыкладання.

Інструменты GitOps на платформе OpenShift

ArgoCD

ArgoCD рэалізуе мадэль External Resource Reconcile і прапануе цэнтралізаваны UI для аркестрацыі адносін паміж кластарамі і Git-рэпазітарамі па схеме "адзін да многіх". Да недахопаў гэтай праграмы можна аднесці немагчымасць кіраваць праграмамі пры непрацуючым ArgoCD.

Афіцыйны сайт

Паток

Flux рэалізуе мадэль On-Cluster Resource Reconcile, і, як следства, тут няма цэнтралізаванага кіравання рэпазітаром азначэнняў, што з'яўляецца слабым месцам. З іншага боку, менавіта з-за адсутнасці цэнтралізацыі магчымасць кіраваць праграмамі захоўваецца і пры выхадзе са строю аднаго кластара.

Афіцыйны сайт

Ўстаноўка ArgoCD на OpenShift

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 Server, каб яго бачыў 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 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

Змена адмінскага пароля 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

Пасля выканання гэтых крокаў з ArgoCD Server можна працаваць праз вэб-кансоль ArgoCD WebUI або інструментар каманднага радка ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - ніколі не позна

«Цягнік сышоў» - так кажуць аб сітуацыі, калі магчымасць нешта зрабіць упушчана. У выпадку з OpenShift жаданне тут жа пачаць выкарыстоўваць гэтую новую класную платформу часта стварае менавіта такую сітуацыю з кіраваннем і абслугоўваннем маршрутаў, deployment'аў і іншых аб'ектаў OpenShift. Але ці заўсёды шанец канчаткова ўпушчаны?

Працягваючы серыю артыкулаў аб GitOps, сёння мы пакажам, як пераўтварыць створанае ўручную дадатак і яго рэсурсы ў нейкі працэс, дзе ўсім кіруе інструментар GitOps. Для гэтага мы спачатку рукамі разгорнем прыкладанне httpd. На скрыне ніжэй паказана, як мы ствараем прастору імёнаў, deployment і сэрвіс, а потым які робіцца expose для гэтага сэрвісу, каб стварыць маршрут.

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.
Уключаем ачыстку (pruning) і аўтасінхранізацыю аб'ектаў.

Як ужо гаварылася ў папярэдняй артыкуле, у GitOps ёсць адна і толькі адна крыніца звестак аб усіх аб'ектах у кластары(ах) Kubernetes – рэпазітар Git. Далей мы зыходзім з перадумовы, што ў вас у арганізацыі ўжо выкарыстоўваецца Git-рэпазітар. Ён можа быць публічным ці прыватным, але ён у абавязковым парадку павінен быць даступны кластарам Kubernetes. Гэта можа быць той жа самы рэпазітар, што і для кода прыкладанняў, ці ж асобны рэпазітар, створаны спецыяльна для deployment'ов. У рэпазітары рэкамендуецца мець строгія дазволы, паколькі там будуць захоўвацца аб'екты secret, маршруты і іншыя адчувальныя па бяспецы рэчы.

У нашым прыкладзе мы створым новы публічны рэпазітар на GitHub. Назваць яго можна як заўгодна, мы выкарыстоўваем імя blogpost.

Калі YAML-файлы аб'ектаў не захоўваліся лакальна або ў Git'е, то давядзецца скарыстацца бінарнікамі oc ці kubectl. На скрыне ніжэй мы запытваем YAML для нашага прасторы імёнаў, deployment'а, сэрвісу і маршруту. Перад гэтым мы кланавалі толькі што створаны рэпазітар і перайшлі ў яго камандай 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

Цяпер паправім файл deployment.yaml, каб выдаліць з яго поле, якое Argo CD не можа сінхранізаваць.

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 наша дадатак будзе мець статус "Out of Sync" (Не сінхранізавана), паколькі няма label-пазнакі, якую прастаўляе ArgoCD.
Менавіта таму, калі мы крыху пазней запусцім сінхранізацыю, паўторнае разгортванне аб'ектаў выконвацца не будзе.

Цяпер выканаем выпрабавальны запуск, каб пераканацца, што ў нашых файлах няма памылак.

argocd app sync simple-app --dry-run

Калі памылак няма, то можна пераходзіць да сінхранізацыі.

argocd app sync simple-app

Пасля выканання каманды argocd get над нашым дадаткам, мы павінны ўбачыць, што статус прыкладання змяніўся на Healthy (Спраўна) або Synced (Сінхранізавана). Гэта будзе азначаць, што ўсе рэсурсы ў рэпазітары 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.

Крыніца: habr.com

Уводзіны ў GitOps для OpenShift