В какой-то момент в нашей команде стало очевидно: пора тащить всю инфраструктуру в Git — по-взрослому, через GitOps. Kubernetes у нас уже был, ArgoCD тоже. Осталось «дотащить» туда AWS-ресурсы, которые мы описываем с помощью AWS CDK.
Идея казалась простой: есть CDK-код в Git, запускается ArgoCD, всё красиво деплоится в облако. Но реальность оказалась совсем не такой. CDK — это не YAML и даже не Terraform. Это исполняемый код. GitOps — это про декларативность и kubectl apply
. CDK с этим не дружит.
Ожидалось, что наверняка есть готовый Kubernetes-оператор, который запускает cdk deploy
при изменении кода. Как это уже сделано для Terraform (через ArgoCD Terraform Controller), Pulumi, или хотя бы через ACK. Но после долгого ресерча выяснилось: нет ничего рабочего и production-ready.
Так появилась идея — написать собственный Kubernetes-оператор, который сможет:
- раз в какое-то время (или по коммиту в Git) запускать cdk deploy
;
- проверять cdk diff
и cdk drift
для отслеживания изменений и дрифта;
- удалять CloudFormation-стэк, если ресурс удалили из Git;
- интегрироваться с ArgoCD и Prometheus.
Получился полноценный GitOps-воркфлоу для AWS CDK — без пайплайнов, без ручных cdk deploy
, без дрейфующих стэков.
Под катом — расскажу, как мы подошли к проблеме, как устроен Custom Resource CdkTsStack
, какие фишки мы добавили (метрики, хуки, IAM-пользователи), и почему наш подход оказался практичнее, чем существующие альтернативы вроде Terraform Operator или Pulumi.