Какво е GitOps? Разширяване на devops до Kubernetes и извън него

През последното десетилетие на програмирането се наблюдават редица революционни трансформации. Единият е възникнал от клъстер практики около devops, който подрежда екипите за разработка и операции в споделен работен процес и непрекъсната интеграция и непрекъсната доставка (CI / CD), при които екипите на devops доставят постоянни постепенни актуализации на кодова база. Друга трансформация дойде от свързания ход от монолитни кодови бази към базирани на облак микроуслуги, работещи в контейнери, управлявани от платформи за оркестрация като Kubernetes.

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

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

На език GitOps, кодът в системата за контрол на версиите е единственият източник на истината за това как трябва да изглежда приложението в производството

Дефиниран GitOps 

Weaveworks е компанията, която е направила най-много за популяризирането на концепцията за GitOps. Ще разгледаме малко подробностите за ролята на Weaveworks, но първо нека да разгледаме дефиницията на компанията за GitOps, която е двойна:

  • Оперативен модел за Kubernetes и други облачни технологии, предоставящ набор от най-добри практики, които обединяват внедряването, управлението и наблюдението на контейнерирани клъстери и приложения.
  • Път към опит за разработчици за управление на приложения; където от край до край CI / CD тръбопроводи и работни потоци на Git се прилагат както към операциите, така и към разработката.

С други думи, GitOps е специфичен набор от практики, предназначени да управляват Kubernetes и подобни платформи, който също се поддава на възможно по-широко приложение, тъй като все повече и повече магазини за разработки приемат практики на devops и мигрират код в облака. Но за да разберем тайния сос на GitOps и проблемите, които той решава, трябва да поговорим за компонентите, които влизат в него.

Определение на Git 

В Git в GitOps отнася до диво популярната система за управление на разпределени версия, разработена от Линус Торвалдс през 2005 г. Git е инструмент, който позволява на екипи от разработчици да работят заедно по кодова заявление, съхраняване на различни клонове на код, който те калайджия с преди сливането им в производствен код. Ключова концепция в Git е заявката за изтегляне, при която разработчикът официално иска някои кодове, по които са работили, да бъдат интегрирани в друг клон в кодовата база.

Искането за Git pull дава възможност на членовете на екипа да си сътрудничат и обсъждат, преди да постигнат консенсус дали новият код трябва да бъде добавен към приложението. Git съхранява и по-стари версии на кода, което улеснява връщането към последната добра версия, ако нещо се обърка, и ви позволява бързо да видите какво се е променило между ревизиите. Git може да е най-известен като основата на GitHub, хоствана в облак система за управление на версиите, но самият Git е софтуер с отворен код, който може да бъде разположен навсякъде, от вътрешни корпоративни сървъри до вашия компютър.

Имайте предвид, че докато обикновено смятаме Git за инструмент за компютърно програмиране, всъщност е агностично по отношение на това за какво съдържание го използвате. Git с удоволствие ще третира всеки набор от текстови файлове като вашата „кодова база“ и може например да се използва от автори, които искат да следят редакциите в съвместна работа. Това е важно, тъй като голяма част от кодовата база в основата на GitOps се състои от декларативни конфигурационни файлове, а не от изпълним код.

Последно нещо, което трябва да кажем, преди да продължим напред: Въпреки че „Git“ е точно там в името, GitOps всъщност не изисква използването на Git. Магазини, които вече са инвестирани в друг софтуер за контрол на версиите, като Subversion, също могат да внедрят GitOps. Но Git се използва широко в света на devops за внедряване на CI / CD, така че повечето проекти на GitOps в крайна сметка ще използват Git.

Какво представлява CI / CD процесът?

Пълният поглед върху CI / CD е извън обхвата на тази статия - вижте обяснителя по въпроса - но трябва да кажем няколко думи за CI / CD, защото това е в основата на това как работи GitOps. В непрекъсната интеграция половина на CI / CD е активирано, като за контрол на версиите Git хранилища като: Разработчиците могат да направят постоянни малки подобрения, за да им програмния код, вместо да въвеждаме огромни, монолитни нови версии на всеки няколко месеца или години. В непрекъснато разгръщане парче е станало възможно чрез автоматизирани системи, наречени тръбопроводи , които изграждат, тестване и разгръщане на новия код на производството.

Отново тук продължаваме да говорим за код , който обикновено призовава видения на изпълним код, написан на език за програмиране като C или Java или JavaScript. Но в GitOps „кодът“, който управляваме, е до голяма степен съставен от конфигурационни файлове. Това не е само малка подробност - тя е в основата на това, което GitOps прави. Тези конфигурационни файлове са, както казахме, „единственият източник на истина“, описващ как трябва да изглежда нашата система. Те са по-скоро декларативни , отколкото поучителни. Това означава, че вместо да казва „стартиране на десет сървъра“, конфигурационният файл просто ще каже „тази система включва десет сървъра“.

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

