GitOps: поредният модерен термин или пробив в автоматизацията?

Повечето от нас, забелязвайки поредния нов термин в IT блогосфера или конференция, рано или късно си задават подобен въпрос: „Какво е това? Поредното модно слово, „buzzword“ или наистина нещо, което заслужава вниманието, изучаването и обещава нови хоризонти?“ По същия начин се случи и с мен със термина GitOps преди известно време. Запarmed with множество вече съществуващи статии, а също и знанията на колегите от компанията GitLab, се опитах да разбера какво точно представлява това и как може да изглежда приложението му на практика.

Между другото, за новостта на термина GitOps също говори наскоро проведеното от нас проучване: повече от половината от анкетираните все още не са започнали работа с неговите принципи.

И така, проблемът с управлението на инфраструктурата не е нов. Множество облачни доставчици са достъпни за широка публика вече повече от десет години и, изглежда, би трябвало да са улеснили работата на екипите, отговорни за инфраструктурата. Въпреки това, в сравнение с процеса на разработка на приложения (където нивото на автоматизация достига нови хоризонти), инфраструктурните проекти все още често включват множество ръчни задачи и изискват специални знания и специалисти, особено с оглед на съвременните изисквания за устойчивост, гъвкавост, мащабируемост и еластичност.

Облачните услуги успешно изпълняваха тези изисквания и именно те дадоха значителен тласък на развитието на подхода IaC. Това е разбираемо. Все пак именно те дадоха възможност да се конфигурира напълно виртуален център за обработка на данни: няма физически сървъри, рафтове, мрежови компоненти, цялата инфраструктура може да бъде описана с помощта на скриптове и конфигурационни файлове.

Така в какво точно се състои разликата GitOps от IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:

GitOps

IaC

Целият код се съхранява в git репозиторий

Версионността на кода не е задължителна

Декларативно описание на кода / Идемпотентност

Допустимо е както декларативно, така и императивно описание

Промените влизат в сила с използването на механизми за Merge Request / Pull Request

Съгласуването, одобрението и колаборацията не са задължителни

Процесът на внедряване на актуализации е автоматизиран

Процесът на внедряване на актуализации не е регламентиран (автоматичен, ръчен, копиране на файлове, с помощта на командния ред и т.н.)

С други думи GitOps се появи благодарение на прилагането на принципите IaC. Първо, инфраструктурата и конфигурациите сега можеха да се съхраняват точно така, както и приложенията. Кодът е лесен за съхранение, споделяне, сравняване и използване на възможностите за версия. Версии, клонове, история. И всичко това на достъпно за целия екип място. Следователно, съвсем закономерно развитие беше използването на системи за контрол на версиите. В частност, git, като най-популярната.

От друга страна, се появи възможността за автоматизиране на процесите за управление на инфраструктурата. Сега това може да стане по-бързо, по-надеждно и по-евтино. В допълнение, принципите на CI / CD вече бяха добре известни и популярни сред разработчиците на софтуер. Беше необходимо само да се пренесат и приложат вече познанията и уменията в нова област. Тези практики обаче излизаха извън стандартното определение за Инфраструктура като код, оттук и възникването на понятието GitOps.

Любопитството GitOps, разбира се, произтича и от факта, че това не е продукт, приставка или платформа, свързана с какъвто и да е вендор. Това по-скоро е парадигма и набор от принципи, аналогично на друг познат ни термин: DevOps.

В компанията GitLab изработихме две определения за този нов термин: теоретично и практически. Нека започнем с теоретичното:

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