Большинство из нас, подмечая очередной новый термин в IT блогосфере или конференции, рано или поздно задается подобным вопросом: “Что это? Очередное модное слово, “buzzword” или действительно что-то стоящее пристального внимания, изучения и обещающее новые горизонты?” Точно также вышло у меня и с термином GitOps некоторое время назад. Вооружившись множеством уже существующих статей, а также знанием коллег из компании GitLab, я попытался разобраться, что же это за зверь, и как его применение может выглядеть на практике.

Кстати, о новизне термина GitOps также говорит недавно проведенный нами опрос: более половины опрошенных еще не начинали работы с его принципами.

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

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

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

Иными словами 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)

• Автоматизировать обнаружение дрейфа системы от желаемого состояния при помощи активного мониторинга