2.6 Terraform: Infrastructure as Code #

🎯 Что такое Terraform простыми словами #

Terraform — это инструмент для описания инфраструктуры в виде кода. Вместо ручного создания серверов и баз данных через веб-интерфейс, вы пишете код, который всё создает автоматически.

🏗️ Аналогия со строительством #

Аналогия со строительством:

Традиционный подход (ручное строительство): Поход в магазин → покупка материалов → доставка на стройку → ручное строительство

Terraform (автоматизированное строительство): Описываем дом в чертеже → нажимаем “печать” → получаем готовый дом

🚀 Зачем нужен Terraform? #

Проблемы без IaC #

Проблемы ручного создания инфраструктуры:

Поэтапные действия разработчика:

Вход в веб-интерфейс AWS Console
Создание VPC (часто забывают про группы безопасности)
Создание EC2-инстанса (можно ошибиться с размером)
Настройка RDS базы данных (можно забыть включить резервное копирование)
Через месяц никто не помнит, что именно создавалось и как

С Terraform #

Подход с Terraform:

Один файл описывает всю желаемую инфраструктуру:

Определяем ресурс EC2-инстанса
Указываем образ AMI (ami-12345)
Выбираем тип инстанса (t3.micro)
Добавляем метки для идентификации

Одна команда “terraform apply” создает всю готовую инфраструктуру

🛠️ Установка Terraform #

🟢 Базовый уровень - Linux/Mac #

Пошаговая установка Terraform на Linux/Mac:

Загрузка: Скачиваем архив Terraform версии 1.7.0 для Linux AMD64 с официального сайта HashiCorp
Распаковка: Извлекаем исполняемый файл из ZIP-архива
Установка: Перемещаем бинарный файл в системную папку /usr/local/bin/
Проверка: Убеждаемся, что Terraform установлен корректно и доступен из командной строки

Windows #

Установка на Windows:

Вариант 1: Использование менеджера пакетов Chocolatey для автоматической установки Terraform

Вариант 2: Ручная загрузка с официального сайта terraform.io/downloads

📁 Структура проекта Terraform #

🟢 Минималистичный проект #

my-infrastructure/
├── main.tf          # Основные ресурсы
├── variables.tf     # Переменные
├── outputs.tf       # Выходные значения
└── terraform.tfvars # Значения переменных

🟡 Продакшн структура #

terraform-project/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   ├── ec2/
│   └── rds/
└── shared/
    └── variables.tf

🎯 Основные команды Terraform #

🟢 Hello World пример #

Базовые команды Terraform для начинающих:

Инициализация проекта: Скачиваем провайдеры и готовим рабочую директорию
Проверка плана: Показываем, какие изменения будут внесены в инфраструктуру
Применение: Выполняем запланированные изменения в облаке
Удаление: Полностью удаляем созданную инфраструктуру

Детальное объяснение команд #

Подробное описание каждой команды Terraform:

terraform init: Инициализация проекта - загружает необходимые провайдеры AWS, Azure, GCP из реестра Результат: Проект готов к работе

terraform plan: Предварительный просмотр изменений - безопасно показывает, что будет создано, изменено или удалено Результат: Никаких изменений в реальной инфраструктуре, только план

terraform apply: Применение изменений - выполняет запланированные операции в реальной инфраструктуре Предупреждение: Изменяет настоящие ресурсы в облаке!

terraform destroy: Удаление всех ресурсов - полностью уничтожает созданную инфраструктуру Критическое предупреждение: Необратимо удаляет все созданные ресурсы!

🌟 Практический пример: Веб-сервер на AWS #

🟢 Простейший EC2 instance #

Конфигурация Terraform для создания веб-сервера в AWS:

Настройка провайдера:

Минимальная версия Terraform: 1.0
AWS провайдер версии 5.x из реестра HashiCorp
Регион размещения: Европа Запад (Ирландия)

Создание EC2-инстанса:

Базовый образ: Amazon Linux 2 (ami-0c02fb55956c7d316)
Тип инстанса: t3.micro (подходит для Free Tier)
Автоматическая настройка через user_data:
- Обновление системных пакетов
- Установка Apache HTTP Server
- Запуск веб-сервера и добавление в автозагрузку
- Создание тестовой HTML-страницы с приветствием

Метки ресурса:

Имя: “WebServer”
Окружение: “Development”
Управляется: “Terraform”

Вывод результата:

Отображение публичного IP-адреса созданного сервера

Запуск примера #

Пошаговое выполнение примера:

Инициализация: Подготавливаем проект - загружаем AWS провайдер и создаем рабочую среду

Просмотр плана: Terraform покажет “План: создать 1 ресурс, изменить 0, удалить 0”

Применение изменений:

Terraform запросит подтверждение
Введите “yes” для продолжения
Процесс создания займет 1-2 минуты

Ожидаемый результат: Получите публичный IP-адрес вида “3.248.123.45” для доступа к веб-серверу

🟡 Средний уровень: Переменные и модули #

Использование переменных #

Определение переменных в файле variables.tf:

Переменная типа инстанса:

Описание: тип виртуальной машины EC2
Тип данных: строка
Значение по умолчанию: t3.micro (для небольших проектов)

Переменная окружения:

Описание: среда развертывания (разработка, тестирование, продакшен)
Тип данных: строка
Обязательна для указания

Переменная разрешенных IP-адресов:

Описание: список IP-адресов для доступа к серверу
Тип данных: список строк
Значение по умолчанию: открыт для всех (0.0.0.0/0)

Использование переменных в основной конфигурации:

Настройка EC2-инстанса с переменными:

Образ AMI: фиксированный Amazon Linux 2
Тип инстанса: берется из переменной instance_type
Метки: динамически формируются с использованием переменной environment
- Имя сервера: “WebServer-” + название окружения
- Окружение: значение переменной environment

Настройка группы безопасности:

Префикс имени: “web-sg-” + название окружения
Входящий трафик HTTP:
- Порт: 80 (стандартный HTTP)
- Протокол: TCP
- Разрешенные адреса: из переменной allowed_ips
Исходящий трафик:
- Разрешен весь трафик во все стороны (типично для веб-серверов)

Пример файла terraform.tfvars с конкретными значениями:

Параметры для staging-окружения:

Тип инстанса: t3.small (больше ресурсов чем по умолчанию)
Окружение: staging (тестовая среда)
Разрешенные IP-сети:
- 203.0.113.0/24 (тестовая подсеть документации RFC)
- 198.51.100.0/24 (дополнительная тестовая подсеть)

🟠 Продвинутый уровень: State Management #

Remote State с S3 #

Настройка удаленного хранения Terraform state в AWS S3:

Конфигурация backend для команды:

S3-бакет: “my-terraform-state-bucket” (централизованное хранилище)
Путь к файлу: “infrastructure/terraform.tfstate” (организованная структура)
Регион AWS: eu-west-1 (Европа)

Механизмы защиты:

Блокировка файла состояния через DynamoDB таблицу “terraform-locks”
Шифрование state-файла для защиты конфиденциальной информации
Предотвращение одновременного редактирования несколькими разработчиками

State команды #

Команды для управления состоянием Terraform:

Просмотр всех ресурсов: Отображает список всех ресурсов, управляемых Terraform в текущем проекте

Детальная информация о ресурсе: Показывает полную конфигурацию и текущее состояние конкретного EC2-инстанса (все атрибуты, IP-адреса, теги)

Импорт существующего ресурса: Добавляет уже созданный в AWS инстанс с ID “i-1234567890abcdef0” под управление Terraform

Удаление из управления: Убирает ресурс из Terraform state, при этом сам ресурс в AWS остается нетронутым (полезно при передаче управления)

🔴 Экспертный уровень: Модули и лучшие практики #

Создание переиспользуемого модуля #

Конфигурация модуля web-server для повторного использования:

Входные параметры модуля:

Окружение: обязательная строковая переменная (для маркировки)
Тип инстанса: строковая переменная с значением по умолчанию t3.micro

Конфигурация EC2-инстанса:

Образ AMI: автоматический поиск последней версии Amazon Linux 2
Группа безопасности: ссылка на соответствующую группу безопасности
Пользовательские данные: загрузка скрипта из шаблона userdata.sh с передачей параметра окружения

Автоматический поиск AMI:

Критерий: последняя версия образа
Владелец: официальные образы Amazon
Фильтр по имени: Amazon Linux 2 AMI с HVM виртуализацией для x86_64 архитектуры

Выходное значение:

Публичный IP-адрес созданного веб-сервера для использования в других частях конфигурации

Использование модуля #

Пример использования одного модуля для разных окружений:

Сервер для разработки:

Путь к модулю: локальная папка modules/web-server
Окружение: “development” (для маркировки и идентификации)
Тип ресурсов: t3.micro (минимальный для экономии)

Сервер для продакшена:

Путь к модулю: тот же модуль modules/web-server
Окружение: “production” (промышленная эксплуатация)
Тип ресурсов: t3.medium (мощнее для продакшена)

Вывод данных:

Публичный IP-адрес сервера разработки для быстрого доступа команды

🏗️ Реальный проект: Полная веб-архитектура #

Архитектура проекта #

Полноценная веб-архитектура в AWS:

Компоненты инфраструктуры:

Сетевая часть: VPC с публичными и приватными подсетями в нескольких зонах доступности
Балансировщик нагрузки: Application Load Balancer для распределения запросов
Вычислительные ресурсы: Auto Scaling Group с EC2-инстансами для автоматического масштабирования
База данных: Управляемая PostgreSQL через AWS RDS
Кэширование: Redis через ElastiCache для ускорения ответов
CDN: CloudFront для глобального распределения контента

main.tf - основная инфраструктура #

Конфигурация основной сетевой инфраструктуры AWS:

Настройка провайдера:

Минимальная версия Terraform: 1.0
AWS провайдер версии 5.x
Регион: получаем из переменной aws_region

Создание VPC (виртуальная частная сеть):

CIDR-блок: 10.0.0.0/16 (около 65000 IP-адресов)
Поддержка DNS: включено для разрешения имен серверов
Метка: динамическое имя на основе переменной project_name

Публичные подсети (для веб-серверов):

Количество: 2 подсети в разных зонах доступности
CIDR-блоки: 10.0.1.0/24 и 10.0.2.0/24 (по 256 адресов каждая)
Автоматическое назначение публичных IP-адресов включено

Приватные подсети (для баз данных):

Количество: 2 подсети в разных зонах доступности
CIDR-блоки: 10.0.10.0/24 и 10.0.11.0/24 (защищенные от интернета)
Публичные IP не назначаются

Интернет-шлюз:

Привязка к созданной VPC
Обеспечивает доступ в интернет для публичных подсетей

Таблица маршрутизации:

Привязка к основной VPC
Маршрут по умолчанию: весь трафик (0.0.0.0/0) направляется через Internet Gateway

Ассоциация маршрутов:

Связываем каждую публичную подсеть с таблицей маршрутизации
Количество ассоциаций: равно количеству публичных подсетей

Security Groups #

Конфигурация групп безопасности для многоуровневой архитектуры:

Группа безопасности для ALB (балансировщик):

Префикс имени: название проекта + “-alb-”
Привязка к созданной VPC

Входящие правила для балансировщика:

HTTP-трафик: порт 80, протокол TCP, доступ открыт для всех IP
HTTPS-трафик: порт 443, протокол TCP, доступ открыт для всех IP

Исходящие правила: Полный доступ ко всем портам и протоколам (стандартно для балансировщиков)

Группа безопасности для EC2-серверов:

Префикс имени: название проекта + “-ec2-”

Входящие правила для серверов:

HTTP от балансировщика: порт 80, доступ только для ALB security group
SSH доступ: порт 22, доступ ограничен CIDR-блоком из переменной ssh_cidr

Исходящие правила: Полный доступ ко всем портам и протоколам (для обновлений и внешних API)

RDS Database #

Конфигурация управляемой базы данных PostgreSQL:

Группа подсетей для базы данных:

Имя: динамическое на основе названия проекта + “-db-subnet-group”
Подсети: все созданные приватные подсети (безопасность через изоляцию)
Метки: идентификация по названию проекта

Группа безопасности для RDS:

Префикс имени: название проекта + “-rds-”
Привязка к основной VPC
Входящие правила: PostgreSQL (порт 5432), доступ только для EC2 security group

Конфигурация RDS-инстанса:

Идентификатор: название проекта + “-db”
Движок: PostgreSQL версии 15.4
Класс инстанса: из переменной db_instance_class
Хранилище: 20 GB начально, автомасштабирование до 100 GB
Шифрование: включено для защиты данных

Параметры резервного копирования:

Период хранения: 7 дней
Окно резервного копирования: 03:00-04:00 (ночью, минимальная нагрузка)
Окно обслуживания: воскресенье 04:00-05:00

Особенности:

Пропуск финального снимка: только для среды разработки (для быстрого удаления)

Variables #

Определение всех переменных для полноценного проекта:

Общие параметры проекта:

Название проекта: строковая переменная с значением по умолчанию “webapp”
Окружение: обязательное указание среды (разработка, тестирование, продакшен)
AWS регион: строковая переменная с значением по умолчанию “eu-west-1”

Параметры вычислительных ресурсов:

Тип EC2-инстанса: строковая переменная с значением по умолчанию “t3.micro”
Класс RDS-инстанса: строковая переменная с значением по умолчанию “db.t3.micro”

Параметры базы данных:

Имя базы: строковая переменная с значением по умолчанию “webapp”
Имя пользователя: строковая переменная с значением по умолчанию “dbadmin”
Пароль: обязательная конфиденциальная переменная (не отображается в логах)

Параметры безопасности:

SSH CIDR: строковая переменная для ограничения SSH-доступа, по умолчанию открыт для всех “0.0.0.0/0”

🔒 Безопасность и лучшие практики #

Secrets Management #

Правильное управление конфиденциальной информацией:

Неправильный подход (НИКОГДА не делайте так):

Определение пароля непосредственно в коде как значение по умолчанию
Опасность: пароль попадает в систему контроля версий!

Правильный подход:

Определение переменной без значения по умолчанию
Маркировка как sensitive: скрывает значение в логах и выводе

Использование AWS Secrets Manager:

Создание секрета: имя на основе названия проекта + “-db-password”
Сохранение значения: пароль сохраняется в зашифрованном виде в AWS
Преимущество: автоматическая ротация паролей

Remote State Security #

Продакшен-конфигурация удаленного state с максимальной безопасностью:

Основные настройки:

S3-бакет: “terraform-state-prod-bucket” (отдельный бакет для продакшена)
Ключ файла: “infrastructure/terraform.tfstate” (организованная структура)
Регион: Европа Запад (Ирландия)

Механизмы защиты:

Шифрование state-файла: включено с AWS KMS ключом
KMS-ключ: ARN ключа шифрования для дополнительной защиты
Блокировка: DynamoDB таблица “terraform-locks” предотвращает одновременное редактирование
Версионирование: автоматическое сохранение всех версий state-файла

Tagging Strategy #

Стратегия маркировки ресурсов для единообразия и аудита:

Определение общих меток:

Проект: название из переменной project_name
Окружение: название из переменной environment
Способ управления: “Terraform” (для отличия от ручно созданных ресурсов)
Ответственная команда: “DevOps Team”
Центр затрат: “Engineering” (для учета расходов)
Дата создания: автоматическое форматирование текущей даты

Пример использования в ресурсах:

