OpenShift үчүн GitOps менен таанышуу

Бүгүн биз GitOps принциптери жана моделдери, ошондой эле бул моделдер OpenShift платформасында кантип ишке ашырылып жаткандыгы жөнүндө сүйлөшөбүз. Бул тема боюнча интерактивдүү колдонмо бар байланыш.

Кыскача айтканда, GitOps инфраструктураны жана колдонмо конфигурацияларын башкаруу үчүн Git тартуу сурамдарын колдонуу практикаларынын жыйындысы. GitOps ичиндеги Git репозиторийси системанын абалы жөнүндө маалыматтын бирдиктүү булагы катары каралат жана бул абалга болгон бардык өзгөртүүлөр толугу менен байкалып, текшерилет.

GitOps'те өзгөрүүлөргө көз салуу идеясы эч кандай жаңы эмес; бул ыкма колдонмонун баштапкы коду менен иштөөдө көптөн бери дээрлик универсалдуу колдонулат. GitOps жөн гана инфраструктураны жана колдонмо конфигурациясын башкарууда окшош функцияларды (карап чыгуулар, тартуу сурамдары, тэгдер ж.б.) ишке ашырат жана баштапкы кодду башкаруудагыдай эле артыкчылыктарды берет.

GitOps үчүн академиялык аныктама же бекитилген эрежелер топтому жок, бул практика курулган принциптердин жыйындысы гана:

• Системанын декларативдик сыпаттамасы Git репозиторийинде сакталат (конфигурациялар, мониторинг ж.б.).
• Мамлекеттик өзгөртүүлөр тартуу сурамдары аркылуу жүргүзүлөт.
• Иштеп жаткан системалардын абалы Git push өтүнүчтөрүн колдонуу менен репозиторийдеги маалыматтарга ылайык келтирилет.

GitOps принциптери

• Системанын аныктамалары баштапкы код катары сүрөттөлөт

Системанын конфигурациясы код катары каралат, ошондуктан аны Git репозиторийинде сактоо жана автоматтык түрдө версиялоо мүмкүн, ал чындыктын бирдиктүү булагы катары кызмат кылат. Бул ыкма системалардагы өзгөртүүлөрдү киргизүүнү жана кайра кайтарууну жеңилдетет.

• Системанын керектүү абалы жана конфигурациясы Gitте орнотулган жана версияланган

Гитте тутумдардын каалаган абалын сактоо жана версиялоо менен биз системаларга жана тиркемелерге өзгөртүүлөрдү оңой чыгарып, кайра кайтара алабыз. Ошондой эле Gitтин коопсуздук механизмдерин кодго ээлик кылууну көзөмөлдөө жана анын аныктыгын текшерүү үчүн колдоно алабыз.

• Конфигурациянын өзгөрүүлөрү тартуу сурамдары аркылуу автоматтык түрдө колдонулушу мүмкүн

Git тартуу өтүнүчтөрүн колдонуу менен биз репозиторийдеги конфигурацияларга өзгөртүүлөр кандайча колдонуларын оңой көзөмөлдөй алабыз. Мисалы, алар башка команда мүчөлөрүнө кароо үчүн берилиши мүмкүн же CI тесттери аркылуу ж.б.

Ошол эле учурда административдик ыйгарым укуктарды оңго жана солго бөлүштүрүүнүн кереги жок. Конфигурацияга өзгөртүүлөрдү киргизүү үчүн колдонуучуларга ошол конфигурациялар сакталган Git репозиторийинде тиешелүү уруксаттар гана керек.

• Конфигурациялардын башкарылбаган дрейфинин көйгөйүн чечүү

Системанын керектүү абалы Git репозиторийинде сакталгандан кийин, системанын учурдагы абалы анын каалаган абалына дал келишин камсыздай турган программалык камсыздоону табышыбыз керек. Эгер андай болбосо, анда бул программалык камсыздоо - орнотууларга жараша - же өз алдынча дал келбөөчүлүктү жок кылышы керек, же конфигурациянын дрейфи жөнүндө бизге кабарлашы керек.

OpenShift үчүн GitOps моделдери

Кластердеги ресурсту элдештирүүчү

Бул моделге ылайык, кластерде Git репозиторийиндеги Kubernetes ресурстарын (YAML файлдары) кластердин реалдуу ресурстары менен салыштыруу үчүн жооптуу контроллер бар. Эгерде дал келбестиктер аныкталса, контролер эскертмелерди жөнөтөт жана мүмкүн болгон айырмачылыктарды оңдоо үчүн чара көрөт. Бул GitOps модели Anthos Config Management жана Weaveworks Fluxте колдонулат.

