До этого момента мы изучали Terraform локально. Теперь пришло время применить эти знания в реальной среде.

В этой статье мы подключим Terraform к облачному провайдеру, создадим первую инфраструктуру, разберём процесс создания сети и виртуальной машины, а также сравним особенности работы с AWS, Microsoft Azure, Google Cloud Platform (GCP) и Yandex Cloud. Несмотря на различия между облачными платформами, вы увидите, что принцип работы Terraform остаётся практически одинаковым.

Почему Terraform особенно полезен в облаке?

Облачные платформы позволяют создавать инфраструктуру за считанные минуты. Однако по мере роста проекта количество ресурсов быстро увеличивается:

виртуальные машины;
виртуальные сети;
подсети;
балансировщики нагрузки;
базы данных;
Kubernetes-кластеры;
DNS-записи;
правила межсетевого экрана.

Создавать всё это вручную через веб-интерфейс неудобно и небезопасно. Terraform позволяет описать инфраструктуру один раз и затем воспроизводить её в любом окружении одной командой.

Как Terraform взаимодействует с облаком?

Независимо от выбранного провайдера процесс выглядит одинаково.

Terraform Configuration
    ▼
terraform plan
    ▼
terraform apply
    ▼
Provider
    ▼
Cloud API
    ▼
Созданная инфраструктура

Terraform не обращается к облаку напрямую. Он использует Provider, который взаимодействует с API конкретной платформы.

Подготовка

Перед началом работы потребуется:

аккаунт облачного провайдера;
установленный Terraform;
ключи доступа (API Keys или Service Account);
базовое понимание структуры выбранного облака.

Независимо от платформы рекомендуется сначала изучить бесплатные тарифы (Free Tier или аналогичные программы), чтобы избежать неожиданных расходов.

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

Минимальная структура проекта практически не отличается от предыдущих примеров:

terraform-cloud/
main.tf
variables.tf
outputs.tf
terraform.tfvars

Подключение Provider

Первый шаг — подключить провайдер выбранного облака. Пример общей структуры:

terraform {
  required_providers {
    cloud = {
      source = "provider/name"
    }  
  }
}
provider "cloud" {}

Каждый облачный провайдер использует собственный Provider, но принцип подключения остаётся одинаковым.

Создание первой виртуальной машины

Практически любой облачный проект начинается с виртуальной машины. В Terraform такой ресурс описывается декларативно: вы указываете необходимые параметры (образ операционной системы, тип машины, регион и сеть), а Terraform создаёт экземпляр через API облачного провайдера. Типичный жизненный цикл выглядит так:

HCL
  ▼
Virtual Machine
  ▼
Public IP
  ▼
SSH

После выполнения terraform apply машина будет создана автоматически, а её параметры можно получить через Outputs.

Создание сети

Перед запуском виртуальных машин создаётся сеть. В зависимости от платформы она может называться:

Облако	Название
AWS	VPC (Virtual Private Cloud)
Microsoft Azure	Virtual Network (VNet)
Google Cloud Platform	VPC Network
Yandex Cloud	Virtual Private Cloud (VPC)

Несмотря на разные названия, назначение одинаковое — объединить ресурсы в изолированную сеть и определить правила их взаимодействия.

Настройка правил доступа

После создания сети необходимо определить, какой трафик разрешён. Во всех облаках используются похожие механизмы:

разрешить SSH (22);
разрешить HTTP (80);
разрешить HTTPS (443);
запретить остальные подключения.

Названия различаются:

AWS	Security Group
Azure	Network Security Group
GCP	Firewall Rules
Yandex Cloud	Security Groups

Идея остаётся неизменной: открыть только те порты, которые действительно необходимы.

Сравнение популярных облачных платформ: плюсы и минусы

Все современные облачные платформы позволяют решать практически одинаковые задачи: создавать виртуальные машины, сети, базы данных, Kubernetes-кластеры и десятки других сервисов. Однако между ними есть различия. Ниже рассмотрим сильные и слабые стороны каждой платформы.

Облачная платформа

Плюсы

Минусы

AWS

• Самая популярная облачная платформа в мире.