Объединение общих меток с специфичными для конкретного ресурса
Имя сервера: название проекта + “-web-server”
Роль: “WebServer” (для идентификации назначения)

🔍 Отладка и мониторинг #

Debugging команды #

Команды для отладки и диагностики Terraform:

Подробное логирование:

Установка переменной окружения TF_LOG=DEBUG для максимальной детализации
Запуск применения с полным логированием всех операций

Логирование в файл:

Установка уровня INFO для сбалансированного логирования
Направление логов в файл terraform.log для последующего анализа

Проверка качества кода:

Проверка форматирования: автоматическое форматирование всех .tf файлов в проекте
Валидация конфигурации: проверка синтаксиса и логической структуры

Визуализация зависимостей:

Генерация графа зависимостей между ресурсами
Преобразование в PNG-изображение с помощью утилиты Graphviz
Полезно для понимания сложных архитектур

Мониторинг изменений #

Настройка правил жизненного цикла для критичных ресурсов:

Правила lifecycle для критичного сервера:

Защита от удаления: prevent_destroy = true предотвращает случайное уничтожение ресурса
Игнорирование обновлений: ignore_changes = [ami] позволяет автоматические обновления AMI без пересоздания
Безопасное обновление: create_before_destroy = true создает новый ресурс перед удалением старого (минимизирует downtime)

📊 Multi-Cloud и Workspaces #

Workspaces для разных окружений #

Команды для управления workspace (рабочими пространствами):

Создание отдельных workspace для каждого окружения:

Разработка: создание workspace с именем “development” для экспериментов
Тестирование: создание workspace “staging” для предпродакшенных тестов
Продакшен: создание workspace “production” для боевой среды

Операции с workspace:

Переключение: выбор рабочего пространства “production” для дальнейших операций
Проверка текущего: отображение имени активного workspace
Просмотр всех: полный список всех доступных workspace

Conditional Resources по workspace #

Конфигурация ресурсов в зависимости от окружения:

Адаптивная конфигурация EC2:

Образ AMI: фиксированный для всех окружений
Тип инстанса: условный выбор - t3.large для продакшена, t3.micro для остальных сред
Метки: автоматическое добавление имени workspace в название сервера

Условное создание мониторинга:

Количество алармов: 1 для продакшена, 0 для остальных сред
Название аларма: автоматическое добавление имени workspace
Компаратор: проверка превышения порогового значения
Остальные параметры: настраиваются соответствующим образом

🚀 CI/CD Integration #

GitHub Actions для Terraform #

Конфигурация CI/CD пайплайна для автоматического развертывания инфраструктуры:

Настройка триггеров:

Название workflow: ‘Terraform’
Запуск при push в главную ветку main
Запуск при создании pull request’ов

Настройка рабочей среды:

Операционная система: Ubuntu последняя версия
Оболочка по умолчанию: bash
Рабочая директория: ./terraform для всех команд

Последовательность шагов:

Checkout: Загрузка исходного кода из репозитория
Setup Terraform: Установка Terraform версии 1.7.0
Проверка форматирования: проверка соответствия стандартам кода
Инициализация: загрузка провайдеров с AWS креденшелами
Валидация: проверка синтаксиса и логики
Планирование: генерация плана изменений без цветового вывода
Применение: автоматическое применение только при push в main ветку

Механизм безопасности:

AWS креденшелы хранятся в GitHub Secrets и передаются через переменные окружения

GitLab CI для Terraform #

Конфигурация GitLab CI/CD пайплайна для Terraform:

Основные настройки:

Базовый образ: официальный Terraform образ от GitLab
Корневая директория: папка terraform в проекте
Адрес state: использование встроенного GitLab Terraform backend

Кэширование:

Ключ кэша: “terraform” для общего использования
Кэшируемые папки: .terraform директория с провайдерами и модулями

Предварительные действия перед каждой работой:

Переход в рабочую директорию terraform
Проверка версии Terraform
Инициализация проекта

Этапы пайплайна:

Валидация: проверка корректности конфигураций
Планирование: генерация плана и сохранение в артифакты
Применение: использование сохраненного плана, только для главной ветки

⚡ Performance и Optimization #

Parallel Execution #

Оптимизация производительности для больших инфраструктур:

Увеличение параллелизма:

Параметр -parallelism=20 позволяет одновременно создавать до 20 ресурсов
По умолчанию Terraform работает с 10 параллельными операциями

Оптимизация для больших инфраструктур:

Планирование без обновления: параметр -refresh=false пропускает синхронизацию с реальными ресурсами (быстрее, но менее точно)
Применение без обновления: аналогичный параметр для быстрого применения

Механизм кэширования:

Ключ кэша: “terraform” для сохранения между запусками
Кэшируемая папка: .terraform с загруженными провайдерами

Этапы работы пайплайна:

Валидация: проверка корректности конфигураций
Планирование: генерация плана и сохранение в файл “planfile”
Применение: использование сохраненного плана, только для главной ветки

Resource Targeting #

Целевое управление конкретными ресурсами:

Целевое применение изменений:

Отдельный ресурс: применение изменений только к конкретному EC2-инстансу web_server
Целый модуль: применение изменений ко всем ресурсам модуля database
Полезно для постепенного обновления части инфраструктуры

Целевое удаление:

Уничтожение только тестового сервера test_server
Остальная инфраструктура остается нетронутой
Критично важно для безопасного обслуживания

🎯 Реальные кейсы использования #

Кейс 1: Migration с CloudFormation #

Пошаговая миграция с AWS CloudFormation на Terraform:

Импорт существующих ресурсов:

EC2-инстанс: добавление существующего сервера с ID “i-1234567890abcdef0” под управление Terraform
Группа безопасности: импорт существующей группы с ID “sg-12345678”
Преимущество: никаких прерываний в работе систем

Генерация конфигурации:

Экспорт текущего state в JSON-формате
Использование jq для фильтрации и выбора ресурсов
Получение детальной информации о всех управляемых ресурсах

Кейс 2: Multi-Region Deployment #

Мультирегиональное развертывание для глобальной доступности:

Настройка мультипле провайдеров:

Провайдер для США: псевдоним “us_east”, регион us-east-1 (Восточное побережье США)
Провайдер для Европы: псевдоним “eu_west”, регион eu-west-1 (Ирландия)
Позволяет работать с несколькими регионами одновременно

Создание ресурсов в разных регионах:

Сервер в США: EC2-инстанс с явным указанием провайдера aws.us_east
Сервер в Европе: EC2-инстанс с явным указанием провайдера aws.eu_west
Полезно для глобальных приложений с низкой задержкой

Кейс 3: Disaster Recovery #

Конфигурация аварийного восстановления (Disaster Recovery):

Основной регион (продакшен):

Модуль: ссылка на локальный модуль “./modules/infrastructure”
Регион: eu-west-1 (Ирландия) - основное место размещения
Окружение: “production” (полная конфигурация)
Признак: is_primary = true (основной регион)

Регион аварийного восстановления:

Модуль: тот же модуль с инфраструктурой
Регион: us-east-1 (Вирджиния) - альтернативное размещение
Окружение: “dr” (специальная маркировка)
Признак: is_primary = false (вторичный регион)

Оптимизация для DR:

Количество инстансов: 1 (минимально для экономии)
Хранение бэкапов: 30 дней (длительное хранение для надежности)

📈 Мониторинг и алерты #

CloudWatch интеграция #

Настройка мониторинга и алармов для Terraform-созданных ресурсов:

Конфигурация аларма на высокую нагрузку CPU:

Название: динамическое на основе названия проекта + “-high-cpu”
Компаратор: “GreaterThanThreshold” (превышение порогового значения)
Периоды оценки: 2 (два последовательных превышения)
Метрика: CPUUtilization из пространства имен AWS/EC2
Период: 120 секунд (2 минуты)
Статистика: среднее значение
Порог: 80% CPU