Тышкы ресурсту элдештирүүчү (түртүү)

"Git репозиторий - Kubernetes кластери" жуптарындагы ресурстарды синхрондоштуруу үчүн жооптуу бир же бир нече контроллерлор болгондо, бул модель мурунку моделдин вариациясы катары каралышы мүмкүн. Бул жердеги айырма, ар бир башкарылуучу кластер сөзсүз түрдө өзүнүн өзүнчө контроллерине ээ эмес. Git - k8s кластердик түгөйлөрү көбүнчө CRD (өздүк ресурстун аныктамалары) катары аныкталат, алар контролер синхрондоштурууну кантип аткарышы керектигин сүрөттөй алат. Бул моделдин алкагында контроллерлор CRDде көрсөтүлгөн Git репозиторийин CRDде да көрсөтүлгөн Kubernetes кластер ресурстары менен салыштырышат жана салыштыруунун жыйынтыгы боюнча тиешелүү аракеттерди аткарышат. Атап айтканда, бул GitOps модели ArgoCDде колдонулат.

OpenShift платформасында GitOps

Көп кластерлүү Kubernetes инфраструктурасын башкаруу

Kubernetesтин жайылышы жана көп булуттуу стратегиялардын жана четки эсептөөлөрдүн популярдуулугу өскөн сайын, OpenShift кластерлеринин бир кардарга орточо саны да көбөйүүдө.

Мисалы, кырдуу эсептөөлөрдү колдонууда, бир кардардын кластерлери жүздөгөн, атүгүл миңдегенде жайгаштырылышы мүмкүн. Натыйжада, ал коомдук булуттагы жана жергиликтүү бир нече көз карандысыз же макулдашылган OpenShift кластерлерин башкарууга аргасыз болот.

Бул учурда, бир топ көйгөйлөрдү чечүү керек, атап айтканда:

• Кластерлердин бирдей абалда экендигин көзөмөлдөө (конфигурациялар, мониторинг, сактоо ж.б.)
• Белгилүү абалдын негизинде кластерлерди кайра түзүү (же калыбына келтирүү).
• Белгилүү абалдын негизинде жаңы кластерлерди түзүңүз.
• Бир нече OpenShift кластерлерине өзгөртүүлөрдү жайылтыңыз.
• Бир нече OpenShift кластериндеги өзгөрүүлөрдү артка кайтарыңыз.
• Калыпталган конфигурацияларды ар кандай чөйрөлөргө байланыштырыңыз.

Колдонмо конфигурациялары

Өндүрүш кластеринде аяктаганга чейин тиркемелер көп учурда кластерлердин чынжырынан (иштеп чыгуучу, этап ж.б.) өтүшөт. Кошумчалай кетсек, жеткиликтүүлүк жана масштабдуу талаптардан улам, кардарлар көбүнчө тиркемелерди бир нече жергиликтүү кластерлерде же коомдук булут платформасынын бир нече аймактарында жайгаштырышат.

Бул учурда, төмөнкү милдеттерди чечүү керек:

