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

До этого момента мы изучали 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.

---

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

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

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

---

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

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

• разрешить SSH (22);

• разрешить HTTP (80);

• разрешить HTTPS (443);

• запретить остальные подключения.

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

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

---

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

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

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

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

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

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

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

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

1. AWS — как наиболее востребованная платформа на мировом рынке.

2. Google Cloud Platform или Microsoft Azure — в зависимости от специализации компании.

3. Yandex Cloud — как дополнительное облако для работы с локальными проектами и понимания общих принципов.

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

---

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

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

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

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

---

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

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

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

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

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

terraform apply

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

1. Terraform читает HCL-конфигурацию.

2. Определяет, какой Provider необходимо использовать.

3. Загружает Provider (если он ещё не установлен).

4. Через Provider отправляет запрос в API облачного провайдера.

5. Облачная платформа создаёт необходимые ресурсы.

6. 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-проект.

Например:

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

---

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. Ссылка ^[5]

• Terraform Cloud Documentation — руководство по совместной работе над инфраструктурой: Remote State, Workspaces, управление переменными, контроль доступа, история изменений и автоматизация через Terraform. Ссылка ^[6]

• LabEx — интерактивные лабораторные работы по Terraform, GitOps, облачным платформам и Infrastructure as Code. Позволяет выполнять практические задания непосредственно в браузере. Ссылка ^[7]

• AWS Well-Architected Framework — рекомендации Amazon по проектированию надёжной, безопасной, производительной и экономически эффективной инфраструктуры в AWS. Полезен после освоения базовых возможностей Terraform. Ссылка ^[8]

• Microsoft Learn — бесплатные интерактивные курсы Microsoft по Azure, Terraform, Azure CLI и другим облачным технологиям. Ссылка ^[9]

• Google Cloud Skills Boost — практические лабораторные работы и обучающие курсы по Google Cloud Platform, Terraform, Kubernetes и другим облачным сервисам. Ссылка ^[10]

• Документация Yandex Cloud — официальные руководства по работе с Terraform Provider, созданию облачной инфраструктуры и настройке сервисов Yandex Cloud. Ссылка ^[11]

---

Заключение

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