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

Введение

Инфраструктура как код (IaC) давно перестала быть роскошью — это стандарт для любой серьёзной облачной архитектуры. Terraform от HashiCorp остаётся одним из самых популярных инструментов для управления инфраструктурой, и в 2026 году его экосистема продолжает развиваться: поддержка HCLv2, улучшенная работа с state, интеграция с Kubernetes и multi-cloud сценарии. Однако даже опытные инженеры часто тратят часы на написание однотипных конфигураций, отладку зависимостей или миграцию state. Промты — это не просто команды, это шаблоны мышления, которые ускоряют разработку и уменьшают количество ошибок. В этой статье я собрал 10 промтов для Terraform, разбитых на три уровня сложности: базовые (для новичков), продвинутые (для уверенных пользователей) и экспертные (для архитекторов и DevOps-инженеров). Каждый промт содержит конкретную задачу, сам промт и пример результата.

Базовые промты

1. Инициализация и структура проекта

Задача: Создать минимальную структуру Terraform-проекта с корректным main.tf, variables.tf и outputs.tf.
Промт: «Сгенерируй структуру Terraform-проекта для развёртывания одиночной виртуальной машины в AWS. Используй HCLv2. Включи файлы: main.tf (провайдер AWS, ресурс aws_instance), variables.tf (переменные для региона, типа инстанса, AMI), outputs.tf (вывод публичного IP). Провайдер версии ~> 5.0.»
Пример результата:

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type
  tags = {
    Name = "ExampleInstance"
  }
}

# variables.tf
variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "ami_id" {
  description = "AMI ID"
  type        = string
}

# outputs.tf
output "public_ip" {
  value = aws_instance.web.public_ip
}

2. Управление state-файлами

Задача: Настроить удалённое хранение state в S3 с блокировкой через DynamoDB.
Промт: «Создай backend-конфигурацию для Terraform state в AWS S3. Используй bucket 'my-terraform-state-2026', ключ 'prod/terraform.tfstate', регион 'eu-west-1'. Добавь таблицу DynamoDB 'terraform-locks' для блокировки. Включи шифрование AES-256.»
Пример результата:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-2026"
    key            = "prod/terraform.tfstate"
    region         = "eu-west-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

3. Простой модуль для VPC

Задача: Создать переиспользуемый модуль для VPC с подсетями.
Промт: «Напиши модуль Terraform для VPC в AWS. Должен принимать параметры: имя VPC, CIDR-блок (по умолчанию 10.0.0.0/16), количество публичных подсетей (2) и приватных (2). Создай Internet Gateway и route tables. Используй count для итерации. Выведи ID подсетей.»
Пример результата (фрагмент):

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block = var.cidr_block
  tags = {
    Name = var.vpc_name
  }
}

resource "aws_subnet" "public" {
  count                   = var.public_subnet_count
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.cidr_block, 8, count.index)
  map_public_ip_on_launch = true
  tags = {
    Name = "${var.vpc_name}-public-${count.index}"
  }
}

Продвинутые промты

4. Работа с Terraform Workspaces

Задача: Использовать workspaces для разделения окружений (dev/staging/prod).
Промт: «Создай Terraform-конфигурацию, которая использует workspaces. Для workspace 'dev' используй t2.micro, для 'staging' — t3.small, для 'prod' — t3.large. Переменные окружения задай через terraform.workspace. Добавь условие: в prod включи deletion_protection для RDS.»
Пример результата:

locals {
  instance_type_map = {
    dev     = "t2.micro"
    staging = "t3.small"
    prod    = "t3.large"
  }
  is_prod = terraform.workspace == "prod"
}

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = local.instance_type_map[terraform.workspace]
}

resource "aws_db_instance" "default" {
  deletion_protection = local.is_prod
  # ... other config
}

5. Data sources и внешние зависимости

Задача: Получить текущий IP для security group и AMI ID по имени.
Промт: «Используй data sources: aws_ip_ranges для получения IP AWS CloudFront, aws_ami для последнего Amazon Linux 2. Создай security group, разрешающий HTTPS только с этих IP. Добавь в aws_instance последнюю AMI.»
Пример результата:

data "aws_ip_ranges" "cloudfront" {
  regions  = ["us-east-1"]
  services = ["cloudfront"]
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_security_group" "web" {
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = data.aws_ip_ranges.cloudfront.cidr_blocks
  }
}

6. Terraform и Kubernetes (EKS)

Задача: Развернуть кластер EKS с управляемыми node groups.
Промт: «Создай модуль для EKS: кластер с Kubernetes version 1.29, node group из t3.medium (2-5 узлов), включи cluster logging для всех компонентов. Используй aws_eks_cluster и aws_eks_node_group. Добавь aws_iam_role для узлов с политиками AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly.»
Пример результата (фрагмент):

resource "aws_eks_cluster" "main" {
  name     = "my-eks-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.29"
  vpc_config {
    subnet_ids = var.subnet_ids
  }
  enabled_cluster_log_types = ["api", "audit", "authenticator"]
}

resource "aws_eks_node_group" "workers" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "workers"
  node_role_arn   = aws_iam_role.eks_nodes.arn
  subnet_ids      = var.subnet_ids
  scaling_config {
    desired_size = 2
    max_size     = 5
    min_size     = 2
  }
  instance_types = ["t3.medium"]
}

