Модульная монорепа для Terraform: организация большого IaC

Когда Terraform-проект вырастает из пары директорий в десятки окружений, команд и облачных сервисов, хаос приходит быстро: дублирование кода, путаница с state, сложные ревью и опасные изменения. Один из рабочих подходов для крупного IaC — модульная монорепа. 🧩☁️⚙️

Что это такое
Монорепа — это один репозиторий, где хранятся:

• reusable-модули Terraform
• конфигурации окружений: dev, stage, prod
• общие политики, шаблоны CI/CD, документация
• иногда — terragrunt/скрипты/linters

Такой подход помогает централизовать управление инфраструктурой и видеть изменения целиком.

Как обычно строят структуру

• modules/ — переиспользуемые модули: VPC, Kubernetes, IAM, RDS
• live/ или envs/ — реальные инстансы инфраструктуры по окружениям и регионам
• global/ — ресурсы общего уровня: DNS, IAM federation, shared networks
• .github/ или .gitlab-ci/ — пайплайны, проверки, security scan
• docs/ — правила, схемы зависимостей, onboarding

Пример логики:

• модуль modules/vpc описывает сеть как шаблон
• envs/prod/eu-west-1/network вызывает этот модуль с конкретными параметрами

Почему это удобно 🚀

• Переиспользование — меньше копипаста, проще поддержка
• Единые стандарты — naming, tagging, security baseline
• Прозрачность изменений — видно, как обновление модуля влияет на окружения
• Удобный CI/CD — можно запускать fmt, validate, tflint, tfsec, plan централизованно
• Упрощение аудита — вся инфраструктура в одном месте

Ключевые правила, без которых монорепа начинает мешать

• Жестко разделяйте модули и live-конфиги. Модуль не должен хранить state и env-specific значения
• Не делайте один state на всё. Разбивайте state по сервисам, окружениям и регионам
• Фиксируйте версии модулей. Даже внутри монорепы важно контролировать, кто и когда обновился
• Настройте selective CI. Проверяйте только затронутые директории, иначе pipeline станет слишком медленным
• Внедрите CODEOWNERS. Ответственность за сеть, IAM, Kubernetes и базы должна быть разграничена
• Документируйте входы/выходы модулей. Иначе reusable-модуль быстро превращается в “магический черный ящик”

Частые ошибки ❌

• огромные “универсальные” модули на все случаи жизни
• смешивание prod и dev в одном state
• отсутствие политики review для опасных ресурсов
• хранение секретов в переменных и tfvars без Vault/Secrets Manager
• запуск terraform apply вручную без контролируемого CI

Когда монорепа подходит лучше всего

• много команд работают над общей инфраструктурой
• есть десятки одинаковых окружений
• нужны стандартизация, аудит и предсказуемые релизы
• инфраструктура активно развивается, а не живет в режиме “настроили и забыли”

Вывод

Модульная монорепа для Terraform — не просто “сложить всё в один git”. Это способ масштабировать IaC без потери управляемости. Главное — четкие границы модулей, изоляция state, автоматизированные проверки и дисциплина изменений. Тогда Terraform остается инструментом управления, а не источником инцидентов. 🔐🛠️

За качественной подборкой каналов про IT — загляните в закрепленную подборку.

🗣 Подборки каналов
🧠 Каталог ботов и приложений
🗺 Навигация