• Кластерлердин (дев, этап ж.б.) ортосунда тиркемелердин (экилик, конфигурациялар ж.
• Бир нече OpenShift кластерлеринде тиркемелерди (экилик, конфигурациялар ж.б.) өзгөртүүнү жайылтыңыз.
• Колдонмолордогу өзгөрүүлөрдү мурунку белгилүү абалга кайтарыңыз.

OpenShift GitOps колдонуу учурлары

1. Git репозиторийинен өзгөртүүлөрдү колдонуу

Кластердин администратору OpenShift кластер конфигурацияларын Git репозиторийинде сактай алат жана аларды автоматтык түрдө жаңы кластерлерди оңой түзүү жана Git репозиторийинде сакталган белгилүү абалга окшош абалга келтирүү үчүн колдоно алат.

2. Жашыруун менеджер менен синхрондоштуруу

Администратор ошондой эле OpenShift жашыруун объектилерин Vault сыяктуу тиешелүү программалык камсыздоо менен синхрондоштуруу мүмкүнчүлүгүнөн пайда көрөт, аларды бул үчүн атайын түзүлгөн куралдар менен башкаруу.

3. Дрейфтин конфигурацияларын башкаруу

Эгерде OpenShift GitOps өзү репозиторийдеги конфигурациялар менен репозиторийде көрсөтүлгөндөрдүн ортосундагы айырмачылыктарды аныктап, эскертсе, администратор дрейфке тез жооп бериши үчүн гана колдойт.

4. Конфигурациянын дрейфи жөнүндө эскертмелер

Алар администратор тез арада өз алдынча тиешелүү чараларды көрүү үчүн конфигурациянын дрейфинин учурлары жөнүндө тез билгиси келген учурда пайдалуу.

5. Дрейфинг учурунда конфигурацияларды кол менен синхрондоштуруу

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

6.Дрифтинг учурунда конфигурацияларды автоматтык түрдө синхрондоштуруу

Администратор ошондой эле OpenShift кластерин дрейф аныкталганда репозиторий менен автоматтык түрдө синхрондоштуруу үчүн конфигурациялай алат, андыктан кластердин конфигурациясы дайыма Gitтеги конфигурацияларга дал келет.

7. Бир нече кластерлер – бир репозиторий

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

8. Кластердик конфигурациялардын иерархиясы (мурас алуу)

Администратор репозиторийдеги кластер конфигурацияларынын иерархиясын орното алат (этап, прод, колдонмо портфолиосу, ж.б. мурас менен). Башкача айтканда, конфигурациялар бир же бир нече кластерлерге колдонулушу керекпи же жокпу аныктай алат.

Мисалы, эгерде администратор Git репозиторийинде “Өндүрүш кластерлери (прод) → Системанын X кластерлери → X тутумунун өндүрүштүк кластерлери” иерархиясын орнотсо, анда төмөнкү конфигурациялардын айкалышы X тутумунун өндүрүш кластерлерине колдонулат:

• Бардык өндүрүш кластерлери үчүн жалпы конфигурациялар.
• Системанын X кластери үчүн конфигурациялар.
• X тутумунун өндүрүш кластери үчүн конфигурациялар.

9. Шаблондор жана конфигурацияны жокко чыгаруу

Администратор тукум кууган конфигурациялардын топтомун жана алардын баалуулуктарын жокко чыгара алат, мисалы, алар колдонула турган белгилүү кластерлердин конфигурациясын тактоо үчүн.

10. Конфигурациялар, тиркеме конфигурациялары үчүн тандалма кошуу жана чыгарып салуу

Администратор белгилүү бир мүнөздөмөлөргө ээ кластерлерге белгилүү бир конфигурацияларды колдонуу же колдонбоо шарттарын коё алат.

11. Калыптарды колдоо

Иштеп чыгуучулар ар бир конкреттүү тиркеме үчүн эң ылайыктуу форматты колдонуу үчүн колдонмо ресурстары кантип аныктала турганын тандоо мүмкүнчүлүгүнөн пайда алышат (Helm Chart, таза Kubernetes yaml ж.б.).

OpenShift платформасындагы GitOps куралдары

ArgoCD

ArgoCD тышкы ресурстарды элдештирүү моделин ишке ашырат жана кластерлер менен Git репозиторийлеринин ортосундагы бирден көпкө мамилелерди уюштуруу үчүн борборлоштурулган UI сунуштайт. Бул программанын кемчиликтери ArgoCD иштебей турганда тиркемелерди башкаруу мүмкүн эместигин камтыйт.

Расмий сайт

агуу

Flux On-Cluster Resource Reconcile моделин ишке ашырат жана натыйжада аныктоо репозиторийинин борборлоштурулган башкаруусу жок, бул алсыз жери. Башка жагынан алганда, так борборлоштуруунун жоктугунан улам, бир кластер иштебей калса дагы, тиркемелерди башкаруу мүмкүнчүлүгү кала берет.

Расмий сайт

OpenShift боюнча ArgoCD орнотуу

ArgoCD эң сонун командалык сап интерфейсин жана веб консолду сунуштайт, ошондуктан биз бул жерде Flux жана башка альтернативаларды камтыбайбыз.

ArgoCDди OpenShift 4 платформасында жайгаштыруу үчүн кластердин администратору катары бул кадамдарды аткарыңыз:

OpenShift платформасында ArgoCD компоненттерин жайылтуу

# 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 куралын жайылтуу

# 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 тиркемесин кол менен орнотобуз. Төмөнкү скриншот ат мейкиндигин, жайылтуу жана кызматты кантип түзүп, андан кийин маршрутту түзүү үчүн бул кызматты ачып көрсөтөбүз.

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 боюнча жаңы коомдук репозиторий түзөбүз. Сиз каалагандай атасаңыз болот, биз блогпост деген аталышты колдонобуз.

Эгерде 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

Эми Argo CD шайкештештире албаган талааны алып салуу үчүн deployment.yaml файлын түзөтөлү.

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 интерфейсинде биздин тиркеме "Синхрондоштуруудан тышкары" статусуна ээ болорун эске алыңыз, анткени 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 колдонбогон.

Source: www.habr.com