Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps.
Если сильно упростить, схема примерно такая:
Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение
OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git.
Вместо привычного сценария:
> Зайди в AWS, поправь вот это.
> Потом сделай kubectl apply.
> А почему staging теперь отличается от production?
Получаем:
> Изменение инфраструктуры — commit.
> Изменение приложения — commit.
> Дальше автоматика сама приводит окружение к нужному состоянию.
И вот это уже интереснее, чем просто очередная связка инструментов.
IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения.
Плюсы очевидны:
⏺меньше ручных действий;
⏺изменения проходят review;
⏺инфраструктура воспроизводима;
⏺rollback часто превращается в git revert;
⏺окружение можно восстановить из кода.
Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane.
Отсюда возникают следующие вопросы:
⏺Что делать, если GitLab недоступен?
⏺Как внести emergency change?
⏺Кто имеет break-glass доступ?
⏺Можно ли восстановить инфраструктуру, если недоступны инструменты, которые ей управляют?
И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях💬
Желаем продуктивной недели и спокойных дежурных смен!