Terraform за 30 минут: поднимаем облачную инфраструктуру кодом

Представьте: вы только что получили задачу развернуть новый сервис в облаке. Нужно создать виртуальную машину, настроить сеть, выдать права доступа, подключить балансировщик нагрузки. Можно зайти в веб-консоль провайдера и кликать по интерфейсу час-полтора. А можно написать несколько десятков строк кода и запустить одну команду. Через три минуты инфраструктура готова — воспроизводимая, версионированная, задокументированная самим фактом своего существования.

Именно это делает Terraform. И именно поэтому за последние несколько лет он стал де-факто стандартом в DevOps-практике.

Что такое Infrastructure as Code и почему это важно

Infrastructure as Code (IaC) — подход, при котором инфраструктура описывается в виде кода, а не настраивается вручную через интерфейсы или скрипты. Звучит как абстракция, но последствия вполне конкретны.

Воспроизводимость. Если инфраструктура описана кодом, её можно поднять заново в любой момент — идентично. Не «примерно так же», а побитово одинаково. Это критично при восстановлении после сбоев, при масштабировании и при создании тестовых окружений.

Версионирование. Код живёт в Git. Значит, у вас есть история изменений: кто, когда и зачем добавил новый сервер или изменил правила файрвола. Code review для инфраструктурных изменений — это уже норма в зрелых командах.

Устранение «снежинок». Серверы, настроенные вручную, со временем расходятся в конфигурации. Один администратор поставил пакет, другой — нет. Один изменил параметр ядра, другой забыл. IaC решает эту проблему на уровне архитектуры: всё, что не описано в коде, не существует.

Скорость. Ручная настройка облачного окружения занимает часы. Terraform применяет конфигурацию за минуты.

До появления зрелых IaC-инструментов DevOps-инженеры писали bash-скрипты или использовали CloudFormation (для AWS). Оба подхода работали, но имели серьёзные ограничения: скрипты хрупки и не отслеживают состояние, CloudFormation привязан к одному провайдеру. Terraform появился в 2014 году и предложил другое: декларативный язык, мультиоблачность и механизм state, который отслеживает реальное состояние инфраструктуры.

Как работает Terraform: ключевые концепции

Прежде чем писать код, стоит разобраться с тем, как Terraform думает.

Декларативность

Вы описываете желаемое состояние, а не последовательность действий. Не «создай сервер, потом добавь диск, потом настрой сеть», а «вот как должна выглядеть инфраструктура». Terraform сам вычисляет, что нужно сделать, чтобы привести реальность в соответствие с описанием.

State

Terraform хранит информацию о созданных ресурсах в файле terraform.tfstate. Это его «память» о том, что уже существует в облаке. При каждом запуске он сравнивает желаемое состояние (ваш код) с текущим (state) и реальным (облако) — и вычисляет минимальный набор изменений.

В командных проектах state хранят удалённо — в S3, GCS или Terraform Cloud — чтобы несколько инженеров работали с одним источником истины.

Providers

Provider — это плагин, который умеет общаться с конкретным API: AWS, Google Cloud, Azure, Yandex Cloud, Kubernetes, GitHub и сотнями других. Провайдеры описывают доступные ресурсы и их параметры. Terraform Registry содержит тысячи провайдеров — от крупных облаков до нишевых сервисов.

Plan / Apply / Destroy

Рабочий цикл Terraform состоит из трёх команд:

• terraform plan — показывает, что будет сделано, без реальных изменений
• terraform apply — применяет изменения
• terraform destroy — удаляет все ресурсы, описанные в конфигурации

plan перед apply — это не опция, это обязательная практика. Всегда смотрите план перед применением.

Установка и первый запуск

Установка

Terraform распространяется как единый бинарный файл. На macOS проще всего через Homebrew:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

На Ubuntu/Debian:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

Проверяем:

terraform version
# Terraform v1.7.x

Структура проекта

Минимальный Terraform-проект — это директория с .tf-файлами. Terraform читает все файлы с этим расширением в директории и собирает из них единую конфигурацию. Типичная структура:

project/
├── main.tf        # основные ресурсы
├── variables.tf   # объявление переменных
├── outputs.tf     # выходные значения
├── versions.tf    # требования к версиям
└── terraform.tfvars  # значения переменных (не коммитить с секретами!)

Пишем первую конфигурацию: сервер в облаке

Для примера возьмём AWS — самый распространённый провайдер в обучающих материалах. Логика идентична для любого другого облака, меняются только названия ресурсов и параметры.

versions.tf — фиксируем версии

terraform {
  required_version = ">= 1.5.0"

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

Фиксировать версии провайдеров — обязательная практика. Без этого обновление провайдера может сломать конфигурацию в самый неподходящий момент.

main.tf — провайдер и ресурсы

provider "aws" {
  region = var.aws_region
}

# Находим актуальный AMI для Ubuntu 22.04
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
}