• Огромное количество сервисов.

• Высокий спрос на специалистов на рынке труда.

• Отличная интеграция с Terraform, Kubernetes, Docker и другими DevOps-инструментами.

• Большое сообщество, множество курсов и документации.

• Высокий порог входа.

• Сложная структура сервисов и терминологии.

• Запутанная модель ценообразования.

Microsoft Azure

• Лучшая интеграция с Windows Server, Active Directory, Microsoft 365 и .NET.

• Популярна среди крупных корпоративных клиентов.

• Хорошая документация и курсы Microsoft Learn.

• Удобная работа с гибридной инфраструктурой (локальные серверы + облако).

• Некоторые сервисы сложнее в настройке по сравнению с AWS.

• Интерфейс и терминология могут быть непривычны начинающим.

• Меньше примеров и сообщества по сравнению с AWS.

Google Cloud Platform (GCP)

• Отличная поддержка Kubernetes (GKE считается одним из лучших управляемых Kubernetes-сервисов).

• Сильные решения для Big Data, аналитики и искусственного интеллекта.

• Простая и понятная консоль управления.

• Хорошая производительность глобальной сети Google.

• Меньше сервисов и вакансий по сравнению с AWS.

• Некоторые функции доступны только в отдельных регионах.

• Сообщество меньше, чем у AWS.

Yandex Cloud

• Простой интерфейс и понятная документация на русском языке.

• Хорошо подходит для проектов в России и странах СНГ.

• Поддерживает Terraform, Kubernetes, Managed PostgreSQL, Object Storage и другие современные сервисы.

• Значительно меньше сервисов по сравнению с AWS и Azure.

• Ограниченное количество регионов размещения.

• Низкая востребованность за пределами СНГ.

• Небольшое международное сообщество.

Какое облако выбрать начинающему DevOps?

Если ваша цель — работать в международной компании, в первую очередь стоит изучить AWS. Большинство вакансий DevOps-инженеров требуют хотя бы базового понимания его сервисов. Если вы планируете развиваться в корпоративной инфраструктуре Microsoft, работать с Windows Server, Active Directory или .NET, логичным выбором станет Microsoft Azure.

Тем, кто интересуется Kubernetes, анализом данных или машинным обучением, стоит обратить внимание на Google Cloud Platform. Многие современные проекты, связанные с контейнеризацией, используют именно GCP.

Если же вы ориентируетесь на рынок России и стран СНГ или хотите быстро познакомиться с облачными технологиями без сложного порога входа, хорошим вариантом станет Yandex Cloud.

Что выбрать для изучения?

Если говорить именно о карьере Junior DevOps, можно рекомендовать следующий порядок:

AWS — как наиболее востребованная платформа на мировом рынке.
Google Cloud Platform или Microsoft Azure — в зависимости от специализации компании.
Yandex Cloud — как дополнительное облако для работы с локальными проектами и понимания общих принципов.

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

Рабочий процесс DevOps-инженера

На практике создание инфраструктуры обычно выглядит следующим образом:

Изменение HCL
    ▼
terraform fmt
    ▼
terraform validate
    ▼
terraform plan
    ▼
Проверка изменений
    ▼
terraform apply
    ▼
Созданная инфраструктура

Такой порядок помогает обнаружить ошибки до того, как изменения попадут в рабочее окружение.

Подключение к облачному провайдеру

Сам по себе Terraform не умеет создавать виртуальные машины, сети или базы данных. Он не знает, как работать с AWS, Microsoft Azure, Google Cloud Platform или Yandex Cloud. Для этого используются Providers — специальные плагины, которые позволяют Terraform взаимодействовать с API конкретной облачной платформы.

Схема работы выглядит следующим образом:

Terraform
    ▼
terraform apply
    ▼
Provider
    ▼
REST API
    ▼
Cloud Platform
    ▼
Созданная инфраструктура

Когда вы выполняете команду:

terraform apply

Terraform не создаёт сервер самостоятельно. Последовательность действий выглядит так:

Terraform читает HCL-конфигурацию.
Определяет, какой Provider необходимо использовать.
Загружает Provider (если он ещё не установлен).
Через Provider отправляет запрос в API облачного провайдера.
Облачная платформа создаёт необходимые ресурсы.
Terraform сохраняет информацию о них в terraform.tfstate.

Именно поэтому один и тот же Terraform можно использовать практически с любым облаком.

Подключаем AWS

Для работы с AWS используется официальный провайдер hashicorp/aws. Подключение начинается с объявления провайдера:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}
provider "aws" {
  region = "eu-central-1"
}

После выполнения:

terraform init

Terraform автоматически скачает AWS Provider из Terraform Registry. Однако одного провайдера недостаточно. Terraform должен получить разрешение на управление вашим аккаунтом AWS. Обычно используются Access Key ID и Secret Access Key, которые можно передать через переменные окружения:

export AWS_ACCESS_KEY_ID="ВАШ_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="ВАШ_SECRET_KEY"

В AWS также можно использовать AWS CLI, IAM Roles (например, на EC2) и другие механизмы аутентификации. Передача ключей через переменные окружения — лишь один из распространённых способов. После этого Terraform сможет создавать ресурсы от имени вашей учётной записи.

Подключаем Microsoft Azure

Azure использует собственный Provider:

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
    }
  }
}
provider "azurerm" {
  features {}
}

Наиболее распространенный способ через Azure CLI. Достаточно выполнить:

az login

После входа Terraform автоматически использует полученные учётные данные.

Подключаем Google Cloud Platform

Для GCP используется Provider:

terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
    }
  }
}
provider "google" {
  project = "my-project"
  region  = "europe-west1"
}

Для доступа обычно создают Service Account, можно скачать JSON-ключ и указать путь к нему:

export GOOGLE_APPLICATION_CREDENTIALS=~/gcp-key.json

Terraform автоматически использует этот файл при обращении к Google Cloud API.

Подключаем Yandex Cloud

Для Yandex Cloud используется официальный Provider:

terraform {
  required_providers {
    yandex = {
      source = "yandex-cloud/yandex"
    }
  }
}
provider "yandex" {
  cloud_id  = var.cloud_id
  folder_id = var.folder_id
  zone      = "ru-central1-a"
}

Для авторизации можно использовать OAuth-токен или сервисную учётную запись (Service Account). В рабочих проектах предпочтительно использовать сервисные аккаунты с минимально необходимыми правами.

Все облака работают одинаково

Несмотря на различия в названиях провайдеров и способах аутентификации, общий принцип работы остаётся неизменным:

HCL
  ▼
terraform init
  ▼
Provider
  ▼
Cloud API
  ▼
Virtual Machine, Network, Database, Load Balancer, Kubernetes

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

Практический пример: создаём виртуальную машину в AWS

Ниже приведён упрощённый пример конфигурации, создающей экземпляр Amazon EC2.

provider "aws" {
  region = "eu-central-1"
}
resource "aws_instance"
  "web" {
    ami = "ami-xxxxxxxx"
    instance_type = "t3.micro"  
    tags = {
      Name = "terraform-demo"
  }
}

Далее выполняется стандартный цикл работы:

terraform init
terraform plan
terraform apply

После подтверждения Terraform:

подключится к AWS;
создаст виртуальную машину;
сохранит её идентификатор в terraform.tfstate;
покажет результат выполнения.

Именно по такому сценарию создаётся большинство облачной инфраструктуры: сначала описывается желаемое состояние в HCL, затем Terraform через Provider обращается к API облачного провайдера и приводит инфраструктуру к этому состоянию.

Workspaces, Terraform Cloud. Кратко.

Далее мы познакомимся с инструментами, которые используются практически в каждой команде: Workspaces, Terraform Cloud.

Что такое Backend?

Для хранения Remote State Terraform использует Backend. Для тех, кто забыл "Remote State — это файл состояния, который хранится не на компьютере разработчика, а в общем удалённом хранилище."

Backend определяет:

где хранится State;
как он читается;
кто имеет к нему доступ;
как предотвращаются конфликты.

Простейший пример Backend для AWS S3:

terraform {
  backend "s3" {
    bucket = "company-terraform-state"
    key = "production/terraform.tfstate"
    region = "eu-central-1" 
  }
}

