Привет, я Даниил, DevOps-инженер в [KTS](https://kts.tech/devops).
Я работаю над инфраструктурой одной крупной сети. В ее штате несколько команд разработки, которые делят между собой больше 40 микросервисов, составляющих одну систему. Ожидаемо, со временем их dev-стенд сильно отстал от продакшена, и разные команды с трудом протаскивали новые фичи до релиза.
Мы в KTS уже давно продвигаем настройку динамических окружений для подобных систем. Пару лет назад мой коллега описывал, как они работают, и давал несколько рекомендаций по применению. Но это был, скорее, обзор.
Сегодня я расскажу, как мы внедрили динамические окружения на практике через ArgoCD и обтесали их под конкретные запросы разработчиков. Еще я попробую объяснить, почему такой подход здорово экономит время и нервы, и поделюсь соображениями о том, когда он будет только мешать.
Оглавление
Контекст
Что мы наделали
App-of-apps
Что пошло не так
Sync-wave
Жизненный цикл стенда
Что еще пошло не так
Когда это не нужно
Что в итоге
Контекст
Чтобы понять, откуда растут ноги нашей проблемы, представьте следующую конструкцию.
Команда А пилит фичу, которая меняет API в условном сервисе заказов. Чтобы ее протестировать, нужно еще обновить условный сервис уведомлений, который этот API дергает. Разработчики раскатывают обе доработки на dev и уходят заниматься другими задачами, потому что тестирование займет минимум неделю. Тестировщиков мало, очередь длинная.
Параллельно команда Б пилит свою фичу в том же сервисе уведомлений. Их фича не связана с API, она про что-то другое, но катится в тот же dev. Спустя неделю до нее доходят руки у тестировщика, и выясняется, что уведомления уже работают не так, как ожидала команда Б, потому что API заказов поменялся. Команде Б нужно вернуться в контекст недельной давности, доработать фичу и вернуть ее в очередь, чтобы тестировщики снова до нее дошли. Колесо Сансары делает полный оборот.
Фича, которую разработчики делали пару дней, доезжает до продакшена через месяц.
Один dev-стенд на всех работает, пока сервисов мало и команды могут договориться на словах. Но как только сервисов становится много, командам приходится либо стоять в очереди, либо мириться с тем, что чужая фича в смежном сервисе ломает их тест-кейсы.
Поднимать еще один dev-стенд — плохая идея по двум причинам. Во-первых, у большинства команд CI/CD заточен под одно окружение: имена неймспейсов, хосты, строки подключения к БД и домены захардкожены в helm values или в скриптах деплоя. Поднять параллельную копию означает переписать половину инфраструктурного кода. Во-вторых, даже если ее поднять, все равно непонятно, какая команда на каком стенде сидит и кто там что катит.
Зато есть хорошая идея: окружение, которое появляется автоматически под конкретный merge request, живет ровно столько, сколько нужно для проверки, и так же автоматически исчезает.
Что мы наделали
Изначальная идея выглядела амбициозно и изящно. Реализовать ее в чистом виде не получилось по ряду причин, но обо всем по порядку. Для понимания все равно важно разобраться, какой подход был предложен в начале.
Когда разработчик открывает MR в любом из сорока сервисов, CI запускает джобу, которая собирает для него отдельный стенд. На стенде поднимаются все сорок сервисов вместе с инфраструктурой (PostgreSQL, Kafka, Redis, MongoDB, ingress, сертификаты и так далее). Сервисы берутся в актуальных dev-версиях, кроме одного — того, в котором открыт MR. Для него подставляется образ из ветки MR.
Стенд изолирован. У него свой неймспейс, свои поддомены и своя база. Две параллельные фичи в смежных сервисах больше не конфликтуют, потому что у каждой свой стенд.
Когда MR закрывается, стенд удаляется. Если разработчик забыл закрыть MR, стенд все равно умрет через пять дней по TTL или вечером в пятницу, в зависимости от настройки. Есть отдельный режим «бессмертного» стенда для долгого тестирования, но тогда раз в неделю прилетает напоминание, что ресурсы тратятся.
Все построено на ArgoCD, app-of-apps и sync-wave.
App-of-apps
CI ничего не разворачивает в кластер напрямую. Он создает в ArgoCD одно родительское приложение, которое указывает на наш Helm-чарт со всем описанием стенда. Этот чарт при рендере генерирует дочерние ArgoCD Application, по одному на каждый сервис из каталога и на каждую вспомогательную систему. ArgoCD дальше сам раскладывает все это по кластеру.
Родительский Application выглядит примерно так:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: feature-325
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: dynamic-env
source:
repoURL: https://gitlab.example.com/devops/parent-helm-chart.git
targetRevision: main
path: "."
helm:
values: |
domain: "feature-325.dev.example.com"
stand:
ttlDays: 5
cleanupFridayEvening: false
immortalNotifyAfterDays: 7
postgresql:
enabled: true
kafka:
enabled: true
valkey:
enabled: true
services:
orders-service:
image: { tag: latest }
notifications-service:
image: { tag: feature-325 }
payments-service:
image: { tag: latest }
# ... ещё ~37 сервисов
destination:
name: dynamic-env
namespace: argocd
syncPolicy:
automated:
enabled: false
Все, что нужно знать о стенде, лежит в этих значениях: какой образ для какого сервиса, какие вспомогательные системы поднимать, какие заданы TTL и политики удаления. CI собирает values, ArgoCD приводит кластер в нужное состояние.
Что пошло не так
Сначала мы хотели брать сервисы по веткам с тем же именем, что у MR. Если открыт, к примеру, feature-325, то для всех сервисов CI ищет ветку feature-325. Если она есть, то образ берется оттуда, а если нет, то из ветки по умолчанию.
Так сделать не получилось. Имена веток были привязаны к задачам в трекере, и для каждого сервиса задача своя. То есть даже если фича сквозная, ветки в разных репозиториях называются по-разному. Сопоставить их по имени невозможно.
В качестве компромисса мы решили использовать одноименные теги. Когда разработчику нужен сборный стенд из доработок нескольких сервисов, он вешает один и тот же тег (например, test-stand-42) на нужные коммиты во всех нужных репозиториях. CI обходит список сервисов через GitLab API и берет образы, на которых есть этот тег, а для сервисов без тега берется образ по умолчанию (обычно latest из dev).
Теги, в отличие от веток, не привязаны к процессу разработки и трекеру, их можно вешать как угодно. И да, такой подход выглядит менее элегантно, чем автоматическое поднятие стенда по кнопке «открыть MR», зато работает в реальности, а не в вакууме.
Sync-wave
Отдельный блок стоит посвятить очередности деплоя в динамическом окружении. Если запустить все сервисы параллельно, половина уйдет в CrashLoopBackOff, потому что не дождется базы.
ArgoCD умеет упорядочивать деплой через аннотации argocd.argoproj.io/sync-wave: каждому дочернему Application присваивается номер волны, и ArgoCD катит волну за волной, дожидаясь готовности предыдущей. Распределение примерно такое:
Первой волной разворачиваются служебные ресурсы стенда: AppProject, RBAC для сервисного аккаунта и CronJob, который снесет стенд по TTL или в пятницу вечером.
Во второй волне идут базы данных и брокеры: PostgreSQL через оператор, Kafka, Redis/Valkey, MongoDB. Managed-решения сознательно не используем: для динамических стендов managed-БД получаются неоправданно дорогими.
Третьей волной поднимаются сервисы, которые зависят только от баз: API, базовые бэкенды (все, что не дергает другие сервисы).
В четвертую (и возможные следующие волны) уже входят сервисы, зависящие от других сервисов. Все дальнейшие волны формируются по графу зависимостей конкретной системы.
ArgoCD проверяет, что предыдущая волна в статусе Healthy, и только тогда переходит к следующей. Когда сходится последняя волна, ссылка приходит в MR.
Жизненный цикл стенда
Истина о том, что должно работать в кластере, всегда лежит в Git и в ArgoCD. CI только подкручивает values и нажимает кнопку. Это удобно для аудита: можно посмотреть состояние любого стенда в любой момент, ничего не нужно реконструировать по логам пайплайнов.
Что еще пошло не так
Вот и обещанный блок о том, что еще мы доделывали под неидеальную действительность.
Спустя пару недель после первых демо одна из команд разработки сообщила, что иногда им нужно поднимать стенд не на dev-образах, а на прод-образах, чтобы быстро проверять срочные фичи в обход спринта. Prod у них сильно отстает от dev, за несколько месяцев накапливается приличный разрыв. Один набор дефолтных values этот сценарий не покрывает.
Пришлось завести два профиля дефолтов: dev и prod. Разработчик при запуске стенда выбирает базу, поверх которой накатываются его доработки. Это потянуло за собой обязательство поддерживать prod-профиль в актуальном состоянии: после каждого релиза в прод нужно обновлять дефолтные теги в prod-профиле. А это тоже регулярная ручная работа.
Мораль здесь простая и скучная: динамическое окружение — это система, которую нужно поддерживать. Сервисы развиваются, появляются новые зависимости (вчера сервис не ходил в Redis, сегодня ходит), и кто-то должен обновлять каталог дефолтных values. Полностью бесплатной и самоподдерживающейся такая инфраструктура не бывает.
Когда это не нужно
Если в вашей системе два-три сервиса, то поднимать отдельное окружение под каждую фичу смысла нет. ArgoCD ApplicationSet с вебхуком на GitLab и простой Helm-чарт закрывают потребность раз в десять дешевле.
Порог окупаемости — где-то в районе десяти-пятнадцати сервисов при наличии нескольких параллельных команд. Выше этого значения экономия начинает быть ощутимой. Девопс не разворачивает стенд вручную по полдня, тестировщики не стоят в очереди к общему dev-стенду, а разработчики намного реже возвращаются в контекст двухнедельной давности.
Плюс есть еще одно важное условие: вы должны быть готовы держать GitOps как основной интерфейс. Если в вашей команде принято катить руками через kubectl, и вам хочется так и продолжать, то ArgoCD будет мешать, а не помогать. Здесь смысл именно в том, что состояние стендов описано декларативно и хранится в Git, и это дает возможность откатить весь стенд одним коммитом.
Что в итоге
Главная метрика, на которую я предлагаю ориентироваться — сколько времени проходит с открытия MR до момента, когда тестировщик уже может потыкать новую фичу. При общем dev-стенде это был срок от пары дней до недели. На динамических стендах весь процесс занимает пятнадцать-двадцать минут, по истечении которых в комментарии к MR появляется ссылка на готовое окружение.
Еще мы прикинули, сколько фич возвращается на доработку из-за конфликта с чужой фичей в смежном сервисе. Точные цифры заказчика приводить не буду, но переход на динамические стенды убрал эту категорию проблем почти полностью. Теперь подобные конфликты обнаруживаются на этапе слияния веток в dev, а не во время тестирования, и исправляются за несколько часов, а не дней или недель.
Само собой, такая инфраструктура стоит больше, чем один общий dev, потому что несколько стендов одновременно жрут больше ресурсов, чем один. Но TTL и пятничная очистка держат это в рамках. И важно помнить, что дороже всего стоят не CPU и память, а разработчики. Мы экономим их время, и все остальное окупается с большим запасом.
Если хотите дополнить материал или уточнить какие-то подробности, жду вас в комментариях. А если интересно узнать больше о том, как мы работаем с инфраструктурой, предлагаю к прочтению статьи моих коллег: