Въведение в GitOps за OpenShift

Днес ще разгледаме принципите и моделите на GitOps, както и начина, по който тези модели се реализират на платформата OpenShift. Интерактивно ръководство по темата е налично. от връзката.

Накратко, GitOps е набор от практическите методи за управление на конфигурации на инфраструктурата и приложенията чрез pull-заявки на Git. Git хранилището в рамките на GitOps се разглежда като единственият източник на информация за състоянието на системата, като всяка промяна на това състояние е напълно проследима и подлежи на одит.

Идеята за проследимост на измененията в GitOps не е нова; такъв подход отдавна и практически навсякъде се използва при работа с изходния код на приложения. GitOps просто реализира подобни функции (прегледи, 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. Няколко клъстера – един репозиторий

Администраторът може да съхранява конфигурации на няколко различни клъстери OpenShift в един репозиторий Git и да ги прилага по избор, когато е необходимо.

8. Иерархия на клъстерни конфигурации (наследяване)

Администраторът може да зададе иерархия на клъстерните конфигурации в репозитория (stage, prod, app portfolio и т.н. с наследяване). С други думи, той може да определя как да се прилагат конфигурациите – към един или няколко клъстера.

Например, ако администраторът зададе в Git репозитория иерархия „Продукционни клъстери (prod) → Клъстери на система X → Продукционни клъстери на система X“, то при продуктонните клъстери на система X ще се приложат съвкупността от следните конфигурации:

• Конфигурации, общи за всички продукционни клъстери.
• Конфигурации за клъстера на система X.
• Конфигурации за продукционния клъстер на система X.

9. Шаблони и преопределение на конфигурации

Администраторът може да преопредели набора на наследени конфигурации и техните стойности, например, за да настрои по-точно конфигурацията за определени клъстери, в които ще се прилагат.

10. Избирателни включвания и изключвания за конфигурации, конфигурации на приложения

Администраторът може да зададе условия за прилагане или неприлагане на определени конфигурации към клъстери с определени характеристики.

11. Поддръжка на шаблони

Разработчиците ще оценят възможността да избират как ще се определят ресурсите на приложението (Helm Chart, чист Kubernetes yaml и т.н.), за да използват най-подходящия формат за всяко конкретно приложение.

Инструменти GitOps на платформата OpenShift

ArgoCD

ArgoCD реализира модела External Resource Reconcile и предлага централизирано UI за оркестрация на отношенията между кластерите и Git хранилищата по схема "едно към много". Сред недостатъците на тази програма е невъзможността да се управляват приложения при неработещо ArgoCD.

Официален сайт

Flux

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. Това може да бъде същият репозиторий, който се използва за кода на приложенията, или отделен репозиторий, създаден специално за разгръщания. В репозитория е желателно да има строги разрешения, тъй като там ще се съхраняват обекти 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:        
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

А сега вече можем да активираме автоматичната синхронизация и почистването, за да гарантираме, че нещо няма да бъде създадено ръчно и че всеки път, когато обект бъде създаден или обновен в репозиториото, ще се извършва разполагане.

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

И така, успешно преминахме към управление на приложението с GitOps, което първоначално не използваше GitOps.

Източник: habr.com