Већина нас, приметивши још један нови термин у ИТ блогосфери или конференцији, пре или касније постави слично питање: „Шта је ово? Само још једна популарна реч, „незнатна реч“ или нешто заиста вредно пажње, проучавања и обећања нових хоризоната?“ Иста ствар ми се десила са термином ГитОпс пре неког времена. Наоружан многим постојећим артиклима, као и знањем колега из компаније , покушао сам да схватим каква је ово звер, и како би њена употреба могла да изгледа у пракси.
Иначе, о новини појма ГитОпс Наше недавно истраживање такође каже: више од половине испитаних још није почело да ради по његовим принципима.
Дакле, проблем управљања инфраструктуром није нов. Многи провајдери облака доступни су широј јавности већ десетак година и, чини се, требало је да учине рад тимова одговорних за инфраструктуру једноставним и јасним. Међутим, у поређењу са процесом развоја апликација (где аутоматизација достиже све нове нивое), инфраструктурни пројекти и даље често укључују много ручних задатака и захтевају специјализовано знање и стручност, посебно имајући у виду данашње захтеве за толеранцију грешака, флексибилност, скалабилност и еластичност.
Цлоуд сервиси су веома успешно испунили ове захтеве и управо су они дали значајан подстицај развоју приступа ИаЦ. Ово је разумљиво. На крају крајева, омогућили су да се конфигурише потпуно виртуелни центар података: нема физичких сервера, рекова или мрежних компоненти; целокупна инфраструктура се може описати помоћу скрипти и конфигурационих датотека.
У чему је тачно разлика? ГитОпс из ИаЦ? Са овим питањем сам започео своју истрагу. После разговора са колегама, успео сам да дођем до следећег поређења:
ГитОпс
ИаЦ
Сав код се чува у гит спремишту
Верзија кода је опциона
Декларативна шифра Опис / Идемпотенција
И декларативни и императивни описи су прихватљиви
Промене ступају на снагу коришћењем механизама Захтева за спајање / Захтева за повлачење
Договор, одобрење и сарадња су опциони
Процес увођења ажурирања је аутоматизован
Процес увођења ажурирања није стандардизован (аутоматски, ручно, копирање датотека, коришћење командне линије, итд.)
Другим речима ГитОпс рођена управо кроз примену принципа ИаЦ. Прво, инфраструктура и конфигурације сада могу да се чувају на исти начин као и апликације. Код се лако складишти, лако се дели, пореди и користи могућности верзирања. Верзије, гране, историја. И све то на месту које је јавно доступно целом тиму. Стога је употреба система контроле верзија постала потпуно природан развој. Конкретно, гит, као најпопуларнији.
С друге стране, постало је могуће аутоматизовати процесе управљања инфраструктуром. Сада то може да се уради брже, поузданије и јефтиније. Штавише, принципи ЦИ/ЦД-а су већ били познати и популарни међу програмерима софтвера. Било је потребно само пренети и применити већ позната знања и вештине у новој области. Ове праксе су, међутим, превазишле стандардну дефиницију инфраструктуре као кода, па отуда и концепт ГитОпс.
Радозналост ГитОпс, наравно, и у чињеници да то није производ, додатак или платформа повезана са било којим добављачем. То је више парадигма и скуп принципа, сличан другом појму који нам је познат: ДевОпс.
У предузећу развили смо две дефиниције овог новог појма: теоријску и практичну. Почнимо са теоријским:
ГитОпс је методологија која узима најбоље ДевОпс принципе који се користе за развој апликација, као што су контрола верзија, сарадња, оркестрација, ЦИ/ЦД, и примењује их на изазове аутоматизације управљања инфраструктуром.
Сви процеси ГитОпс Радим користећи постојеће алате. Сав инфраструктурни код се чува у већ познатом гит репозиторијуму, промене пролазе кроз исти процес одобравања као и сваки други програмски код, а процес увођења је аутоматизован, што нам омогућава да минимизирамо људске грешке, повећамо поузданост и поновљивост.
Са практичне тачке гледишта, описујемо ГитОпс како слиједи:
Већ смо разговарали о инфраструктури као коду као једној од кључних компоненти ове формуле. Хајде да представимо остале учеснике.
Захтев за спајање (алтернативни назив Пулл Рекуест). У смислу процеса, МР је захтев за примену промена кода и затим спајање грана. Али у смислу алата које користимо, ово је више прилика да се добије потпуна слика свих промена које се праве: не само код дифф прикупљен из одређеног броја урезивања, већ и контекст, резултати теста и коначни очекивани резултат. Ако говоримо о инфраструктурном коду, онда нас занима како ће се тачно инфраструктура променити, колико ће нових ресурса бити додато или уклоњено, промењено. По могућству у неком погоднијем и лако читљивом формату. За пружаоце услуга у облаку, добра је идеја да знају какав ће бити финансијски утицај ове промене.
Али МР је такође средство за сарадњу, интеракцију и комуникацију. Место где систем провере и равнотеже ступа на снагу. Од једноставних коментара до формалних одобрења и одобрења.
Па, последња компонента: ЦИ/ЦД, као што већ знамо, омогућава аутоматизацију процеса прављења инфраструктурних промена и тестирања (од једноставне провере синтаксе до сложеније статичке анализе кода). И такође у накнадном откривању помака: разлике између стварног и жељеног стања система. На пример, као резултат неовлашћених ручних промена или квара система.
Да, термин ГитОпс не уводи нас ни у шта потпуно ново, не измишља точак, већ једноставно примењује већ стечено искуство у новој области. Али ту лежи његова снага.
А ако вас одједном заинтересује како све ово изгледа у пракси, онда вас позивам да погледате наше , у којем вам говорим корак по корак како да користите ГитЛаб:
-
Примените основне принципе ГитОпс-а
-
Креирајте и унесите измене у инфраструктуру облака (на примеру Иандек Цлоуд-а)
-
Аутоматско откривање померања система из жељеног стања користећи активни надзор
https://bit.ly/34tRpwZ
Извор: ввв.хабр.цом