Увод у ГитОпс за ОпенСхифт

Данас ћемо говорити о принципима и моделима ГитОпс-а, ​​као ио томе како се ови модели имплементирају на ОпенСхифт платформи. Доступан је интерактивни водич на ову тему по ссылке.

Укратко, ГитОпс је скуп пракси за коришћење Гит захтева за повлачењем за управљање инфраструктуром и конфигурацијама апликација. Гит спремиште у ГитОпс-у се третира као један извор информација о стању система, а све промене овог стања су у потпуности праћене и ревидиране.

Идеја праћења промена у ГитОпс-у никако није нова; овај приступ се већ дуго користи скоро универзално када се ради са изворним кодом апликације. ГитОпс једноставно имплементира сличне функције (рецензије, захтеви за повлачење, ознаке, итд.) у управљању инфраструктуром и конфигурацијом апликација и пружа сличне предности као у случају управљања изворним кодом.

Не постоји академска дефиниција или одобрен скуп правила за ГитОпс, већ само скуп принципа на којима је ова пракса изграђена:

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

ГитОпс принципи

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

Конфигурација система се третира као код тако да се може ускладиштити и аутоматски верзионисати у Гит спремишту, које служи као једини извор истине. Овај приступ олакшава увођење и враћање промена у системима.

• Жељено стање и конфигурација система су постављени и верзионисани у Гиту

Чувањем и верзионисањем жељеног стања система у Гиту, можемо лако да уведемо и вратимо промене у системе и апликације. Такође можемо да користимо Гит-ове безбедносне механизме за контролу власништва кода и проверу његове аутентичности.

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

Коришћењем Гит захтева за повлачењем, можемо лако да контролишемо како се промене примењују на конфигурације у спремишту. На пример, могу се дати другим члановима тима на преглед или проћи кроз ЦИ тестове итд.

А у исто време, нема потребе да се администраторска овлашћења расподељују лево и десно. Да би извршили промене конфигурације, корисницима су потребне само одговарајуће дозволе у ​​Гит спремишту где се те конфигурације чувају.

• Решавање проблема неконтролисаног померања конфигурација

Када се жељено стање система ускладишти у Гит спремишту, све што треба да урадимо је да пронађемо софтвер који ће обезбедити да тренутно стање система одговара његовом жељеном стању. Ако то није случај, онда би овај софтвер требало да – у зависности од подешавања – или сам елиминише неслагање, или да нас обавести о промени конфигурације.

ГитОпс модели за ОпенСхифт

Он-Цлустер Ресоурце Рецонцилер

Према овом моделу, кластер има контролер који је одговоран за упоређивање Кубернетес ресурса (ИАМЛ датотека) у Гит спремишту са стварним ресурсима кластера. Ако се открију неслагања, контролор шаље обавештења и евентуално предузима мере да исправи неслагања. Овај ГитОпс модел се користи у Антхос Цонфиг Манагемент-у и Веавеворкс Флук-у.

Рецонцилер спољних ресурса (пусх)

Овај модел се може сматрати варијацијом претходног, када имамо један или више контролера одговорних за синхронизацију ресурса у паровима „Гит репозиторијум - Кубернетес кластер”. Разлика је у томе што сваки управљани кластер не мора нужно имати свој посебан контролер. Гит - к8с парови кластера се често дефинишу као ЦРД (прилагођене дефиниције ресурса), који могу описати како контролер треба да изврши синхронизацију. У оквиру овог модела, контролори упоређују Гит спремиште наведено у ЦРД-у са ресурсима Кубернетес кластера, који су такође наведени у ЦРД-у, и извршавају одговарајуће акције на основу резултата поређења. Конкретно, овај ГитОпс модел се користи у АргоЦД-у.

ГитОпс на ОпенСхифт платформи

Администрација вишекластера Кубернетес инфраструктуре

Са ширењем Кубернетес-а и растућом популарношћу мулти-цлоуд стратегија и рачунарства на ивици, просечан број ОпенСхифт кластера по кориснику се такође повећава.

