Большасць з нас, заўважаючы чарговы новы тэрмін у IT блогасферы ці канферэнцыі, рана ці позна задаецца такім пытаннем: “Што гэта? Чарговае моднае слова, “buzzword” ці сапраўды нешта вартае пільнай увагі, вывучэння і абяцаючае новыя гарызонты?” Дакладна таксама выйшла ў мяне і з тэрмінам GitOps некаторы час назад. Узброіўшыся мноствам ужо існуючых артыкулаў, а таксама веданнем калег з кампаніі , я паспрабаваў разабрацца, што ж гэта за звер, і як яго прымяненне можа выглядаць на практыцы.
Дарэчы, аб навізне тэрміна GitOps таксама кажа нядаўна праведзенае намі апытанне: больш за палову апытаных яшчэ не пачыналі працы з яго прынцыпамі.
Такім чынам, праблема кіравання інфраструктурай не новая. Мноства хмарных правайдэраў ужо добры дзясятак гадоў даступныя шырокай публіцы і, здавалася б, павінны былі зрабіць працу якія адказваюць за інфраструктуру каманд простай і немудрагелістай. Аднак пры параўнанні з працэсам распрацоўкі прыкладанняў (дзе ўзровень аўтаматызацыі дасягае ўсё новых і новых гарызонтаў), інфраструктурныя праекты ўсё яшчэ часцяком уключаюць мноства выкананых уручную задач і патрабуюць адмысловых ведаў і адмыслоўцаў, асабліва з улікам сучасных патрабаванняў да адмоваўстойлівасці, гнуткасці, маштабаванасці і эластычнасці.
Хмарныя сэрвісы вельмі паспяхова выконвалі гэтыя патрабаванні і менавіта яны далі значны штуршок развіццю падыходу. IaC. Яно і зразумела. Бо менавіта яны далечы магчымасць канфігураваць цалкам віртуальны цэнтр апрацоўкі дадзеных: няма фізічных сервераў, стоек, сеткавых кампанентам, усю інфраструктуру можна апісаць пры дапамозе скрыптоў і канфігурацыйных файлаў.
Так у чым уласна адрозненне GitOps ад IaC? Менавіта з гэтага пытання я і пачаў сваё расследаванне. Паразмаўляўшы з калегамі, у мяне атрымалася выпрацаваць наступнае параўнанне:
GitOps
IaC
Увесь код захоўваецца ў git рэпазітары
Версійнасць кода неабавязковая
Дэкларатыўнае апісанне кода / Ідэмпатэнтнасць
Дапушчальна як дэкларатыўнае, так і імператыўнае апісанне
Змены набываюць моц з выкарыстаннем механізмаў Merge Request / Pull Request
Узгадненне, зацвярджэнне і калабарацыя неабавязковыя
Працэс выкату абнаўленняў аўтаматызаваны
Працэс выкату абнаўленняў не нармаваны (аўтаматычны, ручны, капіраванне файлаў, з выкарыстаннем каманднага радка і г.д.)
Іншымі словамі GitOps з'явіўся на свет менавіта дзякуючы прымяненню прынцыпаў IaC. Па-першае, інфраструктуру і канфігурацыі зараз можна было захоўваць сапраўды гэтак жа як і прыкладанні. Код лёгка захоўваць, ім лёгка дзяліцца, параўноўваць, карыстацца магчымасцямі версійнасці. Версіі, галінкі, гісторыя. І ўсё гэта ў агульнадаступным для ўсёй каманды месцы. Таму суцэль заканамерным развіццём стала выкарыстанні сістэм кантролю версій. У прыватнасці, git, як найболей папулярнага.
З іншага боку, з'явілася магчымасць аўтаматызаваць працэсы кіравання інфраструктурай. Цяпер гэта можна зрабіць хутчэй, надзейней і танней. Тым больш прынцыпы CI/CD ужо былі вядомыя і папулярныя сярод распрацоўшчыкаў праграмнага забеспячэння. Неабходна было толькі перанесці і прымяніць ужо вядомыя веды і навыкі ў новую вобласць. Гэтыя практыкі аднак выходзілі за рамкі стандартнага вызначэння Інфраструктуры як кода, адсюль і нарадзілася паняцце. GitOps.
Цікаўнасць GitOps, вядома, яшчэ і ў тым, што гэта не прадукт, убудова ці платформа, злучаная з якім бы там ні было вендарам. Гэта хутчэй парадыгма і набор прынцыпаў, аналагічна з іншым знаёмым нам тэрмінам: DevOps.
У кампаніі мы выпрацавалі два азначэнні гэтага новага тэрміна: тэарэтычны і практычна. Пачнём з тэарэтычнага:
GitOps - гэта метадалогія, якая выкарыстоўвае перадавыя прынцыпы DevOps, якія выкарыстоўваюцца для распрацоўкі прыкладанняў, такія як кантроль версій, узаемадзеянне, узгадненне, CI / CD, і прымяняе іх для вырашэння задач па аўтаматызацыі кіравання інфраструктурай.
Усе працэсы GitOps працую з выкарыстаннем ужо наяўных прылад. Увесь інфраструктурны код захоўваюцца ва ўжо знаёмым git рэпазітары, змены праходзяць той жа працэс узгаднення, што і любы іншы праграмны код, а працэс выкату аўтаматызаваны, што дазваляе звесці да мінімуму памылкі чалавечага фактару, павысіць надзейнасць і ўзнаўляльнасць.
З практычнага ж пункту гледжання мы апісваем GitOps наступным чынам:
Інфраструктуру як код мы ўжо абмеркавалі, як адно з ключавых складнікаў гэтай формулы. Давайце прадставім астатніх удзельнікаў.
Merge Request (альтэрнатыўная назва Pull Request). У плане працэсу MR - гэта запыт на ўжыванне змен кода і наступнае зліццё галінак. Але ў плане інструментаў, якімі мы карыстаемся - гэта хутчэй магчымасць для атрымання поўнай карціны ўсіх змяненняў, якія ўносяцца: не толькі code diff, сабраны з нейкай колькасці коммітаў, але і кантэкст, вынікі тэстаў, канчатковы чаканы вынік. Калі мы гаворым пра інфраструктурны код, то нам цікава, як менавіта зменіцца інфраструктура, колькі новых рэсурсаў будзе дададзена ці выдалена, зменена. Пажадана ў нейкім зручнейшым і лёгка чытэльным фармаце. У выпадку з хмарнымі правайдэрамі нядрэнна было б ведаць, якія фінансавыя наступствы панясе гэтую змену.
Але MR - гэта яшчэ і сродак сумеснай працы, узаемадзеяння, зносін. Тое месца, дзе ўступае ў дзеянне сістэма стрымак і проціваг. Ад простых каментароў да фармальных ухвал і сцвярджэнняў.
Ну і апошні складнік: CI/CD, як мы ўжо ведаем, дае магчымасць аўтаматызаваць працэс занясення інфраструктурных змен, тэставанні (ад простай праверкі сінтаксісу да больш складанага статычнага аналізу кода). А таксама і ў наступным выяўленні дрэйфу: адрозненняў рэальнага і жаданага стану сістэмы. Напрыклад, у выніку несанкцыянаваных ручных змен ці адмовы сістэм.
Так, тэрмін GitOps не знаёміць нас ні з чым абсалютна новым, не вынаходзіць ровар, а ўсяго толькі прымяняе ўжо назапашаны вопыт у новай вобласці. Але ў гэтым і заключаецца яго сіла.
А калі вам раптам стане цікава, як гэта ўсё выглядае на практыцы, то запрашаю паглядзець наш , у якім я пакрокава расказваю, як пры дапамозе GitLab:
-
Рэалізаваць асноўныя прынцыпы GitOps
-
Ствараць і ўносіць змены ў хмарную інфраструктуру (на прыкладзе Yandex Cloud)
-
Аўтаматызаваць выяўленне дрэйфу сістэмы ад жаданага стану пры дапамозе актыўнага маніторынгу
https://bit.ly/34tRpwZ
Крыніца: habr.com