Что такое GitOps. Улучшенный DevOps?
Для начала давайте вспомним, что такое DevOps.
DevOps – это набор техник для сокращения времени доставки программного обеспечения из редактора кода к конечным пользователям, а вовсе не человек, как это пишут в вакансиях.
С девопсом люди стали применять практики разработки программного обеспечения к управлению инфраструктурой. Грубо говоря серверами, на которых программное обеспечение работает. Далее я буду говорить серверы, но конечно ваша система может работать и на серверлесс решении или на кластере кубернетис.
В частности появились такие вещи как Инфраструктура – как код. То есть описание инфраструктуры вашего проекта в виде кода, то есть в виде json или yaml файлов, в которых вы в декларативной форме указываете что вам необходимо иметь. Инфраструктура как код может быть необязательно декларативной, может вполне себе быть процедурной. Главное чтобы инфраструктура была описана однозначно и исчерпывающе. На основе этой конфигурации специальное программное обеспечение уже разворачивает инфраструктуру. То есть это программное обеспечение нужно запустить, отдать ему конфигурацию и проследить, что все развернулось корректно.
Конечно же инфраструктура как код – это не только про серверы. Это и настройка сетей, политик доступа и всего, что вам может предложить любой облачный провайдер.
Раньше повсеместно, а сейчас наверное разве что на маленьких проектах люди разворачивают инфраструктуру руками. Накликивают то что нужно через пользовательский интерфейс, либо прямо настраивают систему на серверах через удаленный доступ.
Антон Павленко в одном из видео рассказал, почему вам лучше использовать инфраструктуру как код, даже для маленьких проектов.
Так вот, инфраструктура как код – это один из столпов гитопс, но не единственный. Если вы хотите начать, то это может быть лучшим местом. Опишите инфраструктуру и никогда больше не трогайте ее руками, а если трогаете – переносите все изменения в код.
Дальше, как следует из названия, основной черепахой, на которой держится гитопс, является система контроля версий. Ну а так как гит уже почти что стандарт, то и назвали гитопс, а не VSC Ops.
Гит репозиторий является единственным источником истины в гит опс. Все изменение идет через гит и пулл реквесты. Это позволяет прямо на месте подключить всех необходимых людей для процесса ревью, указав группы владельцев определенных участков кода, которые должны одобрить изменение. Таким образом гит и разделение доступа в гит становится вашим единственным местом не только для кода и инфраструктуры, но и для политики доступа к разным частям вашего проекта.
Другими словами, если у тебя нет доступа к репозиторию – у тебя нет доступа к проекту. Если тебе запрещено одабривать изменения в коде инфраструктуры – то ты не можешь ничего незаметно поменять.
Но давайте вспомним, где обычно останавливается дев опс. Обычно программисты пишут код, который потом отправляют на ревью коллегам. После ревью код сливают в главную ветку репозитория, откуда изменения подхватывает система непрерывного интегрирования или CI, делает билд, прогоняет тесты и, если все хорошо, выкатывает новую версию на серверы.
Здесь CI останавливается. Система непрерывной интеграции может проверить основные признаки успеха после выкатки, но если все упадет в следующую секунду после успешного развертывания, то CI это уже не волнует.
Примерно здесь начинается GitOps.
Мы уже договорились, что все что мы делаем будет проходить через гит репозиторий. Мы не будем трогать инфраструктуру руками. Даже доступ к панели управления облачного провайдера будет не у каждого.
Вторая договоренность – код нашей системы будет идти вместе с кодом инфраструктуры, на которой наша система работает. То есть каждый коммит содержит всю необходимую информацию для работы нашей системы.
Третья договоренность – все автоматизировано. Мы не выкатываем изменения руками. Система сама определяет и устраняет разницу между тем, что находится в гите и тем, что реально крутится на серверах. Включая и сами серверы. Их количество и конфигурация. Как настроена сеть между серверами. Какие политики доступа существуют и так далее.
Для этого используют либо пулл, либо пуш модель. То есть либо система сама время от времени проверяет наличие новой версии в репозитории, либо система срабатывает по событию вливания новой версии в главную ветку. Для этого обычно запускают специальную программу-агента, которая работает прямо в окружении вашей системы и изменяет ее изнутри.
Для этого ваша система должна быть обозреваема, возможно вы слышали термин observability. То есть в любой момент времени можно выгрузить состояние инфраструктуры в файлы конфигурации, чтобы сравнить с эталонным состоянием в репозитории.
Так же ваша платформа должна уметь решать конфликты. Если конфигурация одного из серверов изменилась – система должна знать как обновить этот сервер. Возможно проще его убрать и поднять новый. Но все эти правила должны быть заранее прописаны.
Все это похоже на довольно много работы, что же дает такой подход?
Так как все находится в одном месте, то и поделиться этим с соседней командой гораздо проще. Как и проще поднять полную копию системы. Так же ваш репозиторий становится полной документацией на все, что происходит с вашим проектом.
Вся система описана в коде и описание зафиксировано в системе контроля версий. В случае ошибки вы можете вернуться к последнему состоянию откатив сразу все и инфраструктуру и код.
Использование системы контроля версии, как единственного окна в систему облегчает аудит. Можно отследить все изменения в хронологическом порядке. Кто сделал эти изменения. Кто их одобрил, то слил в главную ветку.
Все автоматизировано. Как говорят, если что-то делать некомфортно, то нужно это делать чаще. Система регулярно сама проверяет наличие расхождений и исправляет их. Выкатка новых версий происходит чаще и быстрее. Релиз уже не становится чем-то болезненным.
Как видите за все видео я упомянул кубернетис только один раз. Конечно, куб, как система, которую полностью можно описать декларативно ямл файлами отлично подходит для гит опс. Есть ряд инструментов, которые работают прямо в кластере и обновляют его изнутри. Но точно так же вы можете использовать Terraform или Ansible для облачных платформ, например.
Список источников, которые я использовал при подготовке видео:
https://www.gitops.tech/
https://www.weave.works/technologies/gitops/
https://github.com/weaveworks/awesome-gitops
Видео с критикой GitOps https://www.youtube.com/watch?v=n12xQNWhRdw
Видео Антона Павленко про IaC https://www.youtube.com/watch?v=wq71A-YZhK0
Видео от GitLab https://www.youtube.com/watch?v=JtZfnrwOOAw
Видео от Nana https://youtu.be/f5EpcWp0THw