Экспертные промты

7. Multi-cloud: Terraform для AWS и GCP одновременно

Задача: Развернуть приложение в AWS и GCP с единым управлением.
Промт: «Создай root-модуль, который использует провайдеры AWS и GCP. В AWS разверни EC2 с nginx, в GCP — Compute Instance с тем же приложением. Используй переменную cloud_provider для выбора: 'aws', 'gcp' или 'both'. Для 'both' создай оба ресурса и выведи их IP. Используй count и for_each условно.»
Пример результата:

variable "cloud_provider" {
  type    = string
  default = "both"
}

provider "aws" {
  region = "us-east-1"
}

provider "google" {
  project = var.gcp_project
  region  = "us-central1"
}

resource "aws_instance" "web" {
  count = var.cloud_provider == "aws" || var.cloud_provider == "both" ? 1 : 0
  ami   = var.aws_ami
  instance_type = "t3.micro"
}

resource "google_compute_instance" "web" {
  count = var.cloud_provider == "gcp" || var.cloud_provider == "both" ? 1 : 0
  name  = "web-vm"
  machine_type = "e2-micro"
  zone  = "us-central1-a"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
  }
}

output "aws_ip" {
  value = var.cloud_provider == "aws" || var.cloud_provider == "both" ? aws_instance.web[0].public_ip : null
}

output "gcp_ip" {
  value = var.cloud_provider == "gcp" || var.cloud_provider == "both" ? google_compute_instance.web[0].network_interface[0].access_config[0].nat_ip : null
}

8. Terraform State Migration и импорт

Задача: Импортировать существующий S3 bucket в управление Terraform без удаления.
Промт: «Напиши конфигурацию для импорта существующего S3 bucket 'my-legacy-bucket-2020' в Terraform. Используй terraform import. Включи в ресурс aws_s3_bucket все атрибуты, которые уже есть у bucket: versioning, ACL, encryption. Выполни terraform plan для проверки, что нет изменений.»
Пример результата:

# Команда импорта
terraform import aws_s3_bucket.legacy my-legacy-bucket-2020

# main.tf
resource "aws_s3_bucket" "legacy" {
  bucket = "my-legacy-bucket-2020"
  acl    = "private"
  versioning {
    enabled = true
  }
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

9. Terraform и GitOps: автоматизация через CI/CD

Задача: Создать пайплайн GitHub Actions для Terraform с планом и применением вручную.
Промт: «Создай GitHub Actions workflow для Terraform: на push в main — запусти terraform plan, сохрани план как артефакт. На создание issue с тегом 'terraform-apply' — запусти terraform apply из сохранённого плана. Используй hashicorp/setup-terraform action. Для state используй S3 backend. Добавь проверку форматирования terraform fmt.»
Пример результата (фрагмент YAML):

name: 'Terraform CI/CD'

on:
  push:
    branches: [ main ]
  issues:
    types: [opened]

jobs:
  plan:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.6.0
      - run: terraform fmt -check
      - run: terraform init
      - run: terraform plan -out=tfplan
      - uses: actions/upload-artifact@v4
        with:
          name: tfplan
          path: tfplan

  apply:
    if: github.event_name == 'issues' && contains(github.event.issue.labels.*.name, 'terraform-apply')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v2
      - run: terraform init
      - uses: actions/download-artifact@v4
        with:
          name: tfplan
      - run: terraform apply tfplan

10. Terraform и Sentinel: политики безопасности

Задача: Написать политику Sentinel для запрета публичных S3 buckets.
Промт: «Создай политику Sentinel для Terraform Cloud/Enterprise, которая запрещает создание S3 buckets с public ACL или public block policy disabled. Политика должна проверять ресурс aws_s3_bucket и aws_s3_bucket_public_access_block. Верни ошибку с сообщением, если bucket публичный. Примени политику к workspace 'prod'.»
Пример результата:

# policy.sentinel
import "tfplan"

resource_s3_buckets = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_s3_bucket" and
  rc.change.after is not null
}

check_public_access = rule {
  all resource_s3_buckets as _, bucket {
    bucket.change.after.acl is "private" or bucket.change.after.acl is null
  }
}

# Дополнительная проверка на public_access_block
resource_public_access = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_s3_bucket_public_access_block" and
  rc.change.after is not null
}

check_block = rule {
  all resource_public_access as _, block {
    block.change.after.block_public_acls is true and
    block.change.after.block_public_policy is true and
    block.change.after.ignore_public_acls is true and
    block.change.after.restrict_public_buckets is true
  }
}

main = rule {
  check_public_access and check_block
}

Заключение

Terraform — это мощный инструмент, но его эффективность напрямую зависит от того, насколько хорошо вы владеете промтами и шаблонами. Базовые промты помогают быстро стартовать, продвинутые — автоматизировать рутину, а экспертные — строить сложные multi-cloud архитектуры с соблюдением политик безопасности. В 2026 году, когда облака становятся всё более гетерогенными, умение писать качественные промты для Terraform — это навык, который отличает инженера от архитектора. Практикуйтесь, используйте модули и не забывайте про state: он — сердце вашей инфраструктуры. Если вы хотите углубить знания по Terraform и IaC, обратите внимание на специализированные курсы — например, на asibiont.com есть материалы по интеграции Terraform с AWS и GCP, которые помогут закрепить эти промты на практике.