Привет, я Даниил, DevOps-инженер в KTS.
Я работаю над инфраструктурой одной крупной сети. В ее штате несколько команд разработки, которые делят между собой больше 40 микросервисов, составляющих одну систему. Ожидаемо, со временем их dev-стенд сильно отстал от продакшена, и разные команды с трудом протаскивали новые фичи до релиза.
Мы в KTS уже давно продвигаем настройку динамических окружений для подобных систем. Пару лет назад мой коллега описывал, как они работают, и давал несколько рекомендаций по применению. Но это был, скорее, обзор.
Сегодня я расскажу, как мы внедрили динамические окружения на практике через ArgoCD и обтесали их под конкретные запросы разработчиков. Еще я попробую объяснить, почему такой подход здорово экономит время и нервы, и поделюсь соображениями о том, когда он будет только мешать.
Оглавление
Контекст
Чтобы понять, откуда растут ноги нашей проблемы, представьте следующую конструкцию.
Команда А пилит фичу, которая меняет 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/v1alpha1kind: Applicationmetadata: name: feature-325 namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.iospec: 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.
Жизненный цикл стенда
Картинка с диаграммой ЖЦ очень сильно сжимается, поэтому просто прикреплю ее код. Чтобы посмотреть, скопируйте его в рендерер https://mermaid.live/edit:
flowchart TD A[Разработчик вешает одинаковый тег<br/>на нужные коммиты в репозиториях<br/>задействованных сервисов] --> B[Запускакется джоба деплоя стенда<br/>в пайплайне одного из сервисов] B --> C[CI обходит каталог сервисов<br/>через GitLab API] C --> D{Есть тег<br/>в репозитории<br/>сервиса?} D -->|да| E[Берётся образ,<br/>собранный по тегу] D -->|нет| F{Какой профиль у стенда?} F -->|dev| G[Берётся дефолтный<br/>dev-образ] F -->|prod| H[Берётся дефолтный<br/>prod-образ] E --> I[Формируется values<br/>для родительского Helm-чарта] G --> I H --> I I --> J{Стенд должен быть бессмертным?} J -->|нет| K[Будет включен CronJob удаления по TTL<br/>и пятничной очистки] J -->|да| L[Будет включен CronJob еженедельного напоминания<br/>о расходе ресурсов] K --> M[Применяется один родительский<br/>ArgoCD Application] L --> M M --> N[Волна 1: служебные ресурсы<br/>AppProject, RBAC, CronJob] N --> O[Волна 2: базы данных и брокеры<br/>PostgreSQL, Kafka, Redis, MongoDB] O --> P[Волна 3: сервисы,<br/>зависящие только от баз] P --> Q[Волны 4+: сервисы по графу<br/>зависимостей друг от друга] Q --> R[Стенд готов,<br/>ссылка приходит в MR / в чат] R --> S[Разработка и тестирование] S --> T{Триггер<br/>удаления} T -->|MR закрыт| U[CI удаляет родительский Application] T -->|TTL истёк| U T -->|пятничная очистка| U U --> V[ArgoCD по финализатору<br/>сносит дочерние Application<br/>и все ресурсы стенда]
Истина о том, что должно работать в кластере, всегда лежит в 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 и память, а разработчики. Мы экономим их время, и все остальное окупается с большим запасом.
Если хотите дополнить материал или уточнить какие-то подробности, жду вас в комментариях. А если интересно узнать больше о том, как мы работаем с инфраструктурой, предлагаю к прочтению статьи моих коллег:
ссылка на оригинал статьи https://habr.com/ru/articles/1041242/