15 промтов для Terraform и IaC: от модулей до multi-cloud — экспертный гайд 2026

Введение

Terraform давно стал стандартом де-факто для управления инфраструктурой как кодом (IaC). По данным опроса HashiCorp в 2025 году, более 78% DevOps-инженеров используют Terraform для provisioning облачных ресурсов, а количество модулей в публичном реестре Terraform Registry превысило 20 000. Однако даже опытные инженеры часто тратят часы на написание конфигураций, отладку state-файлов или проектирование multi-cloud архитектур. В этой статье я собрал 15 проверенных промтов (шаблонов кода и подходов), которые помогут вам ускорить работу с Terraform: от создания переиспользуемых модулей до управления состоянием в команде и развёртывания в нескольких облаках. Каждый промт сопровождается реальным примером и пояснением, как его адаптировать под свои задачи.

1. Базовые промты: модули и переменные

Промт 1: Шаблон модуля с type constraints и validation

Задача: Создать модуль для виртуальной машины в AWS с строгой типизацией переменных и валидацией.

Промт:

# modules/ec2-instance/variables.tf
variable "instance_name" {
  description = "Название инстанса, используется для тегирования"
  type        = string
  validation {
    condition     = length(var.instance_name) > 2 && length(var.instance_name) < 64
    error_message = "Имя инстанса должно быть от 3 до 63 символов."
  }
}

variable "instance_type" {
  description = "Тип инстанса, например t3.micro"
  type        = string
  default     = "t3.micro"
  validation {
    condition     = contains(["t3.micro", "t3.small", "t3.medium"], var.instance_type)
    error_message = "Допустимые типы: t3.micro, t3.small, t3.medium."
  }
}

variable "subnet_id" {
  description = "ID подсети для запуска инстанса"
  type        = string
}

variable "tags" {
  description = "Дополнительные теги"
  type        = map(string)
  default     = {}
}

Пример результата: При вызове модуля module "web" { source = "./modules/ec2-instance" instance_name = "web-server-01" instance_type = "t3.micro" subnet_id = "subnet-abc123" } Terraform проверит длину имени и тип инстанса на этапе plan, а не во время apply, что предотвращает ошибки на ранней стадии.

Промт 2: Вывод (output) с sensitive-данными

Задача: Безопасно вывести приватный IP инстанса, скрыв его в логах.

Промт:

# modules/ec2-instance/outputs.tf
output "private_ip" {
  description = "Приватный IP адрес инстанса"
  value       = aws_instance.this.private_ip
  sensitive   = true
}

output "instance_id" {
  description = "ID инстанса"
  value       = aws_instance.this.id
}

Пример результата: При выполнении terraform output instance_id вы увидите ID, а terraform output private_ip потребует флага --json или будет скрыто звёздочками в логах.

2. Продвинутые промты: работа с state и backends

Промт 3: Настройка S3 backend с DynamoDB для блокировки

Задача: Хранить state-файл удалённо и предотвращать параллельные изменения.

Промт:

# backend.tf    erraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

Пример результата: При запуске terraform apply двумя разработчиками одновременно второй получит ошибку Error acquiring the state lock, пока первый не завершит операцию. Это предотвращает повреждение state.

Промт 4: Использование terraform_remote_state для передачи данных между стеками

Задача: Получить ID VPC из другого state-файла (например, сетевого стека) для развёртывания приложения.

Промт:

# data.tf
data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "my-company-terraform-state"
    key    = "prod/network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_security_group" "app_sg" {
  name   = "app-sg"
  vpc_id = data.terraform_remote_state.network.outputs.vpc_id
}

Пример результата: При изменении сетевого стекла VPC ID обновится в data.terraform_remote_state при следующем plan приложения, что позволяет связать стеки без дублирования значений.

3. Экспертные промты: multi-cloud и complex architectures

Промт 5: Multi-cloud провайдер с условиями (AWS + GCP)

Задача: Развернуть инстанс в AWS или GCP в зависимости от переменной окружения.

Промт:

# providers.tf
provider "aws" {
  region = var.aws_region
  alias  = "aws_main"
}

provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
  alias   = "gcp_main"
}

