Когда Terraform становится занозой: хаос в коде, конфликты, дублирование, медленные ревью, риски безопасности и низкая скорость доставки... Чтобы платформенная команда могла управлять стандартами, а разработчики работали быстро и безопасно, команда построила нативный фреймворк для масштабирования Terraform без внешних инструментов.
Проблемы, которые они решали:
⚪️ Разные команды используют разные версии Terraform, providers и модулей
⚪️ Нет единого стандарта именования, тегов, backend иremote state
⚪️ Дублирование модулей и boilerplate-кода
⚪️ Ручные ревью и долгие проверки безопасности
⚪️ Отсутствие контроля за тем, кто и что деплоит в прод
Решение, которое помогло — Native Terraform Framework:
⚪️ Единый корневой root-модуль
Один общий Terraform-модуль, который все команды используют как базовый. Внутри — жестко прописанные правила.
⚪️ Модули как пакеты
Все модули лежат в одном моно-репозитории (или в отдельных, но с единым реестром). Каждая команда просто вызывает нужные модули. Обновление версии обновляет всех.
⚪️ OPA / Rego для политики
Вместо ручных ревью используют Open Policy Agent (OPA) + Conftest / Terraform Plan Policy.
⚪️ Self-service для разработчиков
Платформенная команда предоставляет готовые модули и политики. Разработчики не пишут сырой Terraform, а используют только утвержденные модули и следуют политикам. Это снижает ошибки и ускоряет доставку.
⚪️ GitOps-подход через GitHub Actions / GitLab CI
Главное — заставить всех использовать один и тот же источник истины (модули и политики), а не писать Terraform с нуля.
@DevOpsKaz 😛