Эскертүү. котормо.: Жакында жарыялангандан кийин GitOps'те тартуу жана түртүү ыкмалары жөнүндө биз жалпысынан бул моделге кызыгууну көрдүк, бирок бул тема боюнча орус тилдүү басылмалар өтө аз болчу (Habréде эч ким жок). Ошондуктан, биз сиздердин назарыңыздарга дагы бир макаланын котормосун сунуш кылууга кубанычтабыз – дээрлик бир жыл мурун болсо да! — Weaveworks компаниясынан, анын жетекчиси «GitOps» терминин киргизген. Текст мамиленин маңызын жана учурдагылардан негизги айырмачылыктарын түшүндүрөт.
Бир жыл мурун жарыялаганбыз . Ошондо биз Weaveworks командасы толугу менен Kubernetes'тин негизинде SaaSти кантип ишке киргизгенин жана булуттун түпкү чөйрөсүндө жайылтуу, башкаруу жана мониторинг жүргүзүү боюнча эң жакшы тажрыйбалардын топтомун иштеп чыкканы менен бөлүштүк.
Макала популярдуу болуп чыкты. Башка адамдар GitOps жөнүндө айтып башташты жана жаңы куралдарды чыгара башташты , , , , жана башка. Биздин сайтта пайда болду басылмалар жана GitOps колдонуу учурлары. Бирок кээ бир адамдардын суроолору дагы эле бар. Модель салттуу моделден эмнеси менен айырмаланат? жана үзгүлтүксүз жеткирүү ()? Kubernetes колдонуу зарылбы?
Биз көп өтпөй эле жаңы сүрөттөмө керек экенин түшүндүк:
- Көптөгөн мисалдар жана окуялар;
- GitOps конкреттүү аныктамасы;
- Салттуу үзгүлтүксүз жеткирүү менен салыштыруу.
Бул макалада биз бул темалардын баарын камтууга аракет кылдык. Бул GitOps жаңыртылган киришүүсүн жана иштеп чыгуучу жана CI/CD перспективасын камсыз кылат. Биз биринчи кезекте Кубернетеске көңүл бурабыз, бирок моделди жалпылоого болот.
GitOps менен таанышыңыз
Элестеткиле. Ал келишимдердин сырын түшүнө албаган адамдарга ден соолук, унаа, үй жана саякат камсыздандыруусун сунуш кылган Үй-бүлөлүк камсыздандырууну башкарат. Анын бизнеси Алиса банкта маалымат таануучу болуп иштеп жүргөндө кошумча долбоор катары башталган. Бир күнү ал маалыматтарды эффективдүү талдоо жана камсыздандыруу пакеттерин түзүү үчүн алдыңкы компьютердик алгоритмдерди колдоно аларын түшүндү. Долбоорду инвесторлор каржылап, азыр анын компаниясы жылына 20 миллион доллардан ашык киреше алып келип, тездик менен өсүп жатат. Учурда анда 180 адам ар кандай кызматтарда иштейт. Бул веб-сайтты, маалымат базасын иштеп чыгуучу, тейлөөчү жана кардар базасын талдоочу технологиялык топту камтыйт. 60 адамдан турган бригаданы ишкананын техникалык директору Боб жетектейт.
Бобдун командасы булуттагы өндүрүш системаларын жайылтат. Алардын негизги колдонмолору Google Булуттагы Kubernetes мүмкүнчүлүктөрүн пайдаланып, GKEде иштейт. Мындан тышкары, алар өз иштеринде ар кандай маалыматтарды жана аналитикалык куралдарды колдонушат.
Үй-бүлөлүк камсыздандыруу контейнерлерди колдонууну көздөгөн жок, бирок Докердин энтузиазмына ээ болду. Компания GKE жаңы функцияларды сынап көрүү үчүн кластерлерди жайгаштырууну оңой жана оңой кылганын жакында байкады. Контейнер реестрин уюштуруу үчүн CI жана Quay үчүн Jenkins кошулду, Jenkins үчүн сценарийлер жазылды, алар GKEге жаңы контейнерлерди жана конфигурацияларды түртүштү.
Бир аз убакыт өттү. Элис менен Боб алардын тандаган мамилесинен жана анын бизнеске тийгизген таасиринен капаланышкан. Контейнерлерди ишке киргизуу эмгек ендурумдуулугун коллектив ойлогондой жакшырта алган жок. Кээде жайылтуулар бузулуп, коддун өзгөрүшү күнөөлүү же жокпу белгисиз болчу. Ошондой эле конфигурацияны өзгөртүүгө көз салуу кыйын болуп чыкты. Көбүнчө жаңы кластер түзүү жана ага тиркемелерди жылдыруу керек болчу, анткени бул система болуп калган башаламандыкты жоюунун эң оңой жолу. Элис тиркеме иштелип чыккан сайын кырдаал начарлап кетет деп корккон (андан тышкары, машина үйрөнүүгө негизделген жаңы долбоор даярдалып жаткан). Боб иштин көбүн автоматташтырган жана эмне үчүн түтүк дагы эле туруксуз, масштабы жакшы эмес жана мезгил-мезгили менен кол менен кийлигишүүнү талап кылганын түшүнгөн жок беле?
Андан кийин алар GitOps жөнүндө үйрөнүштү. Бул чечим аларга ишенимдуу илгерилее учун зарыл болгон нерсе болуп чыкты.
Элис менен Боб Git, DevOps жана инфраструктура жөнүндө көп жылдар бою коддун иштөө агымы катары угуп келишкен. GitOpsтун өзгөчөлүгү - бул идеяларды Kubernetes контекстинде ишке ашыруу үчүн эң мыкты тажрыйбалардын жыйындысын - анык жана нормативдик - алып келет. Бул тема , анын ичинде .
Үй-бүлөлүк камсыздандыруу GitOps ишке ашырууну чечет. Компания азыр Kubernetes жана комбайндар менен шайкеш келген автоматташтырылган операция моделине ээ ылдамдык менен туруктуулуканткени алар:
- эч ким жинди болбостон, бригаданын өндүрүмдүүлүгү эки эсеге жогорулаганын аныктады;
- скрипттерди тейлөөнү токтотту. Анын ордуна, алар азыр жаңы функцияларга көңүл буруп, инженердик ыкмаларды өркүндөтө алышат - мисалы, канарларды жайылтуу жана тестирлөө иштерин жакшыртуу;
- биз жайгаштыруу процессин жакшырттык, ошондуктан ал сейрек бузулат;
- кол кийлигишүүсүз жарым-жартылай бузулуулардан кийин жайылтууларды калыбына келтирүү мүмкүнчүлүгүнө ээ болду;
- сатып алынган колдонулатоЖеткирүү системаларына көбүрөөк ишеним. Элис менен Боб команданы параллелдүү иштеген микросервис топторуна бөлө аларын аныкташкан;
- ар бир топтун аракети менен күн сайын долбоорго 30-50 өзгөртүү киргизип, жаңы ыкмаларды сынай алат;
- долбоорго жаңы иштеп чыгуучуларды тартуу оңой, алар бир нече сааттын ичинде тартуу өтүнүчтөрүн колдонуу менен өндүрүшкө жаңыртууларды жайылтуу мүмкүнчүлүгүнө ээ;
- SOC2 алкагында аудиттен оңой өтүшөт (кызмат провайдерлеринин маалыматты коопсуз башкаруу боюнча талаптарга шайкештиги үчүн; мисалы, көбүрөөк окуу — болжол менен. котормо.).
Эмне болду?
GitOps эки нерсе:
- Kubernetes жана булуттук жергиликтүү үчүн операциялык модель. Ал контейнерлештирилген кластерлерди жана тиркемелерди жайгаштыруу, башкаруу жана мониторингдөө үчүн мыкты тажрыйбалардын топтомун камсыз кылат. Формада көрктүү аныктама от :
- Иштеп чыгуучуларга багытталган колдонмолорду башкаруу чөйрөсүн түзүү жолу. Биз Git иш процессин операцияларга да, өнүктүрүүгө да колдонобуз. Бул жөн гана Git push жөнүндө эмес, CI/CD жана UI/UX куралдарынын бүтүндөй топтомун уюштуруу жөнүндө экенин эске алыңыз.
Гит жөнүндө бир нече сөз
Эгер сиз версияны башкаруу системалары жана Git негизиндеги иш процесси менен тааныш болбосоңуз, биз алар жөнүндө үйрөнүүнү сунуштайбыз. Бутактар менен иштөө жана суроо-талаптарды тартуу алгач кара сыйкыр сыяктуу сезилиши мүмкүн, бирок пайдасы күч-аракет жумшайт. Мына баштоо.
Kubernetes кантип иштейт
Биздин окуяда Элис менен Боб Кубернетес менен бир аз иштегенден кийин GitOps'ка кайрылышкан. Чынында эле, GitOps Kubernetes менен тыгыз байланышта - бул Kubernetes негизинде инфраструктура жана тиркемелер үчүн оперативдүү модель.
Kubernetes колдонуучуларга эмне берет?
Бул жерде кээ бир негизги өзгөчөлүктөрү бар:
- Kubernetes моделинде бардыгын декларативдик түрдө сүрөттөсө болот.
- Kubernetes API сервери бул декларацияны киргизүү катары кабыл алып, андан кийин тынымсыз кластерди декларацияда сүрөттөлгөн абалга алып келүүгө аракет кылат.
- Декларациялар ар кандай жумуш жүктөмдөрүн — «тиркемелерди» сүрөттөө жана башкаруу үчүн жетиштүү.
- Натыйжада, колдонмого жана кластерге өзгөртүүлөр төмөнкү себептерден улам келип чыгат:
- контейнер сүрөттөрүн өзгөртүү;
- декларативдик спецификацияга өзгөртүүлөр;
- айлана-чөйрөдөгү каталар - мисалы, контейнер бузулушу.
Кубернетестин чоң конвергенция мүмкүнчүлүктөрү
Администратор конфигурацияга өзгөртүүлөрдү киргизгенде, Kubernetes оркестри аларды кластерге анын абалы өзгөргөнчө колдонот жаңы конфигурацияга жакындабайт. Бул модель бардык Kubernetes ресурсу үчүн иштейт жана Custom Resource Definitions (CRDs) менен кеңейтилет. Ошондуктан, Kubernetes жайылтуулары төмөнкү сонун касиеттерге ээ:
- автоматизация: Kubernetes жаңыртуулары өзгөрүүлөрдү жарашыктуу жана өз убагында колдонуу процессин автоматташтыруу механизмин камсыз кылат.
- Конвергенция: Kubernetes ийгиликтүү болгонго чейин жаңыртуу аракетин улантат.
- Импотенттуулук: Конвергенцияны кайталап колдонуу бир эле натыйжага алып келет.
- Детерминизм: Ресурстар жетиштүү болгондо, жаңыртылган кластердин абалы каалаган абалдан гана көз каранды.
GitOps кантип иштейт
GitOps кантип иштээрин түшүндүрүү үчүн биз Кубернетес жөнүндө жетиштүү билдик.
Үй-бүлөлүк камсыздандыруунун микросервис командаларына кайрылып көрөлү. Алар көбүнчө эмне кылышы керек? Төмөнкү тизмени караңыз (эгер анда кандайдыр бир нерселер кызыктай же бейтааныш болуп көрүнсө, сындаганды токтотуп, биз менен болуңуз). Бул Дженкинс негизиндеги иш процесстеринин мисалдары. Башка куралдар менен иштөөдө башка көптөгөн процесстер бар.
Эң негизгиси, биз ар бир жаңыртуу конфигурация файлдарына жана Git репозиторийлерине өзгөртүүлөр менен аяктаарын көрүп турабыз. Gitке бул өзгөртүүлөр "GitOps операторуна" кластерди жаңыртууга себеп болот:
1.Иш процесси: "Дженкинс куруу - башкы бутак«.
Тапшырма тизмеси:
- Дженкинс теги коюлган сүрөттөрдү Quayге түртөт;
- Дженкинс конфигурация жана Helm диаграммаларын башкы сактоо чакасына түртөт;
- Булут функциясы конфигурацияны жана диаграммаларды башкы сактоо чакасынан башкы Git репозиторийине көчүрөт;
- GitOps оператору кластерди жаңылайт.
2. Jenkins куруу - чыгаруу же оңдоо бутагы:
- Jenkins Quay үчүн белгиленбеген сүрөттөрдү түртөт;
- Дженкинс конфигурацияны жана Helm диаграммаларын стадиялык сактоо чакасына түртөт;
- Булут функциясы конфигурацияны жана диаграммаларды стадиялык сактоо чакасынан Git репозиторийине көчүрөт;
- GitOps оператору кластерди жаңылайт.
3. Jenkins куруу - иштеп чыгуу же өзгөчөлүк тармагын:
- Jenkins Quay үчүн белгиленбеген сүрөттөрдү түртөт;
- Дженкинс конфигурацияны жана Helm диаграммаларын иштеп чыгуучу чакага түртөт;
- Булут функциясы конфигурацияны жана диаграммаларды иштеп чыгуу сактагычынан Git репозиторийине көчүрөт;
- GitOps оператору кластерди жаңылайт.
4. Жаңы кардарды кошуу:
- Жетекчи же администратор (LCM/ops) Gradle'га адегенде тармак жүктөө тең салмактуулугун (NLBs) жайылтуу жана конфигурациялоо үчүн чакырат;
- LCM/ops жаңы конфигурацияны жаңыртууларга даярдоо үчүн ишке ашырат;
- GitOps оператору кластерди жаңылайт.
GitOps кыскача сүрөттөлүшү
- Ар бир чөйрө үчүн декларативдик спецификацияларды колдонуу менен бүт системанын каалаган абалын сүрөттөп бериңиз (биздин окуяда Бобдун командасы Гитте тутумдун бүт конфигурациясын аныктайт).
- Гит репозиторий - бул бүт системанын каалаган абалына байланыштуу чындыктын жалгыз булагы.
- Керектүү абалга бардык өзгөртүүлөр Гиттеги милдеттенмелер аркылуу жүргүзүлөт.
- Кластердин бардык керектүү параметрлери кластердин өзүндө да байкалат. Ушундай жол менен биз алардын дал келерин аныктай алабыз (конвертация, жакындашуу) же айырмалоо (айырмалоо, ажыратуу) каалаган жана байкалган абалдар.
- Эгерде каалаган жана байкалган абалдар айырмаланса, анда:
- Эртеби-кечпи максаттуу жана байкалган абалдарды автоматтык түрдө синхрондоштуруучу конвергенция механизми бар. Кластердин ичинде Кубернетес муну жасайт.
- Процесс дароо "өзгөртүү жасалган" эскертүүсү менен башталат.
- Кээ бир конфигурациялануучу убакыттан кийин, эгерде мамлекеттер башка болсо, "айырма" эскертүүсү жөнөтүлүшү мүмкүн.
- Ошентип, Gitтеги бардык милдеттенмелер кластерге текшерилүүчү жана идемпотенттүү жаңыртууларды жаратат.
- Артка кайтаруу - мурда каалаган абалга жакындашуу.
- Конвергенция акыркы болуп саналат. Анын пайда болушун көрсөтүп турат:
- Белгилүү бир убакыт аралыгында эч кандай айырма эскертүүлөрү жок.
- "бириктирилген" эскертүү (мисалы, webhook, Git writeback окуясы).
Дивергенция деген эмне?
Дагы кайталайлы: бардык каалаган кластер касиеттери кластердин өзүндө байкалышы керек.
Дивергенциянын кээ бир мисалдары:
- Git'теги бутактарды бириктиргендиктен конфигурация файлын өзгөртүү.
- GUI кардары тарабынан жасалган Git милдеттенмесинен улам конфигурация файлындагы өзгөртүү.
- Гиттеги PRдын аркасында каалаган абалга бир нече жолу өзгөртүүлөр, андан кийин контейнердин сүрөтүн түзүү жана конфигурацияларды өзгөртүү.
- Катадан улам кластердин абалынын өзгөрүшү, ресурстук конфликт "жаман жүрүм-турумга" алып келген же жөн эле баштапкы абалынан туш келди четтөө.
Конвергенция механизми кандай?
Бир нече мисал:
- Контейнерлер жана кластерлер үчүн конвергенция механизми Kubernetes тарабынан берилген.
- Ушул эле механизмди Kubernetes негизиндеги тиркемелерди жана дизайндарды (мисалы, Istio жана Kubeflow) башкаруу үчүн колдонсо болот.
- Kubernetes, сүрөт репозиторийлери жана Git ортосундагы оперативдүү өз ара аракеттенүүнү башкаруу механизми камсыз кылат бөлүгү болуп саналат .
- Негизги машиналар үчүн конвергенция механизми декларативдүү жана автономдуу болушу керек. Муну езубуздун тажрыйбабыздан айта алабыз бул аныктамага эң жакын, бирок дагы эле адамдын көзөмөлүн талап кылат. Бул жагынан алганда, GitOps код катары инфраструктуранын салтын кеңейтет.
GitOps Gitти Kubernetesтин эң сонун конвергенция кыймылдаткычы менен айкалыштырат, бул эксплуатациянын үлгүсүн камсыз кылат.
GitOps бизге айтууга мүмкүндүк берет: Сүрөттөлгөн жана байкоого алынган системаларды гана автоматташтырууга жана башкарууга болот.
GitOps бүткүл булуттук стекке (мисалы, Terraform ж.б.) арналган.
GitOps жөн гана Kubernetes эмес. Биз бүтүндөй системанын декларативдүү түрдө иштетилишин жана конвергенцияны колдонууну каалайбыз. Бүтүндөй система дегенде биз Kubernetes менен иштеген чөйрөлөрдүн жыйындысын түшүнөбүз - мисалы, "дев кластери 1", "өндүрүш" ж.б. Ар бир чөйрөдө машиналар, кластерлер, тиркемелер, ошондой эле маалыматтарды, мониторингди камсыз кылган тышкы кызматтар үчүн интерфейстер кирет. жана башкалар.
Бул учурда жүктөө маселеси үчүн Terraform канчалык маанилүү экенин байкаңыз. Kubernetes бир жерге жайгаштырылышы керек жана Terraform колдонуу биз Kubernetes жана тиркемелерди негиздеген башкаруу катмарын түзүү үчүн ошол эле GitOps иш процесстерин колдоно алабыз дегенди билдирет. Бул пайдалуу мыкты тажрыйба.
GitOps түшүнүктөрүн Kubernetes үстүндөгү катмарларга колдонууга катуу көңүл бурулат. Учурда Istio, Helm, Ksonnet, OpenFaaS жана Kubeflow үчүн GitOps тибиндеги чечимдер бар, ошондой эле, мисалы, Pulumi үчүн, алар булуттагы жергиликтүү тиркемелерди иштеп чыгуу үчүн катмарды түзөт.
Kubernetes CI/CD: GitOps башка ыкмалар менен салыштыруу
Белгиленгендей, GitOps эки нерсе:
- Жогоруда сүрөттөлгөн Kubernetes жана булут жергиликтүү үчүн иштөө модели.
- Иштеп чыгуучуга багытталган колдонмону башкаруу чөйрөсүнө жол.
Көптөр үчүн GitOps биринчи кезекте Git түртүрүүсүнө негизделген иш процесси. Бизге да жагат. Бирок бул баары эмес: эми CI/CD түтүктөрүн карап көрөлү.
GitOps Kubernetes үчүн үзгүлтүксүз жайылтууну (CD) иштетет
GitOps үзгүлтүксүз жайылтуу механизмин сунуштайт, ал өзүнчө "жайгаштырууну башкаруу системаларына" муктаждыкты жок кылат. Кубернетес бардык ишти сиз үчүн жасайт.
- Тиркемени жаңыртуу Gitте жаңыртууну талап кылат. Бул каалаган абалга транзакциялык жаңыртуу. "Орнотуу" андан кийин жаңыртылган сүрөттөмөнүн негизинде кластердин ичинде Kubernetes тарабынан жасалат.
- Кубернетестин иштөө мүнөзүнө байланыштуу, бул жаңыртуулар конвергенттүү. Бул бардык жаңыртуулар атомдук болгон үзгүлтүксүз жайылтуу механизмин камсыз кылат.
- Эскертүү: Git жана Kubernetes бириктирген GitOps операторун сунуштайт жана кластердин каалаган жана учурдагы абалын элдештирүү аркылуу CDди аткарууга мүмкүндүк берет.
Kubectl жана сценарийлери жок
Кластериңизди жаңыртуу үчүн Kubectl колдонуудан алыс болушуңуз керек жана өзгөчө kubectl буйруктарын топтоо үчүн скрипттерди колдонуудан алыс болушуңуз керек. Анын ордуна, GitOps түтүгү менен колдонуучу Git аркылуу Kubernetes кластерин жаңырта алат.
Артыкчылыктарга төмөнкүлөр кирет:
- Туура. Жаңыртуулардын тобун колдонууга, бириктирүүгө жана акыры валидациялоого болот, бул бизди атомдук жайгаштыруу максатына жакындатат. Ал эми скрипттерди колдонуу конвергенцияга кепилдик бербейт (төмөндө бул тууралуу көбүрөөк).
- коопсуздук. Келси Хайтауэр: "Кубернетес кластериңизге кирүү мүмкүнчүлүгүн автоматташтыруу куралдарына жана аны оңдоого же тейлөөгө жооптуу администраторлорго чектеңиз." да кара коопсуздук жана техникалык шарттарды сактоо жөнүндө, ошондой эле Этиятсыз жазылган Дженкинс сценарийинен ишеним грамоталарын уурдап.
- Колдонуучу тажрыйбасы. Kubectl бир топ татаал Кубернетес объектинин моделинин механикасын ачып берет. Идеалында, колдонуучулар абстракциянын жогорку деңгээлинде система менен иштешүүсү керек. Бул жерде мен дагы Келсиге кайрылам жана көрүүнү сунуштайм .
CI жана CD ортосундагы айырма
GitOps учурдагы CI/CD моделдерин жакшыртат.
Заманбап CI сервери - бул оркестрлөө куралы. Атап айтканда, бул CI түтүктөрүн уюштуруу үчүн курал. Аларга куруу, сыноо, магистралга бириктирүү ж.б. кирет. CI серверлери татаал көп баскычтуу түтүктөрдү башкарууну автоматташтырат. Кадимки азгырык - бул Kubernetes жаңыртууларынын топтомун скрипт кылуу жана кластерге өзгөртүүлөрдү киргизүү үчүн аны конвейердин бир бөлүгү катары иштетүү. Чынында эле, бул көптөгөн эксперттердин иш. Бирок, бул оптималдуу эмес, бул жерде эмне үчүн.
CI жаңыртууларды магистральга түртүү үчүн колдонулушу керек жана Kubernetes кластери CDди ички башкаруу үчүн ошол жаңыртуулардын негизинде өзүн өзгөртүшү керек. Биз аны чакырып , CI түртүү моделинен айырмаланып. CD бөлүгү болуп саналат иштөө убактысынын оркестри.
Эмне үчүн CI серверлери Kubernetesтеги түз жаңыртуулар аркылуу компакт-дисктерди жасабашы керек
CI серверин CI жумуштарынын жыйындысы катары Kubernetesке түз жаңыртууларды уюштуруу үчүн колдонбоңуз. Бул биз айтып жаткан анти-үлгү менин блогумда.
Келгиле, Алиса менен Бобго кайтып баралы.
Алар кандай көйгөйлөргө туш болушту? Бобдун CI сервери өзгөрүүлөрдү кластерге колдонот, бирок ал процессте бузулуп калса, Боб кластердин кандай абалда экенин (же болушу керек) же аны кантип оңдоону билбей калат. Ийгиликке жеткен учурда да ушундай.
Келгиле, Бобдун командасы жаңы имиджин куруп, андан кийин сүрөттү жайылтуу үчүн жайгаштырууну түзүштү (баары CI түтүкчөсүнөн) деп ойлойлу.
Сүрөт кадимкидей түзүлүп, бирок түтүк иштебей калса, команда төмөнкүлөрдү аныкташы керек:
- Жаңыртуу чыктыбы?
- Биз жаңы курулушту ишке киргизип жатабызбы? Бул керексиз терс таасирлерге алып келеби - бир эле өзгөрүлгүс сүрөттүн эки түзүлүшүнө ээ болуу мүмкүнчүлүгү менен?
- Курулушту иштетүүдөн мурун кийинки жаңыртууну күтүшүбүз керекпи?
- Эмне такыр ката кетти? Кайсы кадамдарды кайталоо керек (жана кайсынысын кайталоо коопсуз)?
Гитке негизделген иш процессин түзүү Бобдун командасы бул көйгөйлөргө туш болбойт деп кепилдик бербейт. Алар дагы эле commit push, теги же башка параметр менен ката кетириши мүмкүн; бирок, бул ыкма дагы эле ачык-айкын баардык же эч нерсе деген мамилеге алда канча жакын.
Жыйынтыктап айтканда, эмне үчүн CI серверлери CD менен иштебеши керек:
- Жаңыртуу скрипттери дайыма детерминисттик эмес; Аларда ката кетирүү оңой.
- CI серверлери декларативдик кластер моделине жакындашпайт.
- Идемпотенттүүлүккө кепилдик берүү кыйын. Колдонуучулар системанын терең семантикасын түшүнүшү керек.
- Жарым-жартылай иштебей калгандан кийин калыбына келтирүү кыйыныраак.
Helm жөнүндө эскертүү: Эгер сиз Helm колдонгуңуз келсе, биз аны GitOps оператору менен айкалыштырууну сунуштайбыз, мисалы . Бул конвергенцияны камсыз кылууга жардам берет. Helm өзү детерминисттик да, атомдук да эмес.
GitOps Kubernetes үчүн үзгүлтүксүз жеткирүүнү ишке ашыруунун эң мыкты жолу
Алиса менен Бобдун командасы GitOps программасын ишке ашырат жана программалык продуктулар менен иштөө, жогорку өндүрүмдүүлүктү жана туруктуулукту сактоо бир топ жеңил болуп калганын аныктайт. Келгиле, бул макаланы алардын жаңы мамилеси кандай экенин көрсөткөн иллюстрация менен аяктайлы. Эсиңизде болсун, биз негизинен тиркемелер жана кызматтар жөнүндө сөз кылып жатабыз, бирок GitOps бүт платформаны башкаруу үчүн колдонулушу мүмкүн.
Kubernetes үчүн иштөө модели
Төмөнкү диаграмманы караңыз. Ал Git жана контейнер сүрөт репозиторийин эки иреттелген жашоо цикли үчүн бөлүшүлгөн ресурстар катары көрсөтөт:
- Git'ке файлдарды окуп жана жаза турган жана контейнер сүрөттөрүнүн репозиторийин жаңырта турган үзгүлтүксүз интеграциялык түтүк.
- Жайгаштырууну башкаруу жана байкоо жүргүзүү менен айкалыштырган Runtime GitOps конвейери. Ал Gitке файлдарды окуйт жана жазат жана контейнер сүрөттөрүн жүктөй алат.
Негизги жыйынтыктар кандай?
- Кооптонууларды бөлүү: Эки түтүк тең Git же сүрөт репозиторийин жаңыртуу аркылуу гана байланыша аларын эске алыңыз. Башка сөз менен айтканда, CI менен иштөө чөйрөсүнүн ортосунда брандмауэр бар. Биз аны "өзгөрбөс брандмауэр" деп атайбыз. (өзгөрбөс брандмауэр), анткени бардык репозиторий жаңыртуулары жаңы версияларды жаратат. Бул тема боюнча көбүрөөк маалымат алуу үчүн 72-87 слайддарды карагыла .
- Сиз каалаган CI жана Git серверин колдоно аласыз: GitOps каалаган компонент менен иштейт. Сиз сүйүктүү CI жана Git серверлериңизди, сүрөт репозиторийлерин жана сыноо топтомдорун колдоно берсеңиз болот. Базардагы дээрлик бардык башка үзгүлтүксүз жеткирүү куралдары өздөрүнүн CI/Git серверин же сүрөт репозиторийлерин талап кылат. Бул булутту өнүктүрүүдө чектөөчү фактор болуп калышы мүмкүн. GitOps менен сиз тааныш куралдарды колдоно аласыз.
- Окуялар интеграция куралы катары: Gitтеги маалыматтар жаңырары менен Weave Flux (же Weave Cloud оператору) иштөө убактысын кабарлайт. Kubernetes өзгөртүү топтомун кабыл алган сайын, Git жаңыртылып турат. Бул төмөндө көрсөтүлгөндөй, GitOps үчүн иштөө процесстерин уюштуруу үчүн жөнөкөй интеграциялык моделди камсыз кылат.
жыйынтыктоо
GitOps ар кандай заманбап CI/CD куралы талап кылган күчтүү жаңыртуу кепилдиктерин берет:
- автоматташтыруу;
- конвергенция;
- импотенттүүлүк;
- детерминизм.
Бул маанилүү, анткени ал булуттагы жергиликтүү иштеп чыгуучулар үчүн оперативдүү моделди сунуш кылат.
- Системаларды башкаруу жана көзөмөлдөө үчүн салттуу инструменттер runbook ичинде иштеген операциялык топтор менен байланышкан (күнүмдүк процедуралардын жана операциялардын жыйындысы - болжол менен котормо.), белгилүү бир жайылтууга байланган.
- Булуттагы жергиликтүү башкарууда, байкоо жүргүзүү куралдары иштеп чыгуу тобу тез арада жооп бериши үчүн жайгаштыруунун натыйжаларын өлчөөнүн эң жакшы жолу болуп саналат.
Ар кандай булуттарга чачырап кеткен көптөгөн кластерлерди жана өз командалары жана жайылтуу пландары менен көптөгөн кызматтарды элестетиңиз. GitOps бул молчулукту башкаруу үчүн масштабдуу инвариант моделин сунуштайт.
Котормочудан PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- ««.
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Бул эки котормо Habréде пайда болгонго чейин GitOps жөнүндө билчү белеңиз?
-
Ооба, мен баарын билчүмүн
-
Үстүртөн гана
-
жок
35 колдонуучу добуш берди. 10 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com