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

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

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

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

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

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

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

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

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

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

ArgoCD

ArgoCD реализира модел на външно съгласуване на ресурси и предлага централизирано UI за организиране на отношенията между клъстери и Git-репозитории по схемата „едно към много“. Недостатък на тази програма е невъзможността за управление на приложенията при неработещ ArgoCD.

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

Flux

Flux реализира модел на съгласуване на ресурси в клъстера и поради това няма централизирано управление на репозиториите с дефиниции, което е слабата страна. От друга страна, именно поради липсата на централизация, възможността за управление на приложенията остава дори когато един клъстер е извън строя.

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

Инсталиране на 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

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

Продължавайки серията статии за GitOps, днес ще покажем как да трансформираме приложението, създадено ръчно, и ресурсите му в процес, при който всичко се управлява от инструмента на GitOps. За целта първо ще разположим приложението httpd ръчно. На екрана по-долу е показано как създаваме пространство за имена, деплоймент и услуга, а след това правим 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" (Не синхронизирано), тъй като няма metки, които 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