На пример, када се користи ивично рачунарство, кластери једног корисника могу бити распоређени на стотине или чак хиљаде. Као резултат тога, он је приморан да управља неколико независних или координисаних ОпенСхифт кластера у јавном облаку и на локалном нивоу.

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

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

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

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

У овом случају треба решити следеће задатке:

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

ОпенСхифт ГитОпс случајеви употребе

1. Примена промена из Гит спремишта

Администратор кластера може да складишти ОпенСхифт конфигурације кластера у Гит спремиште и аутоматски их примени да би без напора креирао нове кластере и довео их у стање идентично познатом стању ускладиштеном у Гит спремишту.

2. Синхронизација са Сецрет Манагер-ом

Администратор ће такође имати користи од могућности да синхронизује ОпенСхифт тајне објекте са одговарајућим софтвером као што је Ваулт како би управљао њима помоћу алата посебно креираних за ово.

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

Администратор ће бити за само ако ОпенСхифт ГитОпс сам идентификује и упозори на неслагање између стварних конфигурација и оних наведених у спремишту, тако да могу брзо да реагују на померање.

4. Обавештења о промени конфигурације

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

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

Дозвољава администратору да синхронизује ОпенСхифт кластер са Гит репозиторијумом у случају промене конфигурације, како би брзо вратио кластер у претходно познато стање.

6.Ауто-синхронизација конфигурација при дрифту

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

7. Неколико кластера – једно спремиште

Администратор може да складишти конфигурације неколико различитих ОпенСхифт кластера у једном Гит спремишту и да их селективно примењује по потреби.

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

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

На пример, ако администратор постави хијерархију „Производни кластери (прод) → Систем Кс кластери → Производни кластери система Кс” у Гит спремишту, онда се комбинација следећих конфигурација примењује на производне кластере система Кс:

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

9. Шаблони и замене конфигурације

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

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

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

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

Програмери ће имати користи од могућности да изаберу како ће се ресурси апликације дефинисати (Хелм Цхарт, чисти Кубернетес иамл, итд.) како би користили најприкладнији формат за сваку специфичну апликацију.

ГитОпс алати на ОпенСхифт платформи

АргоЦД

АргоЦД имплементира модел помирења екстерних ресурса и нуди централизовани кориснички интерфејс за оркестрирање односа један-према-више између кластера и Гит спремишта. Недостаци овог програма укључују немогућност управљања апликацијама када АргоЦД не ради.

Званични сајт

Флукс

Флук имплементира он-Цлустер Ресоурце Рецонциле модел и, као резултат, не постоји централизовано управљање спремиштем дефиниција, што је слаба тачка. С друге стране, управо због недостатка централизације, могућност управљања апликацијама остаје чак и ако један кластер закаже.

Званични сајт

Инсталирање АргоЦД-а на ОпенСхифт

АргоЦД нуди одличан интерфејс командне линије и веб конзолу, тако да овде нећемо покривати Флук и друге алтернативе.

Да бисте применили АргоЦД на ОпенСхифт 4 платформи, пратите ове кораке као администратор кластера:

Примена АргоЦД компоненти на ОпенСхифт платформи

# 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}')

Побољшање АргоЦД сервера тако да га може видети ОпенСхифт Роуте

# 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

Примена АргоЦД Цли алата

# 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

Промена лозинке администратора АргоЦД сервера

# 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

Након што завршите ове кораке, можете да радите са АргоЦД сервером преко АргоЦД ВебУИ веб конзоле или АргоЦД Цли алата командне линије.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

ГитОпс - Никад није касно

„Воз је отишао“ - тако кажу о ситуацији када је прилика да се нешто уради пропуштена. У случају ОпенСхифт-а, жеља да се одмах почне да користи ову цоол нову платформу често ствара управо ову ситуацију са управљањем и одржавањем рута, имплементација и других ОпенСхифт објеката. Али да ли је шанса увек потпуно изгубљена?

Настављајући серију чланака о ГитОпс, данас ћемо вам показати како да трансформишете ручно израђену апликацију и њене ресурсе у процес у коме се свиме управља помоћу ГитОпс алата. Да бисмо то урадили, прво ћемо ручно применити хттпд апликацију. Снимак екрана испод показује како креирамо именски простор, примену и услугу, а затим излажемо ову услугу да бисмо направили руту.

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

