TL;DR: GitOps применяет те же способы для развертывания инфраструктуры, какими пользуются DevOps и CI/CD для развертывания приложений.

За последние десять лет разработка приложений увидела много революционных изменений. Часть их возникла из методов кластеризации вокруг DevOps-подхода и CI/CD. Еще часть таких изменений пришла из движения от монолитной кодовой базы к основанным на облачных технологиях микросервисам, которые запускаются в контейнерах и управляются платформами оркестровки, например 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 дает возможность совместной работы и обсуждения для членов команды. Члены команды должны достичь соглашения по новому коду, который будет добавлен в приложение. Git также сохраняет старые версии кода, что делает возможным легкий откат к последней рабочей версии, если вдруг что-то пойдет не так. Кроме того, можно легко посмотреть различия между версиями. Git также известен как основа GitHub, облачной системы контроля версий, но сам Git — программа с открытым исходным кодом, которую можно установить везде, начиная с внутренних серверов компании и заканчивая вашей рабочей машиной.

Обратите внимание: хоть мы обычно представляем Git как инструмент разработки для IT, ему вообще безразлично, какое содержимое хранить. 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. Но в GitOps под кодом мы по большей части подразумеваем файлы настроек. Это не просто мелкое примечание — это то, на чем основана работа GitOps. Эти файлы, как мы уже говорили, являются «единым истинным источником», описывающим, как наша система должна выглядеть. Они по большей части декларативные, а не инструктивные. Это значит, что вместо того, чтобы сказать "запусти десять серверов» в файле с настройками, мы просто говорим «в системе должно быть десять серверов».

С помощью CI в трактовке GitOps разработчики могут быстро добавить настройки и улучшения в этих файлах, CD начинается там, где автоматизированные программы-агенты делают все необходимое, чтобы реальная версия приложения соответствовала описанию в файлах настройки — сходилась с декларативной моделью, если говорить в терминах GitOps.

GitOps и Kubernetes

Как мы уже писали выше, идеи GitOps были сначала обкатаны на приложениях, управляемых Kubernetes. Давайте теперь с тем, что мы знаем о GitOps, вернемся обратно к обсуждению GitOps от Weaveworks, и посмотрим, как они описывают принципы управления обновлениями для Kubernetes, применяемые в GitOps. Кратко процесс работы:

1. Разработчик делает запрос на слияние с новой функцией;
2. Код проверяется и одобряется, сливается с кодовой базой;
3. Слияние активирует конвейер CI/CD, автоматически собирающий, тестирующий и выкатывающий код в registry;
4. Программный агент получает уведомление об обновлении, скачивает новый код из registry и обновляет файл настроек (написанный на YAML) в репозитории настроек;
5. Программный агент в кластере Kubernetes определяет, основываясь на файле настроек, что его настройки устарели, скачивает изменения и выкатывает новую функцию.

Weaveworks и GitOps

Очевидно, что шаги 4 и 5 делают большую часть тяжелой работы, ведь программные агенты, волшебным образом синхронизирующие «единый истинный источник» в репозитории Git с реальным приложением в Kubernetes, делают возможным GitOps. Как мы уже писали, процесс превращения живых систем в те, что описаны в файлах настроек, в терминах GitOps называется схождением. (А когда не синхронизированы — расхождением). В идеальном случае схождение может быть достигнуто с помощью автоматизированных процессов, но есть несколько пределов автоматизации. Так что местами потребуется вмешательство человека.

Мы описываем процесс общими словами, но по факту, если вы посмотрите страничку Weaveworks, «программные агенты», о которых мы писали, — это часть корпоративной платформы Weave Cloud. Термин «GitOps» придумал генеральный директор Weaveworks, Alexis Richardson, этот термин нужен для того, чтобы привлечь внимание разработчиков, знакомых с DevOps и CI/CD, к платформе Weaveworks.

При этом 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, мы надеемся, что вам стало ясно, как его применять в более широком мире распределенных облачных приложений. Эта статья от поставщика безопасности с открытым исходным кодом выделяет следующие преимущества GitOps:

• Наблюдаемость: системы GitOps предлагают мониторинг, журналирование, слежение и визуализацию сложных приложений, так что разработчики могут видеть, что и где сломалось;
• Управление версиями и изменениями: это, очевидно, ключевое преимущество от использования систем контроля версий, например Git. Кривые обновления можно легко откатить;
• Легкое внедрение: GitOps основан на навыках DevOps, уже имеющихся у большинства разработчиков;
• Продуктивность: GitOps предлагает увеличение продуктивности, аналогичное получаемому от внедрения DevOps и CI/CD;
• Проверки: благодаря Git все действия можно отследить до отдельного коммита, делая легким отслеживание исходных причин проблем.

Даже если вы и не используете Kubernetes, есть хорошие шансы на то, что GitOps станет частью вашего рабочего процесса рано или поздно.

От редакции: Практику применения GitOps можно получить на курсе Слёрма «CI/CD на примере Gitlab CI». До 3 декабря 2020 курс доступен по цене предзаказа, а также можно стать консультантом-тестером и повлиять на итоговый контент курса.