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

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

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

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

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

И така, каква точно е разликата gitops от IaC? С този въпрос започнах разследването си. След разговор с колеги успях да направя следното сравнение:

gitops

IaC

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

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

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

Разрешени са както декларативни, така и императивни описания

Промените влизат в сила чрез механизмите за заявка за сливане / заявка за изтегляне

Координацията, одобрението и сътрудничеството не са задължителни

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

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

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

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

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

Фирмата GitLab разработихме две дефиниции на този нов термин: теоретична и практическа. Да започнем с теорията:

GitOps е методология, която приема най-добрите принципи на DevOps, използвани за разработка на приложения, като контрол на версиите, взаимодействие, съгласуване, CI/CD, и ги прилага за автоматизиране на задачи за управление на инфраструктурата.

Всички процеси gitops Работя със съществуващи инструменти. Целият инфраструктурен код се съхранява в познато git хранилище, промените преминават през същия процес на регистрация като всеки друг код, а процесът на внедряване е автоматизиран, което минимизира човешката грешка, подобрява надеждността и възпроизводимостта.

От практическа гледна точка ние описваме gitops както следва:

Вече обсъдихме инфраструктурата като код като един от ключовите компоненти на тази формула. Нека представим останалите членове.

Заявка за сливане (алтернативно име за заявка за изтегляне). По отношение на процеса, MR е заявка за прилагане на промени в кода и след това обединяване на клонове. Но от гледна точка на инструментите, които използваме, това е по-скоро възможност да получим пълна картина на всички направени промени: не само разлики в кода, събрани от определен брой ангажименти, но също и контекст, резултати от тестове и крайни очаквания резултат. Ако говорим за кода на инфраструктурата, тогава ни интересува как точно ще се промени инфраструктурата, колко нови ресурси ще бъдат добавени или премахнати, променени. За предпочитане в някакъв по-удобен и лесен за четене формат. В случай на облачни доставчици би било хубаво да знаете какви ще бъдат финансовите последици от тази промяна.

Но MR е и средство за сътрудничество, взаимодействие, комуникация. Мястото, където влиза в действие системата на проверки и баланси. От прости коментари до официални одобрения и изявления.

Е, последният компонент: CI / CD, както вече знаем, прави възможно автоматизирането на процеса на извършване на инфраструктурни промени, тестване (от проста проверка на синтаксиса до по-сложен анализ на статичен код). А също и при последващо откриване на дрейф: разлики между реалното и желаното състояние на системата. Например в резултат на неразрешени ръчни промени или повреда на системата.

Да, срокът gitops не ни запознава с нищо абсолютно ново, не преоткрива колелото, а само прилага вече натрупания опит в нова област. Но в това се крие силата му.

И ако изведнъж се заинтересувате как изглежда всичко на практика, тогава ви каня да разгледате нашия майсторски клас, в който ви превеждам как да използвате GitLab:

• Приложете основните принципи на GitOps

• Създаване и извършване на промени в облачната инфраструктура (на примера на Yandex Cloud)

• Автоматизирайте откриването на отклонение на системата от желано състояние чрез активно наблюдение

https://bit.ly/34tRpwZ

Източник: www.habr.com