# Группа безопасности: разрешаем SSH и HTTP
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow SSH and HTTP"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # в продакшене — ограничьте своим IP
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# EC2-инстанс
resource "aws_instance" "web_server" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = var.instance_type
  vpc_security_group_ids = [aws_security_group.web.id]
  key_name               = var.key_name

  tags = {
    Name        = "web-server"
    Environment = "demo"
    ManagedBy   = "terraform"
  }
}

Обратите внимание на строку vpc_security_group_ids = [aws_security_group.web.id]. Terraform понимает зависимости между ресурсами: он создаст группу безопасности раньше, чем инстанс, потому что инстанс ссылается на неё. Явно указывать порядок создания обычно не нужно.

variables.tf — параметризуем конфигурацию

variable "aws_region" {
  description = "AWS region to deploy resources"
  type        = string
  default     = "eu-west-1"
}

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

variable "key_name" {
  description = "Name of the SSH key pair in AWS"
  type        = string
}

outputs.tf — получаем полезные данные после деплоя

output "instance_public_ip" {
  description = "Public IP address of the web server"
  value       = aws_instance.web_server.public_ip
}

output "instance_id" {
  description = "EC2 instance ID"
  value       = aws_instance.web_server.id
}

После apply Terraform выведет публичный IP сервера — не нужно лезть в консоль AWS.

Запускаем

# Инициализируем: скачиваем провайдеры
terraform init

# Смотрим план
terraform plan -var="key_name=my-key"

# Применяем
terraform apply -var="key_name=my-key"

После подтверждения Terraform создаст группу безопасности и EC2-инстанс. Весь процесс займёт около минуты.

Типичные ошибки новичков

Хранение state локально в команде. Если два инженера работают с локальным terraform.tfstate, конфликты неизбежны. Переходите на remote state с первого же командного проекта.

Секреты в коде. Никогда не хардкодьте токены, пароли и ключи в .tf-файлах. Используйте переменные окружения, AWS Secrets Manager, HashiCorp Vault или как минимум terraform.tfvars в .gitignore.

Ручные изменения в облаке. Если вы изменили что-то через веб-консоль, Terraform об этом не знает. При следующем apply он может откатить изменение. Золотое правило: если инфраструктура управляется Terraform, все изменения — только через Terraform.

Игнорирование terraform plan. Команда apply без предварительного просмотра плана — это как деплоить код без code review. Особенно опасно при наличии destroy в плане.

Монолитная конфигурация. Класть всё в один main.tf работает для учебных проектов, но в реальных системах инфраструктуру разбивают на модули. Модули — это переиспользуемые блоки конфигурации, аналог функций в программировании.

Куда двигаться дальше

Terraform — это точка входа в более широкую экосистему. После того как вы освоили базовый цикл работы, логично двигаться в нескольких направлениях.

Модули. Terraform Registry содержит готовые модули для типовых задач: VPC, EKS-кластер, RDS. Изучите, как они устроены — это лучший способ понять паттерны написания хорошего Terraform-кода.

Remote state и блокировки. В командной работе state хранится в S3 с блокировкой через DynamoDB (для AWS) или в Terraform Cloud. Это предотвращает одновременные изменения от нескольких инженеров.

Ansible в связке с Terraform. Terraform поднимает инфраструктуру, Ansible настраивает её содержимое. Это классическая связка: IaC для provisioning, configuration management для настройки ПО. Курс «Знакомство с DevOps на примерах: Terraform, Ansible, Prometheus» рассматривает именно такой стек — от нуля до работающего мониторинга на реальных примерах, что даёт хорошее понимание того, как инструменты дополняют друг друга.

Тестирование инфраструктуры. Инструменты вроде Terratest позволяют писать автоматические тесты для Terraform-модулей — поднять инфраструктуру, проверить, что всё работает, и уничтожить. Это уже уровень зрелой инженерной культуры.

Atlantis или Terraform Cloud. Автоматизация Terraform в CI/CD: pull request в Git запускает plan, merge запускает apply. Инфраструктурные изменения проходят через тот же процесс, что и код приложений.

Заключение

Terraform изменил то, как инженеры думают об инфраструктуре. Не «зайди в консоль и нажми кнопку», а «опиши, что должно быть, и доверь машине это создать». Это не просто удобство — это принципиально иной уровень надёжности, воспроизводимости и контроля.

За 30 минут реально пройти путь от установки до работающего сервера в облаке. Но за этим простым стартом стоит глубокая экосистема: модули, remote state, тестирование, интеграция с CI/CD, связка с Ansible и системами мониторинга. Именно поэтому Terraform — не просто инструмент, а навык, который формирует DevOps-мышление.

Если хочется разобраться системно, а не по кускам из документации, стоит посмотреть на структурированные практические курсы. Тот же «Знакомство с DevOps на примерах: Terraform, Ansible, Prometheus» даёт возможность пройти весь путь в связке реальных инструментов — что ближе к тому, с чем сталкиваешься в работе, чем изолированное изучение каждого инструмента по отдельности.

Главное — начать. Первый terraform apply всегда немного магический.