Вовед во GitOps за OpenShift

Денес ќе зборуваме за принципите и моделите на GitOps, како и за тоа како овие модели се имплементираат на платформата OpenShift. Достапен е интерактивен водич на оваа тема по ссылке.

Накратко, GitOps е збир на практики за користење Git pull барања за управување со инфраструктура и конфигурации на апликации. Складиштето на Git во GitOps се третира како единствен извор на информации за состојбата на системот и сите промени во оваа состојба се целосно следени и ревидирани.

Идејата за следење промени во GitOps во никој случај не е нова; овој пристап долго време се користи речиси универзално кога се работи со изворниот код на апликацијата. GitOps едноставно имплементира слични карактеристики (прегледи, барања за повлекување, ознаки итн.) во управувањето со инфраструктурата и конфигурацијата на апликациите и обезбедува слични придобивки како во случајот со управувањето со изворниот код.

Не постои академска дефиниција или одобрен сет на правила за GitOps, само збир на принципи на кои е изградена оваа практика:

• Декларативниот опис на системот се чува во складиштето Git (конфигурации, мониторинг, итн.).
• Промените на состојбата се прават преку барања за повлекување.
• Состојбата на активните системи се усогласува со податоците во складиштето со помош на Git push барања.

Принципи на GitOps

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

Системската конфигурација се третира како код за да може да се складира и автоматски да се верзира во складиштето на Git, кое служи како единствен извор на вистината. Овој пристап го олеснува воведувањето и враќањето на промените во системите.

• Посакуваната состојба и конфигурација на системите се поставени и верзирани во Git

Со складирање и верзија на посакуваната состојба на системите во Git, можеме лесно да ги воведеме и вратиме промените во системите и апликациите. Можеме да ги користиме и безбедносните механизми на Git за да ја контролираме сопственоста на кодот и да ја потврдиме неговата автентичност.

• Промените во конфигурацијата може автоматски да се применат преку барања за повлекување

Користејќи ги барањата за повлекување на Git, можеме лесно да контролираме како се применуваат промените на конфигурациите во складиштето. На пример, тие може да се дадат на други членови на тимот за преглед или да се извршат преку CI тестови, итн.

И во исто време, нема потреба да се дистрибуираат административни овластувања лево и десно. За да извршат промени во конфигурацијата, на корисниците им требаат само соодветни дозволи во складиштето Git каде што се зачувани тие конфигурации.

• Поправање на проблемот со неконтролирано движење на конфигурации

Штом саканата состојба на системот ќе се зачува во складиштето на Git, сè што треба да направиме е да најдеме софтвер кој ќе осигура дека моменталната состојба на системот се совпаѓа со неговата посакувана состојба. Ако ова не е случај, тогаш овој софтвер треба - во зависност од поставките - или сам да го елиминира несовпаѓањето или да не извести за префрлање на конфигурацијата.

GitOps модели за OpenShift

Премирувач на ресурси на кластерот

Според овој модел, кластерот има контролер кој е одговорен за споредба на ресурсите на Kubernetes (YAML датотеки) во складиштето Git со реалните ресурси на кластерот. Ако се откријат несовпаѓања, контролорот испраќа известувања и евентуално презема мерки за да ги исправи несовпаѓањата. Овој модел на GitOps се користи во Anthos Config Management и Weaveworks Flux.

Помирувач на надворешни ресурси (Push)

Овој модел може да се смета како варијација на претходниот, кога имаме еден или повеќе контролори одговорни за синхронизирање на ресурсите во паровите „Репозиториум Git - кластер Кубернетес“. Разликата овде е во тоа што секој управуван кластер не мора да има свој посебен контролер. Паровите кластери Git - k8s често се дефинираат како CRD (прилагодени дефиниции за ресурси), што може да опише како контролорот треба да изврши синхронизација. Во рамките на овој модел, контролорите го споредуваат складиштето Git наведено во CRD со ресурсите на кластерот Kubernetes, кои исто така се наведени во CRD, и вршат соодветни дејства врз основа на резултатите од споредбата. Конкретно, овој модел на GitOps се користи во ArgoCD.

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