Дакле, имамо ручно израђену апликацију. Сада га треба пренети под управљање ГитОпс-ом без губитка доступности. Укратко, ради ово:

• Направите Гит спремиште за код.
• Извозимо наше тренутне објекте и отпремамо их у Гит спремиште.
• Избор и примена ГитОпс алата.
• Ми додајемо наше спремиште овом комплету алата.
• Дефинишемо апликацију у нашем ГитОпс комплету алата.
• Изводимо пробно покретање апликације користећи ГитОпс алат.
• Синхронизујемо објекте помоћу ГитОпс алата.
• Омогућите обрезивање и аутоматску синхронизацију објеката.

Као што је већ поменуто у претходном Чланак, у ГитОпс-у постоји један и једини извор информација о свим објектима у Кубернетес кластеру(има) - Гит спремиште. Затим полазимо од претпоставке да ваша организација већ користи Гит спремиште. Може бити јавна или приватна, али мора бити доступна Кубернетес кластерима. Ово може бити исто спремиште као за код апликације или засебно спремиште креирано посебно за примену. Препоручује се да имате строге дозволе у ​​спремишту јер ће се тајне, руте и друге безбедносно осетљиве ствари чувати тамо.

У нашем примеру, направићемо ново јавно спремиште на ГитХуб-у. Можете га назвати како год желите, ми користимо име блогпост.

Ако ИАМЛ објектне датотеке нису ускладиштене локално или у Гиту, онда ћете морати да користите оц или кубецтл бинарне датотеке. На слици испод захтевамо ИАМЛ за наш именски простор, примену, услугу и руту. Пре тога, клонирали смо новостворено спремиште и ЦД у њега.

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

Сада уредимо датотеку деплоимент.иамл да уклонимо поље које Арго ЦД не може да синхронизује.

sed -i '/sgeneration: .*/d' deployment.yaml

Поред тога, потребно је променити руту. Прво ћемо поставити вишелинијску променљиву, а затим заменити ингресс: нулл садржајем те променљиве.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

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

git commit -am ‘initial commit of objects’
git push origin master

Даље полазимо од чињенице да сте већ поставили АргоЦД (како то учинити - погледајте претходни брзо). Стога ћемо на Арго ЦД додати спремиште које смо креирали, које садржи код апликације из нашег примера. Само се уверите да сте навели тачно складиште које сте креирали раније.

argocd repo add https://github.com/cooktheryan/blogpost

Сада креирајмо апликацију. Апликација поставља вредности тако да ГитОпс алатка разуме које спремиште и путање да користи, који је ОпенСхифт потребан за управљање објектима, која је специфична грана спремишта потребна и да ли ресурси треба да се аутоматски синхронизују.

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

Једном када је апликација наведена на Арго ЦД-у, комплет алата почиње да проверава већ распоређене објекте у односу на дефиниције у спремишту. У нашем примеру, аутоматска синхронизација и чишћење су онемогућени, тако да се елементи још увек не мењају. Имајте на уму да ће у интерфејсу Арго ЦД-а наша апликација имати статус „Оут оф Синц“ јер не постоји ознака коју АргоЦД обезбеђује.
Због тога, када мало касније започнемо синхронизацију, објекти неће бити поново распоређени.

Хајде сада да урадимо пробни рад да бисмо се уверили да нема грешака у нашим датотекама.

argocd app sync simple-app --dry-run

Ако нема грешака, можете наставити са синхронизацијом.

argocd app sync simple-app

Након што покренемо команду аргоцд гет на нашој апликацији, требало би да видимо да се статус апликације променио у Здрава или Синхронизована. То ће значити да сви ресурси у Гит спремишту сада одговарају оним ресурсима који су већ распоређени.

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

Дакле, успешно смо ставили апликацију под ГитОпс контролу која у почетку није ни на који начин користила ГитОпс.

Извор: ввв.хабр.цом