10 промтов для Terraform и IaC: от модулей до multi‑cloud

10 промтов для Terraform и IaC: от модулей до multi‑cloud

Terraform давно стал стандартом для управления инфраструктурой как кодом (IaC). Но даже опытные инженеры тратят часы на написание однотипных модулей, отладку state и настройку multi‑cloud окружений. Я собрал 10 проверенных промтов, которые использую в работе каждый день. Они помогают сгенерировать рабочий код, избежать типовых ошибок и сэкономить время. Каждый промт — готовый запрос к AI (ChatGPT, Claude или аналогам) с примером результата. Поехали.

1. Создание модуля VPC с настраиваемыми подсетями

Промт:

Напиши Terraform модуль для создания VPC в AWS с публичными, приватными и database‑подсетями. Количество подсетей каждого типа задаётся переменными public_subnets, private_subnets, database_subnets типа list(string). Добавь опцию enable_nat_gateway для выбора между single и multiple NAT Gateway. Следуй best practices HashiCorp: используй locals для вычислений и output для идентификаторов.

Пример результата:

# main.tf
resource "aws_vpc" "this" {
  cidr_block = var.cidr_block
  tags = merge(var.tags, { Name = var.name })
}

locals {
  public_subnet_count  = length(var.public_subnets)
  private_subnet_count = length(var.private_subnets)
  database_subnet_count = length(var.database_subnets)
}

resource "aws_subnet" "public" {
  count = local.public_subnet_count
  vpc_id     = aws_vpc.this.id
  cidr_block = var.public_subnets[count.index]
  map_public_ip_on_launch = true
  availability_zone = element(var.availability_zones, count.index)
}
...

Почему это работает: AI сразу генерирует структуру с count, element, merge — то, что новички часто пишут вручную с ошибками. Проверено на проектах с десятками VPC.

2. State backend на S3 с DynamoDB для блокировок

Промт:

Сгенерируй конфигурацию Terraform backend для хранения state‑файла в S3 bucket my-company-terraform-state с указанием ключа пути env/project/terraform.tfstate. Включи DynamoDB table terraform-state-lock для блокировок. Добавь workspace_key_prefix для изоляции workspace. Предположи, что S3 bucket и DynamoDB уже созданы отдельно.

Пример результата:

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "${var.environment}/${var.project}/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
    workspace_key_prefix = "env"
  }
}

Комментарий: Промт заставляет AI явно указать workspace_key_prefix — это критично для multi‑environment без путаницы. Источник: HashiCorp Terraform Backend S3.

3. Multi‑cloud: EKS (AWS) и GKE (GCP) в одном конфиге

Промт:

Напиши Terraform конфигурацию для развёртывания Kubernetes кластеров в двух облаках: AWS (EKS) и GCP (GKE). Используй модули terraform-aws-eks и terraform-google-kubernetes-engine. Для каждого кластера укажи разные node pools с автодополнением. Выведи kubeconfig для обоих кластеров. Используй provider alias для организации multi‑region.

Пример результата:

provider "aws" {
  region = "us-west-2"
}

provider "google" {
  project = "my-project"
  region  = "us-central1"
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.0.0"
  cluster_name = "my-eks"
  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets
  ...
}

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "30.0.0"
  project_id  = var.project_id
  name        = "my-gke"
  region      = "us-central1"
  ...
}

output "eks_kubeconfig" {
  value = module.eks.kubeconfig
}

output "gke_kubeconfig" {
  value = module.gke.kubeconfig
}

Реальный кейс: Используется в стартапах, где хотят избежать vendor lock‑in. AI сам подберёт корректные входные переменные модулей из Terraform Registry.

4. Импорт существующей инфраструктуры в state

Промт:

У меня есть существующий AWS EC2 instance с ID i-0abcd1234efgh5678, созданный вручную. Напиши Terraform resource для этого инстанса и команду terraform import, чтобы добавить его в state. Используй блок lifecycle { ignore_changes = [ami, user_data] }, чтобы не пересоздавать ресурс.

Пример результата:

resource "aws_instance" "existing" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  # другие атрибуты совпадающие с существующим

  lifecycle {
    ignore_changes = [ami, user_data]
  }
}

# terraform import aws_instance.existing i-0abcd1234efgh5678

Лайфхак: Промт требует ignore_changes — это защищает от дрифта, когда AMI обновляется автоматически. Без этого terraform apply может заменить инстанс.

5. Count vs for_each для динамических ресурсов

Промт:

Покажи разницу между использованием count и for_each на примере создания нескольких IAM users с разными политиками. Сначала используй count, затем перепиши на for_each. Объясни, почему for_each предпочтительнее при изменении списка.

Пример результата (for_each):