После выполнения:

terraform init

Terraform перенесёт локальный State в удалённое хранилище.

Блокировка State (State Locking)

Представим, что два инженера одновременно выполнили:

Без механизма блокировки оба процесса попытаются изменить инфраструктуру одновременно. Это может привести к повреждению состояния. Поэтому большинство Backend поддерживают State Locking.

DevOps A
│
terraform apply
│
Lock State
│
──────────────
DevOps B
│
terraform apply
│
Waiting...

Пока один инженер выполняет изменения, остальные ожидают освобождения блокировки.

Что такое Workspaces?

Практически у любого проекта существует несколько окружений. Например:

Development
Testing
Staging
Production

Можно создать четыре отдельных проекта Terraform. Но гораздо удобнее использовать Workspaces. Workspace позволяет применять одну и ту же конфигурацию к разным окружениям. Создание Workspace:

terraform workspace new dev

Переключение:

terraform workspace select production

Просмотр списка:

terraform workspace list

Каждый Workspace использует собственный State, благодаря чему окружения полностью изолированы друг от друга.

Когда использовать Workspaces?

Они хорошо подходят, если:

структура инфраструктуры одинакова;
отличаются только параметры;
используется один Terraform-проект.

Например:

Workspace	Регион	Размер ВМ
dev	eu-central-1	small
stage	eu-central-1	medium
prod	eu-central-1	large

Один код — несколько окружений. Однако для полностью независимых инфраструктур (например, разные команды или разные облака) часто удобнее использовать отдельные проекты.

Terraform Cloud

Одним из самых популярных решений для командной работы является Terraform Cloud. Он предоставляет:

Remote State;
блокировку состояния;
историю изменений;
управление версиями;
выполнение terraform plan;
выполнение terraform apply;
управление переменными;
контроль доступа.

Получается следующая схема.

Git Repository
▼
Terraform Cloud
│
terraform plan
│
terraform apply
▼
Cloud Provider

Инженерам больше не нужно хранить State локально.

Управление переменными

В предыдущих статьях переменные находились в файле:

terraform.tfvars

В реальных компаниях секреты обычно не хранятся в Git. Например:

API Keys;
Access Keys;
пароли;
токены.

Terraform Cloud позволяет хранить их как защищённые переменные окружения. Это значительно безопаснее, чем размещать секреты в репозитории.

Ресурсы для обучения

Terraform Documentation — официальная документация Terraform. Содержит подробные руководства по работе с Providers, Resources, Variables, Modules, Backend, Remote State, Workspaces и языку HCL. Ссылка
Terraform Cloud Documentation — руководство по совместной работе над инфраструктурой: Remote State, Workspaces, управление переменными, контроль доступа, история изменений и автоматизация через Terraform. Ссылка
LabEx — интерактивные лабораторные работы по Terraform, GitOps, облачным платформам и Infrastructure as Code. Позволяет выполнять практические задания непосредственно в браузере. Ссылка
AWS Well-Architected Framework — рекомендации Amazon по проектированию надёжной, безопасной, производительной и экономически эффективной инфраструктуры в AWS. Полезен после освоения базовых возможностей Terraform. Ссылка
Microsoft Learn — бесплатные интерактивные курсы Microsoft по Azure, Terraform, Azure CLI и другим облачным технологиям. Ссылка
Google Cloud Skills Boost — практические лабораторные работы и обучающие курсы по Google Cloud Platform, Terraform, Kubernetes и другим облачным сервисам. Ссылка
Документация Yandex Cloud — официальные руководства по работе с Terraform Provider, созданию облачной инфраструктуры и настройке сервисов Yandex Cloud. Ссылка

Заключение

Теперь вы знаете не только, как создавать инфраструктуру с помощью Terraform, но и как организовать безопасную и масштабируемую работу над ней в команде. В следующей статье мы перейдём к Ansible — инструменту автоматизации конфигурации, который отвечает за настройку уже созданных серверов.

С нуля до Junior DevOps в 2026 году. Часть 6.2. Terraform в облаке. Работа в команде