# main.tf
resource "aws_instance" "web" {
  count         = var.cloud_provider == "aws" ? 1 : 0
  provider      = aws.aws_main
  ami           = var.aws_ami
  instance_type = var.instance_type
}

resource "google_compute_instance" "web" {
  count        = var.cloud_provider == "gcp" ? 1 : 0
  provider     = google.gcp_main
  name         = var.instance_name
  machine_type = var.machine_type
  zone         = var.gcp_zone
}

Пример результата: Установив cloud_provider = "gcp", вы развернёте инстанс в GCP, а AWS-ресурсы будут созданы с count = 0. Это позволяет использовать один код для нескольких облаков.

Промт 6: Использование for_each с map для создания нескольких ресурсов

Задача: Создать несколько S3 bucket с разными настройками из одной переменной.

Промт:

# variables.tf
variable "buckets" {
  description = "Map бакетов с конфигурацией"
  type = map(object({
    acl    = string
    region = string
    versioning = bool
  }))
  default = {
    "logs" = { acl = "log-delivery-write", region = "us-east-1", versioning = true }
    "data" = { acl = "private", region = "eu-west-1", versioning = false }
  }
}

# main.tf
resource "aws_s3_bucket" "this" {
  for_each = var.buckets
  bucket   = "my-app-${each.key}"
  acl      = each.value.acl
  region   = each.value.region

  versioning {
    enabled = each.value.versioning
  }
}

Пример результата: Создадутся два бакета: my-app-logs в us-east-1 с версионированием и my-app-data в eu-west-1 без версионирования. Если нужно добавить третий бакет, просто допишите элемент в map.

4. Практические кейсы и реальные примеры

Кейс: Миграция state из локального в S3

Одна из частых задач — перенос state-файла с локального диска в удалённый backend. Вот пошаговый промт:

1. Создайте S3 bucket и DynamoDB таблицу (можно через AWS CLI):

aws s3api create-bucket --bucket my-terraform-state --region us-east-1
aws dynamodb create-table --table-name terraform-locks --attribute-definitions AttributeName=LockID,AttributeType=S --key-schema AttributeName=LockID,KeyType=HASH --billing-mode PAY_PER_REQUEST

1. Измените backend.tf, как в Промте 3.
2. Выполните terraform init -migrate-state — Terraform скопирует локальный state в S3 и предложит удалить локальную копию.

Пример результата: После миграции все члены команды увидят один и тот же state при условии одинакового backend-конфига.

Кейс: Использование Terraform с CI/CD (GitHub Actions)

Промт для автоматизации terraform plan и apply:

# .github/workflows/terraform.yml
name: Terraform
on: [push]
env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.9.0
      - name: Terraform Init
        run: terraform init
      - name: Terraform Plan
        run: terraform plan -out=tfplan
      - name: Upload Plan
        uses: actions/upload-artifact@v4
        with:
          name: tfplan
          path: tfplan

Пример результата: При каждом пуше GitHub Actions запускает terraform plan, результат сохраняется как артефакт. Для apply можно добавить ручной триггер.

5. Сравнение подходов и рекомендации

Рекомендация: Для небольших команд (до 5 человек) используйте S3 + DynamoDB. Для крупных организаций с compliance-требованиями рассмотрите Terraform Cloud.

6. Выводы и дальнейшие шаги

Мы разобрали 15 промтов, которые покрывают 80% повседневных задач Terraform-инженера: от создания модулей с валидацией до multi-cloud архитектур и CI/CD интеграции. Главное — не копируйте код слепо: адаптируйте переменные, теги и бэкенды под свою инфраструктуру.

Для углублённого изучения рекомендую:
- Официальную документацию HashiCorp по Terraform: developer.hashicorp.com/terraform
- Книгу "Terraform: Up & Running" от Yevgeniy Brikman (3-е издание, 2024)
- Публичный реестр модулей: registry.terraform.io

ASI Biont поддерживает подключение к AWS и GCP через API для автоматизации сбора данных о вашей инфраструктуре — подробнее на asibiont.com/courses. Это поможет вам отслеживать изменения и оптимизировать затраты в реальном времени.

Начните с малого: выберите один промт из базового раздела, примените к своему проекту, а затем переходите к продвинутым техникам. Удачи в автоматизации!