variable "users" {
  type = map(object({
    policy_arn = string
  }))
  default = {
    "alice" = { policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess" }
    "bob"   = { policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess" }
  }
}

resource "aws_iam_user" "this" {
  for_each = var.users
  name     = each.key
}

resource "aws_iam_user_policy_attachment" "this" {
  for_each = var.users
  user       = aws_iam_user.this[each.key].name
  policy_arn = each.value.policy_arn
}

Вывод: При удалении пользователя из map for_each корректно уничтожит только его, тогда как count при удалении элемента из середины списка пересоздаст все последующие. AI это объяснит и покажет наглядно.

6. Условная логика в модуле (create_only_if)

Промт:

Создай Terraform модуль для S3 bucket, который будет создавать bucket только если переменная create_bucket равна true. Также добавь возможность включить версионирование и шифрование через переменные enable_versioning и enable_encryption. Используй count = var.create_bucket ? 1 : 0.

Пример результата:

variable "create_bucket" {
  type    = bool
  default = false
}

resource "aws_s3_bucket" "this" {
  count  = var.create_bucket ? 1 : 0
  bucket = var.bucket_name
  ...
}

resource "aws_s3_bucket_versioning" "this" {
  count  = var.create_bucket && var.enable_versioning ? 1 : 0
  bucket = aws_s3_bucket.this[0].id
  versioning_configuration {
    status = "Enabled"
  }
}

Жизненный случай: В больших репозиториях модули часто включаются/выключаются флагами. Промт выдаёт готовую конструкцию с защитой от обращения к пустому ресурсу.

7. Remote state и data sources

Промт:

Напиши Terraform код для чтения remote state другого проекта из S3 bucket shared-state-bucket с ключом network/terraform.tfstate. Получи ID VPC и список публичных подсетей. Используй эти данные для создания EC2 instance в конфигурации текущего проекта.

Пример результата:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "shared-state-bucket"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_instance" "app" {
  ami           = var.ami
  instance_type = "t3.micro"
  subnet_id     = data.terraform_remote_state.network.outputs.public_subnet_ids[0]
  vpc_security_group_ids = [aws_security_group.app.id]
}

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

Важно: Промт заставляет AI выводить конкретные outputs из remote state. Без этого новички часто путаются в синтаксисе.

8. Workspace для сред dev/stage/prod

Промт:

Настрой Terraform workspace для трёх сред: dev, stage, prod. Используй файл terraform.tfvars для общих переменных и отдельные файлы dev.tfvars, stage.tfvars, prod.tfvars для переопределения. Напиши команды для создания и переключения workspace, а также пример модуля, который использует terraform.workspace для выбора размера инстанса.

Пример результата:

# variables.tf
variable "instance_type" {
  type = string
}

# main.tf
resource "aws_instance" "app" {
  instance_type = var.instance_type
  ...
}
# dev.tfvars
instance_type = "t3.micro"
# prod.tfvars
instance_type = "t3.large"
# Команды:
# terraform workspace new dev
# terraform apply -var-file="dev.tfvars"

Почему это полезно: AI напомнит про terraform workspace show и workspace new — мелочи, которые экономят время при ручном тестировании.

9. CI/CD с Terraform в GitLab CI

Промт:

Создай файл .gitlab-ci.yml для конвейера Terraform. Он должен состоять из четырёх стадий: validate, plan, apply, destroy (только для веток с тегом destroy). Используй образ hashicorp/terraform:1.8. Добавь артефакты для plan файла и логику запуска apply только при merge request в main.

Пример результата:

stages:
  - validate
  - plan
  - apply
  - destroy

before_script:
  - terraform init

validate:
  stage: validate
  script:
    - terraform validate

plan:
  stage: plan
  script:
    - terraform plan -out=plan.tfplan
  artifacts:
    paths:
      - plan.tfplan
  only:
    - merge_requests

apply:
  stage: apply
  script:
    - terraform apply plan.tfplan
  only:
    - main
  when: manual

destroy:
  stage: destroy
  script:
    - terraform destroy -auto-approve
  only:
    - tags
  except:
    - branches

Реальный кейс: На одном из проектов такой пайплин предотвратил случайный destroy из‑за неправильной ветки — AI сам расставил only и except.

10. Security: tflint, tfsec и pre‑commit hooks

Промт:

Создай файл .pre-commit-config.yaml с хуками для Terraform: tflint, tfsec, terraform fmt, checkov. Настрой tflint на глубокую проверку, tfsec на поиск уязвимостей (открытые порты, слабые политики). Добавь инструкцию по установке pre‑commit.

Пример результата:

repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.86.0
    hooks:
      - id: terraform_fmt
      - id: terraform_tflint
        args:
          - '--args=--deep'
      - id: terraform_tfsec
        args:
          - '--args=--severity=CRITICAL,HIGH'
      - id: terraform_checkov

Зачем это нужно: Промт заставляет AI выдать конкретные аргументы для tflint --deep и tfsec --severity. Это критично, потому что без уровней severity tfsec может пропустить опасные блоки.

Заключение

Эти 10 промтов покрывают 80% повседневных задач: от модулей и state до multi‑cloud и CI/CD. Они сэкономят вам часы работы и помогут избежать типовых граблей. Сохраните подборку в закладки — пригодится на каждом проекте. А если захотите углубиться, загляните в Terraform Best Practices и Terraform Registry.

Какие промты используете вы? Делитесь в комментариях — дополним список.