Вадим Гедзь, ведущий DevOps инженер, Dyninno Technologies

Всем привет! Сегодня я хотел бы рассказать о том, как в компании, где я работаю, происходит переход к GitOps. Но сначала немного контекста: я ведущий DevOps инженер в компании Dyninno Technologies – это IT-хаб группы компаний Dyninno. Мы занимаемся разработкой ПО и отвечаем за IT инфраструктуру всех компаний группы. Dyninno – международный холдинг, который работает в трех сегментах бизнеса: авиаперелеты, финансовый сектор и индустрия развлечений (кастинг). Мы создали и поддерживаем собственный инструмент по поиску лучших вариантов перелетов для клиентов, соцсети по кастингу актеров и талантливых людей, и недавно запустили новое платежное решение для необанка. Работа этих проектов завязана на технологии, за развитие которых отвечает команда Dyninno Technologies. 

В команде разработки больше 300 человек, поэтому остро стоит вопрос управления конфигурациями и непрерывной интеграции кода. В этом кейсе я расскажу о том, как при переходе на GitOps мы исключили дрифт конфигурации между git репозиториями и инфраструктурой, отмечу преимущества и недостатки ArgoCD, как решили задачу secret management при использовании ArgoCD. Также затрону вопрос обратной связи после того, как Docker Image залит в Docker Register и до того, как ArgoCD начинает deployment, рассказав, как мы с коллегами в свое свободное время написали сервис Argo Watcher. Эта статья может быть интересна тем, кто задумывается о внедрении GitOps в свою инфраструктуру.  

Описание проблемы 

Когда я только начал работать в Dyninno, в компании использовался неожиданный способ развертывания приложений в кластерах Kubernetes. Бралась определенная версия Helm чарта, из нее генерировали манифесты, которые в дальнейшем управлялись через Kustomize, а тот запускался из огромного Makefile. Вся эта конструкция как-то справлялась со своими задачами, но эту работу было сложно назвать оптимальной или хотя бы минимально приемлемой. При таком подходе многие вещи делались локально, без коммита в гит репозиторий. А значит, возникали ситуации, когда новые изменения отменяли не зафиксированные предыдущие.   

Я пришел в Dyninno Technologies из компании, где Weave Flux использовался во всех кластерах Kubernetes. Здесь также применялся этот оператор, но управлялся через него минимальный процент конфигурации. Стало очевидно, что для улучшения процессов нужно переходить к GitOps.  

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

• Какое из GitOps решений лучше подходит под наши задачи?   

• Как разработчики смогут контролировать, что происходит с их кодом по завершению работы CI/CD pipeline?  

Выбор инструмента 

Одна из самых главных задач при выборе GitOps решения – понять, что происходит в процессе синхронизации. Несмотря на то, что логов, которые предоставляются другими продуктами, обычно достаточно для понимания происходящего, иногда трудно найти относящиеся к проблеме с конкретным ресурсом сообщения. Особенно если используются чарты с десятками, если не сотнями, ресурсов. А в ArgoCD сделан очень удобный интерфейс, в котором отображаются статусы каждого ресурса, что помогает сократить время на выявление потенциальной проблемы. Только одно это – большой плюс по сравнению с Weave Flux. Дополнительными аргументами стали возможность подключения сторонних плагинов для расширения функций и интеграция с SSO (единый вход в систему) при работе через web-интерфейс.

Что не хватает 

Мы постепенно приходим к стандартизации всех сред Kubernetes. Но поскольку у разных команд свое виденье того, какие технологии использовать, система должна уметь подстроиться под отличия от стандартного подхода. Для нас одним из критических параметров стало управление секретами (secrets management). Поскольку мы решили, что в конечном итоге хотим перейти на GitOps, создание секретов вручную стало неприемлемым. В некоторых кластерах уже использовался контроллер SealedSecrets. Это по-прежнему требовало прямого доступа к кластеру и хотя бы базового понимания, как с ним работать. Но едва ли все разработчики должны это знать. И, увы, в ArgoCD secrets management не нашлось решения из коробки.  

Но ArgoCD позволяет подключать сторонние плагины для расширения функций. Один из них – отличный плагин, который дает возможность использовать секреты из HashiCorp Vault (https://github.com/argoproj-labs/argocd-vault-plugin). Благодаря этому разработчики или не IT-специалисты могут редактировать пароли и другие чувствительные данные через удобный и простой веб-интерфейс.   

Хотя мы и стараемся следовать принципу наименьших привилегий (Principle of Least Privilege), иногда разработчикам необходимо знать, что происходит с их кодом в продакшене. С упомянутым выше интерфейсом и при правильно настроенных политиках RBAC, выдается ограниченный доступ к каждому приложению, которого будет достаточно для понимания общей картины происходящего.   

Как это согласуется с CI/CD? Как развертывать образы в реальной среде? Работает следующая последовательность: 

• Образ создается и помечается тегом по предопределенным правилам.

• ArgoCD Image Updater обнаруживает новый образ, который совпадает со стратегией обновления, и делает коммит в соответствующий git репозиторий.  

• ArgoCD синхронизирует изменения в кластере.

Но остается вопрос прозрачности процессов, так как после того, как образ отправлен в реестр Docker, нет никакой обратной связи. Мы не нашли ничего подходящего под наши задачи. И после нескольких дискуссий внутри команды решили потратить часть свободного времени чтобы написать свой собственный инструмент, Argo Watcher: https://github.com/shini4i/argo-watcher.

Argo Watcher – это связующее звено между пайплайнами и ArgoCD.

• Пайплайн отправляет задачу в Argo-Watcher и запрашивает обновление.

• Argo-Watcher делает запросы к ArgoCD API и проверяет, работает ли конкретное приложение на ожидаемой версии.

• Деплоймент считается успешным, если приложение работает на ожидаемой версии, если оно healthy и synced. 

• Если после тайм-аута приложение работает не на ожидаемой версии, или не синхронизировано, делается заключение, что загрузка прошла неудачно. 

К тому же Argo-Watcher выполняет функцию централизованной панели мониторинга, где показаны развертывания во всех проектах. Это тоже полезно, поскольку не все имеют доступ к git репозиториям. 

Как управлять инструментом, который управляет всем остальным

Развертывание и подготовка инфраструктуры к запуску ArgoCD реализована так:  

1. Используем Terraform для развертывания всего, что так или иначе относится к инфраструктуре.

2. Namespace/секреты для ArgoCD создаем с помощью Terraform. 

3. Деплоим ArgoCD также через Terraform с помощью Helm-провайдера. 

А все остальное делается через коммиты в git репозиторий.

Выводы 

Во-первых, стало намного проще отслеживать изменения. Теперь все мониторится централизованно, и нет необходимости перелопачивать десятки репозиториев, что сильно экономит время.   

Во-вторых, что важнее всего – такой подход практически исключает возможность дрифта конфигурации (когда конфигурация в git/скриптах отличается от того, что есть на самом деле). Потому что теперь каждое ручное (не через коммит в git) изменение автоматически убирается самим ArgoCD. Это дисциплинирует и предотвращает появление неприятных сюрпризов.  

На следующих этапах мы продолжили распространять GitOps на другие сферы: например, начали управлять Terraform-ом через Atlantis. 

В целом, переход на GitOps оказал положительный эффект на взаимодействие разработчиков с operations-командой. Мы получили более прозрачную и контролируемую систему, снизили количество ошибок. Мы будем продолжать развивать и улучшать нашу инфраструктуру, опираясь на принципы GitOps. 

Вадим Гедзь, ведущий DevOps инженер, Dyninno Technologies
https://github.com/shini4i