Развёртывание EC2 в AWS с Terraform

Схема развёртывания EC2 в AWS с помощью Terraform

Terraform позволяет описывать инфраструктуру как код и автоматизировать развёртывание AWS EC2. В статье показаны шаги: установка и инициализация Terraform, безопасная настройка учётных данных, создание конфигурации (data + resource), планирование и применение. В конце — рекомендации по безопасности, откату и чек-листы для доставляемых конфигураций.

Быстрые ссылки

Terraform
Terraform и AWS

Автоматизация экономит время, снижает расходы и уменьшает число ошибок. Один из популярных инструментов для этого — Terraform. Его цель — версионировать инфраструктуру через конфигурацию как код. Одна из частых задач — перенос рабочих нагрузок в облако; Amazon Web Services (AWS) — одна из крупнейших платформ. AWS предоставляет виртуальные машины через Amazon Elastic Compute Cloud (EC2), и Terraform позволяет автоматизировать создание EC2‑инстансов.

В этой статье приведён практический пример развёртывания EC2‑инстанса в AWS с помощью Terraform, а также дополнительные рекомендации для эксплуатации, безопасности и отката.

Что такое Terraform

Terraform — инструмент для описания, изменения и версионирования инфраструктуры в виде кода. Он управляет ресурсами через провайдеры (например, AWS) и применяет изменения через план и исполнение.

Коротко: Terraform хранит состояние и сопоставляет конфигурацию с реальным окружением. Это делает развёртывания повторяемыми и совместимыми с системами контроля версий.

Основные шаги для создания и развертывания EC2:

Установка и инициализация Terraform
Настройка учётных данных и создание конфигурации Terraform
Планирование конфигурации (валидация)
Применение конфигурации

Установка Terraform

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

Учётные данные

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

Два простых варианта хранения учётных данных вне репозитория:

Переменные окружения

$ export AWS_ACCESS_KEY_ID="AWSAccessKey"
$ export AWS_SECRET_ACCESS_KEY="AWSSecretKey"
$ export AWS_DEFAULT_REGION="us-west-2"

В конфигурации Terraform укажите провайдера aws без параметров — Terraform автоматически прочитает переменные окружения:

provider "aws" {}

Плюс: ключи не лежат на диске. Минус: доступны только в рамках текущей сессии.

Файл на диске (~/.aws/credentials)

Формат файла:

[default]
aws_access_key_id=AWSAccessKey
aws_secret_access_key=AWSSecretKey

Если установлен AWS CLI, команда aws configure создаст этот файл автоматически. В конфигурации Terraform часто указывают профиль и регион:

provider "aws" {
  region  = "us-west-2"
  profile = "default"
}

Советы по безопасности учётных данных:

Используйте роли IAM с минимальными правами вместо длинно-живущих ключей.
Для CI/CD применяйте временные креденшалы (assume role) или AWS OIDC/IRSA механизмы.
Храните секреты в менеджерах (Secrets Manager, Vault) и подставляйте в пайплайны.

Важно: никогда не коммитьте файлы с секретами.

Инициализация Terraform

Создайте файл provision.tf (или любой .tf) в рабочей директории и поместите туда определение провайдера. Затем выполните:

terraform init

Команда загрузит нужные плагины (провайдеры) и подготовит локальное окружение. Terraform инициализирует backend и плагины только если в каталоге есть соответствующие .tf‑файлы.

Описание конфигурации EC2

Ниже — пример простой конфигурации: мы ищем последний Ubuntu 18.04 AMI и создаём t2.micro инстанс.

Блок data для поиска AMI

data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
  }
  owners = ["099720109477"]
}

Пояснения:

most_recent = true — если вернётся несколько AMI, берётся самый новый.
filter по имени AMI ограничивает выбор образов Ubuntu Bionic.
owners указывает владельца образа (официальный Ubuntu AMI owner ID).

Ресурс aws_instance

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"

  tags = {
    Name = "LinuxVM"
  }
}

Замечание: раньше использовали синтаксис ${data.aws_ami.ubuntu.id}. В новых версиях HCL допускается просто data.aws_ami.ubuntu.id.

Планирование конфигурации

Перед применением всегда запускайте:

terraform plan

Plan показывает, какие ресурсы будут созданы, изменены или удалены. Пример вывода:

user@computer# ./terraform plan
Refreshing Terraform state in-memory prior to plan...
...

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami = "data.aws_ami.ubuntu.id"
      + arn = (known after apply)
      + associate_public_ip_address = (known after apply)
...

Plan: 1 to add, 0 to change, 0 to destroy.

Если план соответствует ожиданиям, можно применить изменения.

Применение конфигурации

Команда:

terraform apply

Она предложит подтвердить план (введите yes). При успешном выполнении будет выведен результат создания ресурсов и их идентификаторы.

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Почему перенос инфраструктуры в Terraform полезен

Версионирование инфраструктуры в Git позволяет отслеживать изменения.
Повторяемость развёртываний: одна и та же конфигурация даёт одинаковые результаты.
Рефакторинг инфраструктуры с минимальным риском (terraform plan предупреждает об изменениях).

Когда такой подход не подходит

Для разовых ручных операций, которые сложнее автоматизировать — возможно, проще использовать консоль.
Если инфраструктура опирается на устаревшие провайдеры или нестандартные API без поддержки Terraform.
В very high‑frequency транзакционных ситуациях, где управление состоянием в одном общем state‑файле создаёт узкие места (требуются remote backends с блокировкой).

