Всем привет! Хочу поделиться вариантом организации динамических окружений для разработки и тестирования с помощью ArgoCD и применением GitOps подхода на реальном примере. Статья рассчитана на DevOps инженеров и разработчиков уже хорошо знакомых с такими инструментами как: Kubernetes Helm Crossplane ArgoCD GitLab CI Краткая логика работы пайплайна.  Разработчик пушит новую ветку c постфиксом ‑dyn в названии в репозиторий с project-backend Стартует GitLabCI пайплайн: билдит docker image, пушит его в image registry; «идет» в репозиторий manifests, отрезает новую ветку — имя которой идентичное имени ветки в исходном репозитории — project-backend; обновляет image tag контейнера в Helm values для окружения и пушит изменения. ApplicationSet в ArgoCD отслеживает изменение в репозитории manifests, «видит» новую ветку с постфиксом и создает новый Application вместе с базой. При удалении ветки из репозитория — удаляется App и БД из облака. Из официальной документации ArgoCD с переводом: Argo CD следует схеме GitOps, использующей репозитории Git в качестве источника достоверной информации для определения желаемого состояния приложения. Argo CD реализован как контроллер kubernetes, который постоянно отслеживает запущенные приложения и сравнивает текущее рабочее состояние с желаемым целевым состоянием (как указано в репозитории Git). Развернутое приложение, текущее состояние которого отличается от целевого состояния, считается OutOfSync. Argo CD сообщает и визуализирует различия, предоставляя средства для автоматической или ручной синхронизации реального состояния с желаемым целевым состоянием. Любые изменения, внесенные в желаемое целевое состояние в репозитории Git, могут автоматически применяться и отражаться в указанных целевых средах. Crossplane позволяет описывать облачные ресурсы в формате k8s yaml манифестов, «применять» их в кластер и создавать ресурсы в облаке согласно описанному состоянию. Вводные: используем ресурсы в Yandex Cloud; классический проект -2 репозитория — project-frontend, project-backend; артефакты (docker image) проекта «собираются» в GitLab CI; собранные артефакты проекта — 2 docker image — project-frontend, project-backend; приложение деплоится в Kubernetes cluster через Helm (имеет Helm chart); Git репозиторий manifests с Helm charts приложения и crossplane ресурсов (БД, DataTransfer и т. д.); для работы project-backend необходима база данных — PostgreSQL — для создания БД используем Yandex Cloud DataTransfer — копируем данные из исходной — «эталонной» БД в новую. project-dyn-envs-manifest-repo-scm.yaml ApplicationSet использует SCM provider geneator — позволяет по тригеру (появлению в репозитории manifestsновой ветки, имя которой попадает по Regexp создавать новое приложения в ArgoCD) AppSet генерирует параметры (helm values) для нового приложения на основе имени ветки. Можно использовать в параметрах sha комита или например имя репозитория, полный список параметров можно посмотреть в документации генератора. Допустим crossplane уже установлен и сконфигурирован в кластере. Crossplane используем для создания новой БД для project-bakcned и DataTranser. При создании окружения БД через DataTransfer копируется из исходной — эталонной БД в новую созданную для окружения. Манифесты Crossplane «упакованы» в Helm chart, приведу пример templates и valuesдля Yandex Cloud. Новая БД для project-backend db-target.yaml. Тут важный момент — мы используем отдельно созданный кластер PostgreSQL для всех БД в динамических окружениях, который под управлением Terraform — он импортирован в Crossplane как внешний ресурс. Но никто не мешает создавать новые кластера Postgres из Crosplane.  БД пользователь — в Yandex Cloud пользователей можно создавать только через API: db-user-target.yaml datatransfer.yaml project-dyn-infra - values Через Crossplane невозможно изменять параметры endpoints (политика копирования, порядок переноса данных) в DataTransfer, так же нет возможности активировать DataTransfer с параметром SNAPSHOT_ONLY — это возможно сделать только через API. Для обхода ограничений в values (project-backend) init container который изменяет параметры DataTransfer после его создания, активирует трансфер и проверяет его статус. После успешного завершения — стартует контейнер с беком. В чарт с беком (project-backend) добавлен ConfigMap в котором описан скрипт — entrypoint для init container (dynInitEntrypointDta) — скрипт монтируется как extraVolumes в init container. Для определения — с каким именно трансфером должен работать скрипт «проброшено» имя ветки через ConfigMap — dynenv в init container Что бы не генерить новые DNS записи для окружений заведена запись указывающая на балансир кластера — *.dyn.project.ru имя ветки — id окружения; постфикс dyn и имя проекта в имени ветки (PROJECT-7777-my-branch-dyn); одинаковое имя ветки в репозитории фронта и бека; длина имени ветки не более 63 символов; при создании окружения берется из эталонной БД на момент деплоя окружения; при обновлении версии бека — БД не пересоздается — если нужно пересоздать — дропаем App в ArgoCD; трансфер БД требует времени; нет актуализации версии бека и фронта с продом (деплоим фронт — фронт соберется, версия бека будет из dev ветки manifests (project-stack/dyn/values.yaml); при копировании БД не переносятся math views — ограничение DataTransfer; список созданных окружений можно посмотреть только в ArgoCD; удаление окружения и ресурсов = удаление ветки в manifests.