Какую бы сделал структуру файлов в Terraform?

Структура файлов и каталогов в Terraform

Я бы рекомендовал модульную структуру, основанную на принципах изоляции окружений и компонентов инфраструктуры. За 10+ лет работы с Terraform я убедился, что правильная организация — ключ к поддерживаемости и безопасности.

Базовая структура проекта

terraform-project/
├── modules/                    # Переиспользуемые модули
│   ├── network/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── compute/
│   └── database/
├── environments/               # Изоляция по окружениям
│   ├── dev/
│   ├── staging/
│   └── prod/
│       ├── terraform.tfvars    # Переменные окружения
│       ├── backend.tf          # Бэкенд для state-файлов
│       └── main.tf            # Вызов модулей
├── globals/                    # Глобальные настройки
│   ├── provider.tf
│   └── versions.tf
├── scripts/                    # Вспомогательные скрипты
└── README.md

Ключевые принципы организации

1. Разделение по окружениям Каждое окружение (dev, staging, prod) должно быть полностью изолировано:

• Отдельные state-файлы
• Разные значения переменных
• Возможность независимого деплоя

Пример структуры для окружения:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/network"
  
  cidr_block     = var.vpc_cidr
  enable_nat_gw  = true
  environment    = "prod"
}

# environments/prod/terraform.tfvars
vpc_cidr       = "10.0.0.0/16"
instance_count = 5
instance_type  = "t3.large"

2. Модульный подход Модули инкапсулируют логику и способствуют повторному использованию:

• Модули должны быть независимыми и тестируемыми
• Четкие интерфейсы через variables/outputs
• Версионирование модулей при использовании в нескольких проектах

# modules/network/variables.tf
variable "cidr_block" {
  description = "CIDR блок для VPC"
  type        = string
}

variable "enable_nat_gw" {
  description = "Включить NAT Gateway"
  type        = bool
  default     = false
}

3. Управление состоянием (State)

• Использование удаленного бэкенда (S3, GCS, Azure Storage)
• Блокировка состояния через DynamoDB или аналоги
• Раздельные бэкенды для окружений

# environments/prod/backend.tf
terraform {
  backend "s3" {
    bucket         = "terraform-state-prod"
    key            = "infrastructure/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Расширенная структура для enterprise-проектов

Для сложных проектов я добавляю:

terraform-project/
├── _templates/                 # Шаблоны для быстрого старта
├── policies/                   # Политики Sentinel/OPA
├── tests/                      # Интеграционные тесты
│   ├── terratest/
│   └── kitchen-terraform/
├── workflows/                  # GitHub Actions/GitLab CI
└── docs/                       # Документация

Практические рекомендации

1. Именование ресурсов — используйте стандартные префиксы:

resource "aws_instance" "app_server_prod" {
  tags = {
    Name        = "app-server-prod-001"
    Environment = "prod"
    Component   = "application"
  }
}

1. Управление версиями:

terraform {
  required_version = ">= 1.5.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

1. Безопасность:

• Никогда не храните секреты в коде
• Используйте Vault, AWS Secrets Manager, или переменные окружения
• Разделяйте права доступа между окружениями

1. Автоматизация:

• CI/CD пайплайны для проверки и деплоя
• Автоматический форматирование кода (terraform fmt)
• Статический анализ (tflint, checkov)

Рабочий процесс

Моя типичная рабочая структура включает:

# Инициализация проекта
terraform init -backend-config=backend.hcl

# Планирование изменений
terraform plan -var-file=prod.tfvars -out=plan.out

# Применение
terraform apply plan.out

# Валидация
terraform validate
terraform fmt -check

Золотое правило: Структура должна быть достаточно простой для понимания новыми членами команды, но достаточно гибкой для масштабирования. Я всегда начинаю с минимальной структуры и расширяю её по мере роста проекта, избегая преждевременной оптимизации. Ключевое — обеспечить повторное использование кода, изоляцию изменений и безопасную работу в команде.