Альтернативные подходы

AWS CloudFormation — нативный инструмент для AWS, тесная интеграция, но специфичен для AWS.
Pulumi — инфраструктура как код с использованием известных языков программирования (TypeScript, Python, Go).
Ansible — хорош для конфигурации ОС и пошагового управления, но не всегда удобен для idempotent‑управления ресурсами в облаке.

Ментальные модели и эвристики

Модель «describe → plan → apply»: всегда сначала опишите, затем проверьте план, потом применяйте.
Минимизируйте blast radius: одна конфигурация — одна зона ответственности. Разделяйте state по окружениям (prod/stage/dev).
Принцип наименьших прав: давайте Terraform роли с минимально необходимыми разрешениями.

Фактбокс

Формат конфигурации: HCL (HashiCorp Configuration Language).
Типичный рабочий цикл: terraform init → terraform plan → terraform apply.
State: хранится локально по умолчанию; в проде используют remote backend (S3 + DynamoDB для блокировок).

Рольовые чек-листы

Инженер DevOps

Проверил конфигурацию локально (terraform validate)
Сделал terraform plan и проверил изменения
Обновил ветку в Git и открыл PR с описанием изменений

Инженер безопасности

Проверил IAM‑права для используемой роли
Убедился, что секреты не закоммичены
Провёл оценку риска публичных IP и правил безопасности (Security Groups)

Владелец продукта

Подтвердил требования по доступности и стоимости
Утвердил изменения в окружении

Пошаговый SOP для создания EC2 через Terraform

Подготовка репозитория: создайте отдельную директорию для инфраструктуры, инициализируйте Git.
Добавьте .gitignore: state‑файлы локального снапшота, .terraform/* и файлы с секретами.
Опишите provider и используйте модульные блоки для повторного использования.
terraform init → terraform validate → terraform plan.
Обсудите план в PR, получите одобрения, затем выполните terraform apply в CI или вручную.
После развёртывания проверьте состояние инстанса и логи.

Критерии приёмки

EC2 инстанс создан с ожидаемым AMI и типом.
Тэги установлены корректно (Name, environment и т. п.).
Инстанс запускается и доступен по ожидаемым портам (если применимо).
В Terraform state добавлен новый ресурс; terraform plan показывает 0 изменений.

План отката и обработка инцидентов

Откат: откатить изменения можно, восстановив предыдущую конфигурацию в Git и выполнив terraform apply. Если требуется экстренный откат — вручную удалить проблемный ресурс через консоль и скорректировать state (обычно через terraform destroy или state rm + apply).

Инцидент‑руководство при ошибке развертывания:

Остановить дальнейшие автоматические пайплайны.
Посмотреть логи terraform apply и облачные логи AWS (CloudTrail, CloudWatch).
Если инстанс частично создан — удалить ресурс, зафиксировать ошибку, повторно выполнить terraform apply после исправления.
Внести правило в тестовый набор, чтобы предотвратить регресс.

Тесты и критерии приёмки

Acceptance: terraform validate должен пройти без ошибок; terraform plan не должен предлагать неожиданного удаления ресурсов.
Интеграция: проверка доступа к созданному инстансу (SSH или подключение по приложению) в тестовой сети.

Безопасность и жёсткая настройка

Используйте Security Groups вместо широких правил 0.0.0.0/0, если возможно.
Ограничивайте доступ по ключам SSH или используйте Session Manager (SSM) вместо SSH для администрирования.
Храните state в S3 с серверной шифровкой и включённой блокировкой через DynamoDB.
Настройте аудит: включите CloudTrail и сбор логов в централизованный сервис.

Советы по миграции и совместимости

Разделяйте state по окружениям: prod, staging, dev. Это уменьшит риск случайных изменений в проде.
Для миграции существующих ресурсов в Terraform используйте terraform import и затем manual drift reconciliation.
Тестируйте импорт в отдельном окружении, прежде чем перемещать прод‑ресурсы.

Локальные особенности и подводные камни

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

Примеры сценариев отказа

Ошибка: AMI больше не доступен. Решение: скорректировать фильтр data.aws_ami или зафиксировать конкретный AMI ID.
Ошибка: недостаточно прав у роли. Решение: расширить права на необходимые ресурсы (EC2 Describe/RunInstances, IAM pass role если используется instance profile).

Чек-лист перед продовым применением

State хранится в удалённом backend с блокировкой
Произведена рецензия изменений
Секреты вынесены в менеджер секретов
Настроен мониторинг и логирование
Описаны критерии приёмки и план отката

Заключение

Перенос конфигурации AWS в Terraform делает инфраструктуру предсказуемой, управляемой и версионируемой. Для простого EC2‑инстанса достаточно нескольких блоков кода, но на практике важно продумать хранение state, управление секретами и правила безопасности. Следуя описанным шагам и чек‑листам, вы сможете безопасно и повторяемо развёртывать виртуальные машины в AWS с помощью Terraform.

Краткое резюме:

Описывайте инфраструктуру как код и храните её в Git.
Никогда не храните секреты в репозиториях.
Используйте terraform plan как обязательный шаг перед apply.
Храните state удалённо и настраивайте блокировки для командной работы.

Спасибо за чтение. Если нужно, могу подготовить готовый модуль Terraform для вашего окружения или шаблон CI/CD для безопасного выполнения terraform apply.

Развёртывание EC2 в AWS с помощью Terraform