Администрација на мулти-кластер Kubernetes инфраструктура

Со ширењето на Kubernetes и зголемената популарност на стратегиите за повеќе облак и пресметување на работ, се зголемува и просечниот број на OpenShift кластери по клиент.

На пример, кога се користи рабното пресметување, кластерите на еден клиент може да се распоредат во стотици или дури илјадници. Како резултат на тоа, тој е принуден да управува со неколку независни или координирани OpenShift кластери во јавниот облак и во просториите.

Во овој случај, треба да се решат многу проблеми, особено:

• Контролирајте дека кластерите се во идентична состојба (конфигурации, следење, складирање, итн.)
• Повторно креирајте (или обновете) кластери врз основа на позната состојба.
• Создадете нови кластери врз основа на позната состојба.
• Воведи промени во повеќе OpenShift кластери.
• Врати ги промените низ повеќе OpenShift кластери.
• Поврзете шаблони конфигурации со различни средини.

Конфигурации на апликацијата

За време на нивниот животен циклус, апликациите често минуваат низ синџир на кластери (dev, stage, итн.) пред да завршат во производствен кластер. Дополнително, поради барањата за достапност и приспособливост, клиентите често распоредуваат апликации низ повеќе кластери во просториите или повеќе региони на јавна облак платформа.

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

• Обезбедете движење на апликациите (бинарни, конфигурации, итн.) помеѓу кластерите (dev, фаза, итн.).
• Воведи промени во апликациите (бинарни, конфигурации, итн.) во неколку OpenShift кластери.
• Врати ги промените на апликациите во претходната позната состојба.

Случаи за употреба на OpenShift GitOps

1. Примена на промени од складиштето Git

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

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

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

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

Администраторот ќе биде за само доколку самиот OpenShift GitOps идентификува и предупреди за несовпаѓања помеѓу реалните конфигурации и оние наведени во складиштето, за да можат брзо да одговорат на drift.

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

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

5. Рачна синхронизација на конфигурации при лебдење

Дозволува администраторот да го синхронизира кластерот OpenShift со складиштето Git во случај на префрлање на конфигурацијата, за брзо враќање на кластерот во претходната позната состојба.

6.Автоматска синхронизација на конфигурации при лебдење

Администраторот исто така може да го конфигурира кластерот OpenShift за автоматско синхронизирање со складиштето кога ќе се открие дрифт, така што конфигурацијата на кластерот секогаш се совпаѓа со конфигурациите во Git.

7. Неколку кластери - едно складиште

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

8. Хиерархија на конфигурации на кластери (наследување)

Администраторот може да постави хиерархија на конфигурации на кластери во складиштето (фаза, прод, портфолио на апликации итн. со наследство). Со други зборови, може да определи дали конфигурациите треба да се применат на еден или повеќе кластери.

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

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

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

Администраторот може да отфрли сет на наследени конфигурации и нивните вредности, на пример, за фино да ја прилагоди конфигурацијата за одредени кластери на кои ќе се применат.

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

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

11. Поддршка за шаблон

Програмерите ќе имаат корист од можноста да изберат како ќе се дефинираат ресурсите на апликацијата (Хелм табела, чист Kubernetes yaml, итн.) со цел да го користат најсоодветниот формат за секоја специфична апликација.

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

ArgoCD

ArgoCD го имплементира моделот External Resource Reconcile и нуди централизиран интерфејс за оркестрирање на врски еден-на-многу помеѓу кластерите и складиштата на 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 за да може да се види преку 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 има еден и единствен извор на информации за сите објекти во кластерот(ите) Кубернетес - складиштето 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

Сега ајде да ја уредиме датотеката 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, комплетот со алатки започнува да ги проверува веќе распоредените објекти во однос на дефинициите во складиштето. Во нашиот пример, автоматската синхронизација и чистење се оневозможени, така што елементите сè уште не се менуваат. Ве молиме имајте предвид дека во интерфејсот на Argo CD нашата апликација ќе има статус „Out of Sync“ бидејќи не постои ознака што ја обезбедува 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 на кој било начин.

Извор: www.habr.com