В последние годы GitOps зарекомендовал себя как эффективная модель процесса для автоматизированного предоставления инфраструктуры и приложений. Она сочетает в себе декларативные конфигурации, рабочие процессы Git и автоматизацию для обеспечения прозрачного, эффективного и безопасного развертывания.
В этой статье мы подробно рассмотрим, что из себя представляет GitOps и в каких случаях эта модель могла бы помочь.
Итак, GitOps — это фреймворк, использующий лучшие практики DevOps, применяемые при разработке приложений, такие как контроль версий, совместная работа, соответствие требованиям и CI/CD, и применение их для автоматизации инфраструктуры.
Также GitOps можно назвать подходом к управлению инфраструктурой и приложениями, при котором Git выступает в качестве единого источника истины.
Большая часть жизненного цикла разработки программного обеспечения уже давно автоматизирована, в то время как настройка инфраструктуры зачастую продолжает оставаться в основном ручным процессом, требующим привлечения специализированных команд.
С учетом требований, предъявляемым к современной инфраструктуре, становится все более важным внедрение средств автоматизации. Современная инфраструктура должна быть эластичной, чтобы она могла эффективно управлять облачными ресурсами, необходимыми для непрерывного развертывания.
Также важно учитывать, что современные приложения, в особенности облачные, разрабатываются с учетом скорости и масштаба. Организации с развитой культурой DevOps могут разворачивать код в производстве по много раз в день. Команды DevOps могут добиться этого с помощью лучших практик разработки, таких как контроль версий, проверка кода и конвейеры CI/CD, автоматизирующие тестирование и развертывание.
GitOps используется для автоматизации процесса создания инфраструктуры, особенно облачных сред. Подобно тому, как команды используют исходный код приложений, команды сопровождения, внедрившие GitOps, используют файлы конфигурации, хранящиеся в виде кода (инфраструктура как код). Конфигурационные файлы GitOps генерируют одно и то же инфраструктурное окружение при каждом развертывании, точно так же, как исходный код приложения генерирует одни и те же двоичные файлы приложения при каждой сборке.
Ключевые принципы работы GitOps включают в себя:
- Декларативную инфраструктуру
- Целевое состояние представленное в файлах формата YAML или JSON
- Версионирование
- Все изменения документируются в Git
- CI/CD конвейеры для тестирования и развертывания
- Инструменты непрерывного развертывания обеспечивают постоянное соответствие фактического состояния целевому состоянию
В результате во всех средах мы получаем одинаковую инфраструктуру, необходимую для работы приложений. При этом GitOps может работать как со средами виртуализации, так и с контейнеризацией и непосредственно с ОС и ПО.
При этом сами описания конфигураций мы также, как и исходный код проекта храним в едином репозитории, и именно это хранилище используется при развертывании в каждой из сред.
С основными принципами работы GitOps, полагаю, мы разобрались и теперь можно переходить непосредственно к кейсам.
Лучшие практики и популярные инструменты DevOps-инженера можно изучить на онлайн-курсе.
Когда мы все уронили
Жизненная история наверняка хоть раз случавшаяся с каждым DevOps инженером: несколько часов простоя всей инфраструктуры.
Представим себе ситуацию, когда в одной компании критически важное обновление было вручную развернуто в производственной среде. В процессе была случайно применена неверная конфигурация, что привело к многочасовому сбою.
Причиной возникновения проблемы стало отсутствие тестирования изменений на нужном уровне и недостаточный контроль изменений.
При этом причиной того, что никто не знал об измененной конфигурации, был банальный человеческий фактор. Единственный сотрудник, знавший об изменении в конфигурации, находился в отпуске, а все остальные полагали, что конфигурация не менялась, и поэтому применили обновления.
В случае использования GitOps, конфигурация должна была быть заранее версифицирована в Git‑репозитории и представлена через pull request. После рассмотрения изменений всей командой обновление было бы безопасно развернуто в производственной среде. Благодаря декларативным описаниям инфраструктура постоянно соответствовала бы целевому состоянию, что позволило бы обнаруживать и исправлять ошибки на ранних стадиях.
В результате был бы сведен к минимуму человеческий фактор, так как все внесенные изменения были бы сохранены (с соответствующими комментариями и пояснениями) в едином репозитории. И при тестировании нового обновления проблемы были бы выявлены сразу, а не на этапе установки обновления в продуктивную среду.
Когда срочность превыше всего
Представим другую ситуацию: команде разработчиков срочно потребовалось внедрить критические изменения в производственную среду из‑за неожиданной проблемы с приложением в части безопасности. Проще говоря, нам нужно срочно закрыть критичную уязвимость.
К сожалению, команда тестирования, ответственная за проведение регрессионных тестов, в это время находилась на обучении и не могла оказать поддержку. Отсутствие автоматизированного тестирования привело к задержке в решении проблемы, а значит, клиентам пришлось дольше работать с уязвимым приложением, подвергая риску свои данные.
Здесь GitOps также мог бы быть полезен. С помощью GitOps команда разработчиков смогла бы самостоятельно добавить изменения в репозиторий. Автоматизированные конвейеры CI/CD и инструменты GitOps, такие как Jenkins, Pulumi или ArgoCD, позволили бы осуществлять развертывание в производственной среде без ручного вмешательства.
Это позволило бы снизить нагрузку на команду тестирования и эксплуатации и быстрее установить хотфикс.
Сейчас мы рассмотрели случаи, связанные с внесением изменений в имеющуюся инфраструктуру. Теперь давайте поговорим о случаях, когда инцидент уже произошел, и необходимо как можно быстрее восстановиться после сбоя.
Задержка восстановления системы после сбоя
Неожиданный отказ системы в многооблачной среде потребовал ручного вмешательства для восстановления инфраструктуры. Процесс занял несколько часов, поскольку не было четкой документации о последнем стабильном состоянии инфраструктуры приложения.
В результате многие действия по настройке конфигурации выполнялись вручную и именно это привело к дополнительным затратам времени.
В случае, если бы в репозитории Git хранились все конфигурации целевой инфраструктуры, команда поддержки смогла бы оперативно откатиться к рабочей версии.
Опять же инструменты непрерывного развертывания смогли бы автоматически восстановить целевое состояние и тем самым значительно сократить время простоя.
Нарушение compliance
Понятие compliance (соответствие нормативным требованиям) обычно относят к вопросам информационной безопасности. Для проверки соответствия этим нормативным требованиям проводят аудиты, как правило внешние, когда сторонняя организация проводит проверку.
Вот в ходе одного такого аудита было обнаружено, что изменения конфигурации не были достаточно документированы и исторически прослеживаемы (проще говоря, отсутствовала версионность). В результате были нарушены важные требования соответствия нормативным актам, что привело к предписаниям со стороны регуляторов и затем к штрафам.
Здесь GitOps тоже смог бы помочь избежать проблем. С помощью GitOps все изменения конфигурации были бы версионированы и документированы в репозиторий Git.
Любое изменение можно было бы проверить, включая информацию о том, кто его внес и время внесения. Кроме того, автоматизированные тесты могли бы гарантировать, что все изменения соответствуют требованиям компании. Для этого достаточно было бы периодически сверять текущую версию конфигурации с эталонным образцом и выявлять изменения.
Заключение
В заключении рассмотрим еще один важный вопрос: чем GitOps отличается от DevOps.
GitOps в значительной степени полагается на технические средства: автоматизацию и инструментарий для управления и развертывания изменений кода.
В свою очередь DevOps больше фокусируется на коммуникации и сотрудничестве между командами. В определенной степени DevOps это больше культура, в то время как GitOps это скорее про технологии.
Кроме того, GitOps обычно используется в сочетании с технологиями контейнеризации, такими как Kubernetes, в то время как DevOps может применяться для любого типа приложений.
Но в целом, GitOps — это ответвление DevOps, которое фокусируется на использовании репозиториев кода Git для управления развертыванием инфраструктуры и кода приложений. Основное различие между ними заключается в том, что в GitOps репозиторий Git является источником истины для состояния развертывания, а в DevOps — это просто конфигурационные файлы приложения или сервера.