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

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

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

Идеята за проследяване на промените в GitOps в никакъв случай не е нова; този подход отдавна се използва почти универсално при работа с изходния код на приложението. GitOps просто прилага подобни функции (ревюта, заявки за изтегляне, тагове и т.н.) в инфраструктурата и управлението на конфигурацията на приложенията и предоставя подобни предимства, както в случая с управлението на изходния код.

Няма академична дефиниция или одобрен набор от правила за GitOps, а само набор от принципи, върху които е изградена тази практика:

• Декларативното описание на системата се съхранява в хранилището на Git (конфигурации, мониторинг и т.н.).
• Промените в състоянието се правят чрез заявки за изтегляне.
• Състоянието на работещите системи се привежда в съответствие с данните в хранилището с помощта на Git push заявки.

Принципи на GitOps

• Системните дефиниции са описани като изходен код

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

• Желаното състояние и конфигурация на системите се задават и управляват в Git

Чрез съхраняване и създаване на версии на желаното състояние на системите в Git, ние сме в състояние лесно да внедряваме и връщаме обратно промените в системите и приложенията. Можем също да използваме механизмите за сигурност на Git, за да контролираме собствеността върху кода и да проверяваме неговата автентичност.

• Промените в конфигурацията могат да се прилагат автоматично чрез заявки за изтегляне

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

И в същото време няма нужда да разпределяте администраторски правомощия наляво и надясно. За да извършат промени в конфигурацията, потребителите се нуждаят само от подходящи разрешения в Git хранилището, където се съхраняват тези конфигурации.

• Коригиране на проблема с неконтролираното отклонение на конфигурациите

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

GitOps модели за OpenShift

On-Cluster Resource Reconciler

Според този модел клъстерът има контролер, който отговаря за сравняването на ресурсите на Kubernetes (YAML файлове) в Git хранилището с реалните ресурси на клъстера. Ако се установят несъответствия, администраторът изпраща известия и евентуално предприема действия за коригиране на несъответствията. Този модел GitOps се използва в Anthos Config Management и Weaveworks Flux.

Съгласувател на външни ресурси (Push)

Този модел може да се разглежда като вариант на предишния, когато имаме един или повече контролери, отговорни за синхронизирането на ресурсите в двойките „Git repository - Kubernetes cluster“. Разликата тук е, че всеки управляван клъстер не е задължително да има свой отделен контролер. Git - k8s клъстерните двойки често се определят като CRD (персонализирани дефиниции на ресурси), които могат да опишат как контролерът трябва да извършва синхронизация. В рамките на този модел контролерите сравняват Git хранилището, посочено в CRD, с ресурсите на клъстера Kubernetes, които също са посочени в CRD, и извършват подходящи действия въз основа на резултатите от сравнението. По-специално, този модел GitOps се използва в ArgoCD.

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

Администриране на мултиклъстерна инфраструктура на Kubernetes

С разпространението на Kubernetes и нарастващата популярност на мулти-облачните стратегии и крайните изчисления, средният брой OpenShift клъстери на клиент също се увеличава.

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

В този случай трябва да се решат много проблеми, по-специално:

• Контролирайте клъстерите да са в идентично състояние (конфигурации, наблюдение, съхранение и т.н.)
• Създаване наново (или възстановяване) на клъстери въз основа на известно състояние.
• Създайте нови клъстери въз основа на известно състояние.
• Разпространете промени в множество OpenShift клъстери.
• Върнете назад промените в множество OpenShift клъстери.
• Свържете шаблонни конфигурации с различни среди.

Конфигурации на приложението

По време на своя жизнен цикъл приложенията често преминават през верига от клъстери (dev, stage и т.н.), преди да попаднат в производствен клъстер. В допълнение, поради изискванията за наличност и мащабируемост, клиентите често внедряват приложения в множество локални клъстери или множество региони на публична облачна платформа.

В този случай трябва да се решат следните задачи:

• Осигурете движението на приложения (двоични файлове, конфигурации и т.н.) между клъстери (dev, stage и т.н.).
• Разпространете промени в приложения (двоични файлове, конфигурации и т.н.) в няколко OpenShift клъстера.
• Върнете промените в приложенията до предишно известно състояние.

Случаи на използване на OpenShift GitOps

1. Прилагане на промени от Git хранилището

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

2. Синхронизация с Secret Manager

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

3. Контрол на конфигурациите на дрейфа

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

4. Известия за отклонение в конфигурацията

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

5. Ръчна синхронизация на конфигурациите при дрифт

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

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

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

7. Няколко клъстера - едно хранилище

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

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

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

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

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

9. Шаблони и настройки на конфигурацията

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

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

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

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

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

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

ArgoCD

ArgoCD прилага модела External Reconcile Reconcile и предлага централизиран потребителски интерфейс за оркестриране на връзки "един към много" между клъстери и 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 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

# 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 приложението. Екранната снимка по-долу показва как създаваме пространство от имена, внедряване и услуга и след това излагаме тази услуга, за да създадем маршрут.

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

Сега нека редактираме файла 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 нашето приложение ще има статус „Извън синхронизация“, тъй като няма етикет, който 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