Что делает
Создаёт и обновляет облачную инфраструктуру (EC2, RDS, VPC, DNS) по декларативному описанию в HCL-файлах: terraform plan показывает план изменений, terraform apply применяет их.
Live-данные · обновлено 19 июля 2026 г.
Terraform
Terraform — инструмент Infrastructure as Code для декларативного описания облачной инфраструктуры. Стандарт DevOps-инженера для управления AWS, GCP и Azure: в вакансиях чаще всего рядом с Kubernetes и Ansible.
КВКузнецов Вячеслав·Технический редактор·DevOps/SRE-техлид · опыт 10+ лет
Вакансий
235
активных в Москве
Медиана зарплаты
287 тыс. ₽
n = 47 вакансий с указанной зарплатой
Индекс спроса
78/100
#72 из 332 навыков
Доля IT-рынка
3.4%
20 профессий
Коротко о навыке
Terraform — инструмент Infrastructure as Code (IaC) от HashiCorp, позволяющий описывать инфраструктуру (серверы, сети, базы данных, DNS) декларативно в файлах HCL (HashiCorp Configuration Language). Вместо ручного создания ресурсов через консоль или shell-скрипты инженер описывает желаемое конечное состояние, Terraform вычисляет разницу с текущим и применяет только необходимые изменения.
Ключевая концепция — tfstate-файл, база данных реального состояния инфраструктуры. В команде tfstate хранится в remote backend (S3, GCS, Terraform Cloud), что предотвращает конфликты. На рынке труда Terraform — почти исключительно DevOps-навык: подавляющее большинство вакансий с ним приходится на роли DevOps-инженера и SRE.
Что такое Terraform
Кто использует
DevOps-инженеры, SRE и Platform Engineer: Terraform применяется для управления инфраструктурой AWS, GCP и Azure, настройки Kubernetes-кластеров и сетевых конфигураций.
Позиция на рынке
Ядро DevOps-стека. Доминирующая роль — DevOps-инженер; в парах чаще всего Kubernetes, Ansible и облачные платформы.
Что такое Terraform
Terraform — инструмент декларативного управления инфраструктурой от HashiCorp с открытым исходным кодом. Конфигурация пишется на HCL: разработчик описывает ресурсы (aws_instance, google_sql_database, kubernetes_deployment), Terraform при выполнении terraform apply создаёт их через API провайдера. Ключевое отличие от Ansible и shell-скриптов — идемпотентность: повторный apply с той же конфигурацией не создаёт дубликаты, а сверяет текущее состояние с желаемым.
tfstate — база данных инфраструктуры
После каждого apply Terraform сохраняет актуальное состояние всех ресурсов в terraform.tfstate — JSON-файл с ID, атрибутами и зависимостями каждого ресурса. При следующем apply Terraform сравнивает конфигурацию с tfstate и API провайдера, вычисляя минимальный план изменений. Локальный tfstate в команде — критический риск: два инженера одновременно могут перезаписать состояние и потерять синхронизацию с реальной инфраструктурой.
Remote Backend
Remote backend хранит tfstate централизованно: S3 с блокировкой через DynamoDB (AWS), GCS (GCP), Terraform Cloud. State locking (блокировка) гарантирует, что только один оператор в момент времени может менять инфраструктуру — предотвращает конфликты при параллельной работе. Remote backend — обязательный элемент Terraform в командной работе.
Понятия / Карта
Из чего состоит Terraform
Понятие Что это Что нужно уметь
HCL
Язык, на котором описывают, какая инфраструктура должна существовать.
Писать resource/variable/output-блоки, использовать функции, for_each и динамические блоки.
Provider
Плагин-переводчик между Terraform и конкретным облаком или сервисом.
Фиксировать версии через required_providers, настраивать алиасы для нескольких регионов.
tfstate
Файл-реестр: что Terraform уже создал и в каком оно состоянии.
Понимать план через сравнение state/конфига/реальности, уметь terraform state mv и import.
Remote backend
Хранение этого реестра в облаке, чтобы команда работала с одной версией.
Настраивать S3+DynamoDB с блокировками, разносить state по окружениям через key-пути.
Module
Готовый переиспользуемый блок инфраструктуры с настраиваемыми параметрами.
Проектировать интерфейс модуля (variables/outputs), подключать модули из registry с фиксацией версий.
Data source
Чтение уже существующего ресурса — например, «найди свежий образ Ubuntu».
Использовать data-блоки вместо хардкода ID, строить зависимости между слоями инфраструктуры.
Механика / Работа
Как Terraform управляет инфраструктурой
От конфига до реального ресурса в облаке — стандартный рабочий процесс.
Шаг Слой Смысл
Шаг 01
Написать конфигурацию HCL
Описать ресурсы в .tf-файлах: провайдер, переменные, resource-блоки. terraform fmt форматирует, terraform validate проверяет синтаксис.
Шаг 02
terraform plan
Terraform читает tfstate, опрашивает API провайдера и вычисляет минимальный план изменений: + создать, ~ изменить, - удалить. Это можно ревьюить в PR.
Шаг 03
terraform apply
После подтверждения Terraform вызывает API провайдера, создаёт/изменяет ресурсы в нужном порядке и обновляет tfstate с актуальными атрибутами.
Карьера / Роли
Кому нужен Terraform
Terraform переносится между ролями: DevOps-инженер, SRE-инженер, Системный администратор. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Роли с Terraform за период
DevOps-инженер — самый заметный профиль в распределении ролей по навыку.
Роль Упоминаний за период Медиана
Ещё 7 ролей используют Terraform
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
Практика / Задачи
Частые задачи с Terraform
Terraform ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
# Задача Что делает специалист
Задача 01
Первый ресурс AWS
Создать EC2-инстанс с провайдером AWS — базовая структура Terraform-проекта.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = var.region
}
resource "aws_instance" "web" {
ami = data.aws_ami.ubuntu.id
instance_type = var.instance_type
tags = {
Name = "web-server"
Environment = var.environment
}
}
Задача 02
Переменные и валидация
Описать входные параметры модуля с типами, значениями по умолчанию и валидацией.
# variables.tf
variable "instance_type" {
type = string
default = "t3.micro"
description = "Тип EC2-инстанса"
}
variable "environment" {
type = string
validation {
condition = contains(
["dev", "staging", "prod"],
var.environment
)
error_message = "Только dev, staging или prod."
}
}
Задача 03
Output values
Экспортировать ID и IP созданных ресурсов для использования в других модулях или CI/CD.
# outputs.tf
output "instance_id" {
description = "ID EC2-инстанса"
value = aws_instance.web.id
}
output "public_ip" {
description = "Публичный IP веб-сервера"
value = aws_instance.web.public_ip
sensitive = false
}
output "private_ip" {
description = "Приватный IP (для внутренней сети)"
value = aws_instance.web.private_ip
}
Задача 04
Вызов модуля из реестра
Использовать готовый VPC-модуль из Terraform Registry вместо описания всех ресурсов вручную.
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.1.0"
name = "main-vpc"
cidr = "10.0.0.0/16"
azs = ["eu-central-1a", "eu-central-1b"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
public_subnets = ["10.0.101.0/24", "10.0.102.0/24"]
enable_nat_gateway = true
}
output "vpc_id" {
value = module.vpc.vpc_id
}
Задача 05
Remote backend на S3
Настроить хранение tfstate в S3 с блокировкой через DynamoDB для командной работы.
terraform {
backend "s3" {
bucket = "my-tfstate-bucket"
key = "prod/main/terraform.tfstate"
region = "eu-central-1"
dynamodb_table = "terraform-state-locks"
encrypt = true
}
}
Задача 06
Data source для AMI
Найти последний Ubuntu-образ через data source вместо хардкода AMI-ID, который устаревает.
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477"] # Canonical
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-22.04-amd64-*"]
}
filter {
name = "virtualization-type"
values = ["hvm"]
}
}
resource "aws_instance" "web" {
ami = data.aws_ami.ubuntu.id
instance_type = var.instance_type
}Практика / Ошибки
Ошибки новичков
Ошибка 01
Хранить tfstate локально в команде
Коммитить terraform.tfstate в git или оставлять его локальным при командной работе. Два инженера с разными локальными state создадут дублирующиеся ресурсы или потеряют синхронизацию. Обязателен remote backend с блокировкой.
Ошибка 02
Хардкодить secrets в .tf-файлах
Писать пароли БД, API-ключи и токены прямо в переменных или resource-атрибутах. Secrets должны поступать из переменных среды (TF_VAR_db_password), HashiCorp Vault или AWS Secrets Manager — никогда из .tf или .tfvars, попадающих в git.
Ошибка 03
Не использовать terraform plan перед apply
Выполнять terraform apply без предварительного review плана. Plan может показать неожиданные удаления ресурсов из-за изменения имени или типа. В production — всегда plan + ревью, затем apply.
Ошибка 04
Копировать ресурсы вместо модулей
Дублировать одинаковые блоки ресурсов для dev и prod вместо создания модуля с переменными. При изменении архитектуры придётся менять копии в нескольких местах — источник расхождений конфигураций окружений.
Ошибка 05
Не добавлять зависимости явно
Не указывать depends_on когда Terraform не может автоматически определить зависимость между ресурсами (например, resource и data source в разных модулях). Результат — apply в неправильном порядке и ошибки создания.
Рынок / Контекст
Terraform в современных IT-проектах: контекст спроса
DevOps-инженер — доминирующая роль в вакансиях с Terraform, следом SRE. Это второй по частоте IaC-инструмент после Ansible на российском рынке, но растёт он быстрее: облачная миграция компаний создаёт спрос на декларативное управление AWS и GCP. В парах чаще всего Kubernetes, Ansible и GitLab CI.
Сокращает ручную работу
Terraform востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.
Встроен в рабочий процесс
Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.
Закреплён в зрелом стеке
Terraform чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.
Сигнал рынка
Стабильный спрос
Terraform формирует устойчивый спрос внутри своего рабочего сегмента.
Рынок / Спрос
Спрос на Terraform на рынке
Terraform сохраняет устойчивый прикладной спрос на рынке: 235 активных вакансий, #72 по рынку, 3.4% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
Сила спроса
Стабильный спрос 235
активных вакансий сейчас
#72 по рынку • 3.4% IT-вакансий
Месяц к месяцу
295
июль 2026 — предварительный накопительный срез
-32 вакансий и -10% к предыдущему месяцу.
Доход / Уровни
Зарплаты в вакансиях, где требуется Terraform
Terraform спрашивают с DevOps-инженеров и SRE — ролей с одними из самых высоких медиан на рынке. Отдельно инструмент не тарифицируется, но облачная специализация ценится выше классического конфигурационного управления; доход растёт с...
Медиана рынка
Ограниченная точность 287 000
₽ / месяц
47 вакансий с зарплатой в расширенной зарплатной выборке
Коридор по грейдам
—
уровни с выборкой
Коридор появится, когда по грейдам наберётся достаточная выборка.
Основной уровень
Senior
по структуре рынка
Senior - основной уровень рынка (59%)
Связи / Навыки
Навыки в связке с Terraform
Terraform редко живёт изолированно: чаще всего рынок видит его рядом с Kubernetes, Ansible, CI/CD. Самая плотная связка сейчас - Kubernetes: оба навыка встречаются вместе в 87% вакансий.
Главная связка: Kubernetes • 87% вакансий. Показываем общерыночные связки Terraform: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
Рабочий стек вокруг Terraform
навыки, которые рынок чаще всего видит рядом в одной вакансии
Навык Зачем рядом Доля
Связки, которые усиливают доход
не базовый минимум, а более сильные комбинации стека
1
CI/CD
n = 39
+4% 299 000 ₽
Вход / Старт
Порог входа
Сейчас на рынке 7 активных junior-вакансий с Terraform. Это 3.8% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
Junior-вакансии сейчас
7
активных вакансий
3.8% всех вакансий по навыку • Senior / Junior 15.6x
Доля junior
3.8%
% всех вакансий по навыку
Окно входа узкое: рынок чаще нанимает с опытом.
Что нужно на старте
Стартовый стек
20
навыков в медианной вакансии
Медианная вакансия с Terraform ожидает около 20 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
Карьера / Резюме
Terraform в резюме: что значит "знаю Terraform"
В резюме нужно не просто указать «Terraform», а показать уровень: умеете ли вы писать модули, настраивать удалённый бэкенд, работать с state и CI/CD.
Уровень Что значит Что показать
Beginner
Могу написать main.tf с одним ресурсом, выполнить plan/apply/destroy
Написал конфигурацию для создания S3-бакета в AWS
Junior developer
Работаю с провайдерами, переменными, outputs, state локально
Создал и уничтожил тестовый VPC с подсетями через переменные
Middle developer
Использую модули, remote backend с блокировкой, несколько workspaces
Разработал модуль VPC, опубликовал в внутреннем реестре, настроил state в S3 + DynamoDB
QA automation
Поднимаю и уничтожаю тестовые окружения, проверяю plan в CI
Интегрировал terraform plan в GitLab CI, автоматически развёртываю стенды для тестов
Data/ML
Управляю облачными хранилищами данных (S3, Redshift, BigQuery)
Автоматизировал provisioning S3 бакетов для ML-пайплайнов
DevOps junior
Создаю инфраструктуру микросервисов через модули, state в удалённом бэкенде
Развернул кластер Kubernetes + балансировщик через Terraform модули
SRE/platform
Проектирую IaC-стратегию, работаю с мультиоблачностью, политиками
Создал единый фреймворк Terraform модулей для трёх облаков, внедрил plan-ревью в CI/CD
Сравнение / Инструменты
Terraform в DevOps-стеке
Стандартные пары Terraform в production-инфраструктуре.
Инструмент За что отвечает Когда нужен Граница
Kubernetes
Terraform создаёт managed-кластеры EKS/GKE и базовые дополнения
При развёртывании кластера как части инфраструктуры
Деплой приложений в кластер — задача GitOps-инструментов, не Terraform.
Ansible
Конфигурация ОС и приложений на созданных Terraform серверах
Когда после создания ВМ нужно установить и настроить ПО
Не отслеживает состояние ресурсов — идемпотентность на уровне задач, не инфраструктуры.
AWS / GCP / Yandex Cloud
Облачные платформы — основные провайдеры Terraform
Любая облачная инфраструктура под управлением кода
Специфичные новинки облака попадают в провайдер с задержкой.
GitLab CI / Atlantis
Автоматический plan в merge request и apply после апрува
Когда изменения инфраструктуры должны проходить ревью
Нужно продумать хранение облачных креденшалов в CI.
Helm
Установка Kubernetes-приложений через helm_release
Для базовых кластерных сервисов (ingress, cert-manager)
Прикладные релизы через Terraform быстро становятся неудобными — лучше ArgoCD.
Навык / Применение
Где используется Terraform
Terraform применяется везде, где инфраструктура создаётся программно: облачные серверы, Kubernetes-кластеры, сетевые конфигурации и управляемые сервисы.
Сценарий 01
Облачная инфраструктура
Облачная инфраструктура AWS: VPC, подсети, security groups, EC2-инстансы, RDS и S3-бакеты описываются в .tf-файлах; terraform apply создаёт всё окружение за минуты,...
Сценарий 02
Kubernetes-кластер
Kubernetes-кластер EKS/GKE: Terraform создаёт managed Kubernetes через terraform-aws-modules/eks и устанавливает дополнения (ingress-controller, cert-manager) через...
Сценарий 04
Управление средами
Управление средами: modules/ описывает общие ресурсы, environments/dev и environments/prod вызывают одни и те же модули с разными переменными — гарантированная...
По направлениям
Terraform заметен в 2 направлениях рынка с долей выше 5%.
Направление Контекст Доля
Инфраструктура
Часть спроса по навыку сосредоточена в этом направлении.
78.9%
Безопасность
Часть спроса по навыку сосредоточена в этом направлении.
5.1%
Данные и ML
Часть спроса по навыку сосредоточена в этом направлении.
5%
Разработка
Часть спроса по навыку сосредоточена в этом направлении.
5%
Направления показывают, в каких частях IT-рынка навык заметен чаще всего, без разбивки по ролям.
Инструмент / Возможности
Что умеет Terraform
Ключевые возможности инструмента для декларативного управления инфраструктурой.
Декларативный IaC
Описываешь желаемое конечное состояние, Terraform вычисляет разницу с текущим и применяет только необходимые изменения — без ручного управления порядком создания ресурсов.
3000+ провайдеров
AWS, GCP, Azure, Kubernetes, GitHub, Datadog, Cloudflare и тысячи других сервисов управляются из одного инструмента через единый HCL-синтаксис.
Plan как code review
terraform plan показывает точный список изменений до применения — инфраструктурные изменения можно ревьюить в Pull Request так же, как изменения кода.
Модульная архитектура
Модули из Terraform Registry (VPC, EKS, RDS) избавляют от написания сотен строк конфигурации с нуля — переиспользуемые, протестированные блоки IaC.
Сравнение / Контекст
Terraform vs Ansible vs Pulumi
Три популярных IaC-инструмента — у каждого своя роль в DevOps-стеке.
Terraform vs Ansible
Это не конкуренты, а связка: Terraform создаёт и удаляет облачные ресурсы (серверы, сети, базы), Ansible настраивает то, что уже создано — пакеты, конфиги, сервисы. Типичный production-процесс:...
Terraform vs Pulumi
Pulumi описывает инфраструктуру на Python, TypeScript или Go — с циклами, функциями и тестами обычного языка. Terraform с его декларативным HCL проще для инженеров эксплуатации и имеет больше готовых...
Terraform vs CloudFormation
CloudFormation — родной IaC AWS: глубокая интеграция, но только одно облако и многословный YAML/JSON. Terraform работает с тысячами провайдеров единым языком. Для AWS-only команд оба варианта...
Практика / Workflow
Как Terraform используется в реальном проекте
Этап Что происходит Артефакт
1 terraform init
HashiCorp CLI
Провайдеры загружены, backend инициализирован
2 terraform validate
HCL parser
Синтаксис конфигурации корректен
3 terraform plan
Diff engine
Список ресурсов к созданию/изменению/удалению
4 Code review
Git PR / Atlantis
Изменения одобрены командой
5 terraform apply
Provider API
Инфраструктура создана, tfstate обновлён
6 terraform destroy
Provider API
Ресурсы удалены (для временных окружений)
Инструмент / Оркестрация
Terraform: workspace, state и модули
Работа с Terraform включает: workspace для изоляции окружений, state — сердце инструмента, и модули для переиспользования. Ниже — ключевые элементы типового проекта.
Workspace
Механизм изоляции окружений (dev/предрелизное/prod) внутри одной конфигурации. Команды `terraform workspace new` и `select` переключают контекст.
State‑файл
Файл `terraform.tfstate` содержит атрибуты всех созданных ресурсов. Хранить удалённо: S3 с нативной блокировкой (use_lockfile = true, Terraform 1.11+) или Terraform Cloud — для командной работы.
Модули
Переиспользуемые блоки ресурсов. Например, модуль VPC скрывает десятки ресурсов за простым интерфейсом cidr_block и subnet_count.
Переменные и Output
Переменные делают конфигурацию гибкой (регион, размер). Output выводит IP, URL и другие значения после apply.
Backend
Место хранения state: локально, S3, Terraform Cloud, GitLab. Выбор backend влияет на безопасность и коллаборацию.
Рекомендации для production
Используйте remote backend с блокировкой, не храните state в Git, внедряйте plan-ревью через Pull Request.
Практика / Terraform
Terraform: лучшие практики и типичные ошибки новичков
Практика 01
Используйте модули
Разбивайте инфраструктуру на переиспользуемые модули: VPC, Network, Compute. Реестр модулей Terraform Registry — готовые решения для типовых сценариев.
Практика 02
State на удалённом бэкенде
Никогда не храните `terraform.tfstate` в Git. Используйте S3 с нативной блокировкой (use_lockfile = true, Terraform 1.11+) или Terraform Cloud — DynamoDB для этого больше не обязателен.
Практика 03
Plan перед Apply
Всегда запускайте `terraform plan` перед `apply`. Для CI/CD — генерируйте план как артефакт и утверждайте его через PR.
Практика 04
Версионируйте провайдеров
Фиксируйте версии провайдеров в `required_providers` для воспроизводимости. Обновляйте их осознанно.
Практика 05
Не злоупотребляйте count и for_each
Массовое создание ресурсов через `count` и `for_each` усложняет state и логику изменений. Используйте модули для группировки.
Практика 06
Format и lint код
Применяйте `terraform fmt -recursive` для единого стиля и `terraform validate` для проверки синтаксиса.
Практика 07
Разделяйте окружения
Используйте отдельные корневые конфигурации или workspaces для dev, предрелизного и prod. Не смешивайте state-файлы.
Практика 08
Документируйте модули
Пишите описание переменных, outputs и примеры использования в README модуля. Это упрощает командную работу и онбординг.
Практика 09
Используйте terraform_remote_state
Для обмена данными между конфигурациями применяйте data-источник `terraform_remote_state` — это безопаснее, чем жёстко закодированные ID.
Практика / Безопасность
Безопасность Terraform: что нельзя делать
Риск 01
Секреты в конфигурации
Не храните пароли, токены и ключи в файлах .tf и переменных. Используйте Vault, AWS Secrets Manager или переменные CI/CD.
Риск 02
Закоммиченный state
Файл `terraform.tfstate` содержит все атрибуты ресурсов, включая пароли. Никогда не добавляйте его в Git.
Риск 03
Жёстко закодированная аутентификация
Не указывайте access_key/secret_key в коде. Используйте AWS IAM roles, профили или OIDC для CI/CD.
Риск 04
Пренебрежение блокировками
Работа без блокировки state при командном apply приводит к конфликтам и повреждению файла. Всегда настраивайте блокировку: нативный S3-lock (use_lockfile, Terraform 1.11+) или Terraform Cloud.
Риск 05
Дрейф конфигураций без проверки
Инфраструктура может быть изменена вручную через консоль. Регулярно запускайте `terraform plan` или используйте дрифт-детекторы.
Риск 06
Слабые политики доступа к провайдеру
IAM-роль для Terraform должна иметь минимальные разрешения (least privilege). Не используйте admin-роль.
Риск 07
Использование `latest` версии провайдера
Фиксируйте версию провайдера в `required_providers`. `latest` может содержать несовместимые изменения.
Риск 08
Небезопасный локальный backend
Локальный state-файл хранится с открытыми данными. Для production используйте удалённый бэкенд с шифрованием.
Риск 09
Отсутствие аудита изменений
Вносите изменения через Pull Request с `terraform plan` в CI/CD. Никто не должен выполнять `apply` напрямую.
Будущее / Роль
Перспективы Terraform
Перспективы Terraform завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Сигнал 01
OpenTofu как с открытым кодом альтернатива
После смены лицензии Terraform на BSL в 2023 году сообщество создало OpenTofu — полностью совместимый форк под лицензией MPL. OpenTofu входит в Linux Foundation; некоторые...
Сигнал 02
Terraform CDK
CDK for Terraform (CDKTF) позволяет писать конфигурацию на TypeScript, Python или Go вместо HCL, генерируя стандартный Terraform JSON. Объединяет типобезопасность языков...
Сигнал 03
Drift Detection и непрерывная сверка
Terraform Cloud и Atlantis добавляют автоматическое обнаружение drift: если кто-то изменил ресурс через консоль, CI создаёт алерт и план исправления. Это закрывает главный...
Практика / Портфолио
Портфолио с Terraform: с чего начать
Проект 01
AWS-инфраструктура с модулями
Terraform-проект для двух окружений (dev/prod): VPC через terraform-aws-modules/vpc, EC2 с ALB, RDS PostgreSQL, remote backend на S3+DynamoDB, GitLab CI с plan в MR и apply при merge.
Проект 02
Kubernetes-кластер EKS
Создание EKS-кластера через terraform-aws-modules/eks: node groups, IRSA для pod identity, установка ingress-controller и cert-manager через helm_release. Все настройки в переменных.
Обучение / Маршрут
Как изучить Terraform
Terraform осваивается поэтапно: базовый синтаксис за несколько дней, remote state и модули — за неделю, production-паттерны (Terragrunt, модульная архитектура) — за месяц практики.
Этап Фокус Что изучать
Этап 01
HCL-синтаксис и первый ресурс
Освоить блоки resource, variable, output, data. Начать с провайдера null или random — без реального облака и без затрат: terraform init → plan → apply →...
Этап 02
AWS-ресурсы и первая инфраструктура
Создать EC2-инстанс, VPC и security group в AWS Free Tier. Понять зависимости между ресурсами через ссылки (aws_instance.web.id) и depends_on.
Этап 03
Remote backend и командная работа
Настроить S3-backend с DynamoDB-блокировкой. Это обязательный шаг перед работой в команде — без remote backend tfstate будет конфликтовать при...
Этап 04
Переменные и outputs
Вынести настраиваемые параметры в variables.tf, добавить outputs.tf для экспорта ID ресурсов. Использовать terraform.tfvars для env-специфичных значений.
Курсы · по данным рынка
Где учить Terraform
Соответствие — доля тем навыка, которые охватывает программа курса
Практика / Первый запуск
Как начать изучать Terraform
Трёхшаговый путь от нуля до production IaC.
Шаг 01
Установить и пройти туториал без облака
Установить Terraform CLI, пройти официальный Get Started на developer.hashicorp.com/terraform/tutorials — использовать провайдер docker или null без облачного аккаунта.
Шаг 02
Создать реальные ресурсы в AWS Free Tier
Зарегистрировать AWS-аккаунт, создать EC2 + VPC через Terraform, настроить S3-backend. Это первый production-паттерн, который используется в реальных проектах.
Шаг 03
Старт / Документация
Официальные ресурсы и быстрый старт
Для инструментов вроде Terraform на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.
Официальный сайт
Terraform
Официальный портал Terraform от HashiCorp.
Документация
Tutorials
Официальные туториалы: от установки до модулей и remote state.
Документация
Language
Справочник по HCL: ресурсы, переменные, модули, функции.
Документация
Terraform Registry
Каталог провайдеров и готовых модулей.
Документация
Backends
Официальный раздел про remote backend и блокировки state.
Частые вопросы
Вопросы и ответы
Что такое tfstate и почему его нельзя удалять?
Tfstate — JSON-файл с актуальным состоянием всех ресурсов, управляемых Terraform: ID, атрибуты, зависимости. Без tfstate Terraform не знает, что уже создано, и при следующем apply попытается создать ресурсы заново — дублирование или ошибки. Удаление state без импорта ресурсов обратно лишает Terraform возможности управлять ими.
Зачем нужен remote backend?
Локальный tfstate — критический риск в команде: два инженера с разными копиями state создадут конфликты. Remote backend (S3 + DynamoDB) хранит единственную копию state в облаке и блокирует параллельный apply — только один оператор может менять инфраструктуру в момент времени.
Terraform vs Ansible — в чём разница?
Terraform управляет инфраструктурой (создаёт/удаляет облачные ресурсы: серверы, сети, базы данных). Ansible конфигурирует ОС и приложения на уже существующих серверах. В production они работают вместе: Terraform создал сервер → Ansible установил nginx и приложение.
Как начать без реального облака?
Использовать провайдер null или random для практики синтаксиса без создания реальных ресурсов. Для AWS — Free Tier с t3.micro инстансами (бесплатно 12 месяцев). Для локальной практики — Terraform с LocalStack (mock AWS API).
Что такое Terraform модуль?
Модуль — директория с .tf-файлами, описывающая переиспользуемый набор ресурсов. Принимает input variables, возвращает outputs. Позволяет создавать одинаковую инфраструктуру для dev и prod с разными переменными из одного кода. Публичные модули доступны на registry.terraform.io.
Как безопасно хранить пароли в Terraform?
Никогда не хардкодить в .tf-файлах и не коммитить в git. Использовать переменные среды (TF_VAR_db_password), AWS Secrets Manager через data source, HashiCorp Vault provider или sensitive = true в variable-блоке чтобы Terraform скрывал значение в выводе.
Что такое Terragrunt?
Terragrunt — обёртка над Terraform для управления многоокружным проектом: устраняет дублирование backend-конфигурации, автоматизирует зависимости между модулями и упрощает работу с иерархией environments/region/module. Используется в enterprise при 5+ окружениях.