GitOps и Kubernetes

Както споменахме, концепциите на GitOps първоначално са разработени около управлението на Kubernetes приложения. С онова, което сега знаем за GitOps, нека отново посетим дискусията на Weaveworks за GitOps и ще видим как те описват как бихте направили актуализации на Kubernetes, управляван на принципите на GitOps. Ето обобщение:

  1. Разработчик отправя Git pull заявка за нова функция.
  2. Кодът се преглежда и одобрява, след което се обединява в основната кодова база.
  3. Обединяването задейства CI / CD конвейер, който автоматично тества и възстановява новия код и го изпраща в регистър.
  4. Софтуерен агент забелязва актуализацията, изтегля новия код от системния регистър и актуализира конфигурационния файл (написан в YAML) в хранилището за конфигуриране.
  5. Софтуерен агент в клъстера Kubernetes открива, че клъстерът е остарял, въз основа на конфигурационния файл, изтегля промените и внедрява новата функция.

Weaveworks и GitOps

Ясно е, че стъпки 4 и 5 тук правят голяма част от тежкото повдигане. Софтуерните агенти, които магически синхронизират „източника на истината“ в хранилището Git с реалното приложение Kubernetes, са магията, която прави GitOps възможна. Както казахме, в термините на GitOps процесът за създаване на системи на живо по-скоро като идеалните системи, описани в конфигурационните файлове, се нарича конвергенция . (Когато системата на живо и идеалната система не са синхронизирани, това е разминаване. ) В идеалния случай конвергенцията би се постигнала чрез автоматизирани процеси, но има ограничения за това, което може да направи автоматизацията и понякога е необходима човешка намеса.

Ние описахме процеса тук в общи термини, но всъщност, ако всъщност отидете да погледнете страницата на Weaveworks, „софтуерните агенти“, които споменахме, са част от платформата на компанията Weave Cloud. Терминът „GitOps“ е измислен от главния изпълнителен директор на Weaveworks Алексис Ричардсън и отчасти служи, за да направи платформата Weaveworks привлекателна за разработчиците, които вече са потопени в света на devops и CI / CD.

Но Weaveworks никога не е претендирал за монопол върху GitOps, което е по-скоро философия и набор от най-добри практики, отколкото конкретен продукт. Както отбелязва блогът за CloudBees, компания, която предоставя CI / CD решения, GitOps представлява отворен, неутрален от доставчика модел, разработен в отговор на управлявани собствени решения Kubernetes, пуснати от големи доставчици на облак като Amazon, Google и Microsoft . CloudBees предлага свои собствени GitOps решения, както и редица играчи в това пространство.

GitOps и devops

Atlassian, компания, която създава редица инструменти за пъргави разработчици, има задълбочена публикация в блога за историята и целта на GitOps, която си заслужава времето. Според тях GitOps представлява логично продължение на идеите, събрани като devops. По-конкретно, GitOps е разработка на концепцията за инфраструктура като код, сама по себе си идея, която излезе от средата на devops. GitOps, както го вижда Atlassian, преодоля решаващата пропаст между съществуващите техники на devops, които са се развили за решаване на проблемите на системното администриране, и специфичните нужди на разпределените приложения за хостинг в облак. Автоматизираната конвергенция, предлагана от различни доставчици на облак, е това, което прави GitOps специален.

И докато GitOps остава фокусиран върху Kubernetes днес, ние се надяваме, че сме изяснили как се прилага за много по-широкия свят на разпределени приложения, базирани на облак. Публикация в блог от доставчик на сигурност с отворен код WhiteSource очертава предимствата на GitOps:

  • Наблюдаване : GitOps системи предлагат наблюдение, регистриране, проследяване, и визуализация в сложни приложения, така че разработчиците могат да видят какво се счупи и къде.
  • Контрол на версиите и управление на промените : Очевидно това е ключово предимство от използването на система за контрол на версиите като Git. Неправилните актуализации могат лесно да бъдат върнати.
  • Лесно приемане : GitOps се основава на уменията на devops, които много разработчици вече имат.
  • Производителност : GitOps осигурява повишаване на производителността, която devops и CI / CD са довели до други сфери.
  • Одит: Благодарение на Git, всяко действие може да бъде проследено до определен ангажимент, което улеснява проследяването на причината за грешките.

Дори и да не използвате Kubernetes, шансовете са, че GitOps рано или късно ще бъде част от вашия работен процес.