Привязка к ресурсам:

Мониторинг конкретного EC2-инстанса по ID
Действия при срабатывании: отправка уведомления через SNS-топик

Настройка уведомлений:

Создание SNS-топика с динамическим именем на основе названия проекта

🏆 Лучшие практики Terraform #

1. Структура кода #

Лучшие практики организации Terraform-кода:

✅ Рекомендуемые подходы:

Использование модулей для повторного использования кода
Один ресурс = один файл для крупных проектов
Логическая группировка связанных ресурсов в отдельные файлы
Последовательные соглашения по именованию

❌ Нежелательные подходы:

Один огромный main.tf файл со всеми ресурсами
Прямое указание конкретных значений в коде вместо переменных
Игнорирование автоматического форматирования terraform fmt

2. State Management #

Правильное управление состоянием для надежности:

✅ Обязательные практики:

Удаленное хранение state в продакшен-окружении (не локально)
Блокировка state-файла через DynamoDB для предотвращения конфликтов
Регулярное резервное копирование state-файлов
Отдельные state-файлы для каждого окружения (изоляция рисков)

❌ Опасные практики:

Локальное хранение state при работе в команде (конфликты гарантированы)
Коммит .tfstate файлов в Git-репозиторий (конфиденциальные данные)
Общий state-файл для разработки и продакшена (риск повреждения продакшена)

3. Security #

Принципы безопасности в Terraform:

✅ Обязательные меры безопасности:

Маркировка конфиденциальных переменных как sensitive (скрывает в логах)
Принцип минимальных прав для IAM-ролей и пользователей
Шифрование state-файлов при хранении в S3
Хранение паролей и API-ключей в AWS Secrets Manager

❌ Критически опасные практики:

Прямое указание паролей в Terraform-конфигурации
Излишне широкие IAM-права (например, полный доступ к AWS)
Незашифрованное хранение state-файлов
Использование root ключей доступа AWS

🎯 Практические задания #

🟢 Задание 1: Hello World #

Создайте простой EC2 instance с веб-сервером:

Инициализируйте новый Terraform проект
Создайте EC2 instance с Apache
Выведите публичный IP
Проверьте доступность веб-страницы

🟡 Задание 2: Multi-tier Architecture #

Создайте архитектуру с:

VPC с публичными и приватными подсетями
ALB для балансировки нагрузки
Auto Scaling Group
RDS базой данных

🟠 Задание 3: Модули #

Создайте переиспользуемый модуль для веб-сервера
Используйте модуль в разных окружениях
Добавьте переменные и outputs
Опубликуйте модуль в Terraform Registry

🔴 Задание 4: Production Setup #

Настройте remote state с S3 и DynamoDB
Создайте CI/CD pipeline
Добавьте мониторинг и алерты
Реализуйте blue-green deployment

🔗 Полезные ресурсы #

Документация #

Terraform Documentation - официальная документация
AWS Provider - AWS ресурсы
Terraform Registry - модули и провайдеры

Инструменты #

Terragrunt - DRY конфигурации
Terraform-docs - автогенерация документации
TFLint - линтер для Terraform

Обучение #

HashiCorp Learn - официальные туториалы
Terraform Best Practices - лучшие практики
Gruntwork Infrastructure as Code Library - production-ready модули

🎯 Заключение #

Terraform — это фундаментальный навык DevOps инженера в 2025 году. Основные принципы:

✅ Infrastructure as Code — вся инфраструктура описана в коде
✅ Immutable Infrastructure — изменяем через пересоздание
✅ Version Control — история изменений инфраструктуры
✅ Team Collaboration — общий стандарт для команды
✅ Disaster Recovery — быстрое восстановление из кода

Помните: Terraform не просто инструмент, это новый подход к управлению инфраструктурой. Начните с простых примеров, изучите best practices, и постепенно переходите к сложным сценариям.

Следующий раздел: 2.8 Мониторинг и Observability