Terraform CLI: практическое руководство

TL;DR

Кратко: вы научитесь использовать Terraform CLI для инициализации, проверки, планирования, применения и удаления простой Docker-инфраструктуры на основе файла main.tf. Пошаговые команды, контроль состояния, рекомендации по безопасности и чек-листы помогут безопасно экспериментировать и интегрировать Terraform в рабочий процесс.

Terraform — это инструмент Infrastructure as Code (IaC) для описания и управления инфраструктурой в виде конфигураций. Здесь мы разберём работу с Terraform через его командную строку (CLI) на примере создания контейнера Docker по шаблону проекта.

В статье вы найдёте:

• Пошаговую инструкцию по установке git, клонированию проекта и знакомству с main.tf.
• Описание базовых команд Terraform CLI: init, fmt, validate, plan, apply, destroy.
• Практические советы по хранению состояния, безопасности и ролям.
• Чек-листы, методологию тестирования и процедуру отката.

Введение

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

Определение: инфраструктура как код (IaC) — это подход, при котором конфигурации инфраструктуры хранятся в виде файлов и управляются версионно.

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

Кому полезно

• Инженерам DevOps и SRE, которые автоматизируют окружения.
• Разработчикам, желающим воспроизводимые локальные среды.
• Командам, которые внедряют практики IaC и CI/CD.

Пререквизиты

• Базовые знания Terraform: блоки provider, resource, переменные.
• Linux-машина (в примере Ubuntu 20.04 LTS, но подойдёт любая дистрибуция).
• Установленные terraform и docker.

Кратко о совместимости: Terraform CLI взаимодействует с провайдерами через плагины; версии провайдеров и Terraform важно синхронизировать, чтобы избежать конфликтов.

Клонирование основного кода

Следуйте этим шагам, чтобы подготовить рабочую директорию:

1. Установите git, если он отсутствует:

sudo apt install git -y

2. Клонируйте шаблон проекта Terraform CLI из репозитория:

git clone https://github.com/howtoforge-com/terraform-cli.git

3. Перейдите в директорию и откройте файл main.tf в любимом редакторе. Файл main.tf — входная точка проекта: он содержит провайдеры и ресурсы, которые Terraform будет создавать и изменять.

cd terraform-cli && sudo nano main.tf

Описание основных секций, которые вы увидите в примере main.tf:

• Блок terraform { } задаёт required_provider — указывает, что будет использоваться провайдер docker.

• Блок resource “docker_image” “nginx” демонстрирует создание ресурса образа Docker. В примере устанавливается тег nginx:latest и параметр keep_locally = false, чтобы избежать дублирования кэша локально.

• Блок resource “docker_container” “nginx” создаёт контейнер с именем tutorial и отображением порта 8000 хоста на порт 80 контейнера.

Если в вашем main.tf есть другие ресурсы — прочитайте их внимательно и сопоставьте с документацией провайдера.

Работа с Terraform CLI: шаг за шагом

Ниже приведён стандартный рабочий цикл для локальной сборки инфраструктуры и её удаления.

1. Инициализация рабочей директории

Команда terraform init загружает необходимые плагины провайдеров и подготавливает рабочую директорию к работе.

terraform init

Ожидаемый результат: загрузка плагина docker, сообщение об успешной инициализации.

Пояснение: init нужно запускать при первом использовании директории и при изменении секции required_providers.

2. Автоформатирование конфигураций

terraform fmt

fmt делает конфигурации читабельными и единообразными. Полезно перед коммитом и в CI.

3. Валидация конфигурации

terraform validate

validate проверяет синтаксис и базовую корректность конфигурации без доступа к провайдерам.

4. Просмотр плана изменений

terraform plan

plan показывает, какие ресурсы будут созданы, изменены или удалены. Это превентивный шаг: никогда не выполняйте apply без просмотра плана.

5. Применение изменений

terraform apply

После подтверждения (введите yes) Terraform создаст ресурсы. Команда переиспользует вычисления из плана для оптимального исполнения.

6. Просмотр файлов в директории

После apply появится файл terraform.tfstate — локальное состояние инфраструктуры.

ls

Пояснение: файл состояния содержит полное представление ресурсов как видит их Terraform. Его нельзя терять и нужно аккуратно управлять доступом.

7. Удаление инфраструктуры

terraform destroy

Подтвердите вводом yes. destroy удалит все ресурсы, описанные в конфигурации. Это необратимая операция.

Совет: для безопасного удаления держите резервную копию состояния и используйте stage-окружения.

Чек-лист перед запуском apply

• Проверьте, что вы запустили terraform init в рабочей директории.
• Выполните terraform fmt и terraform validate.
• Просмотрите результат terraform plan и подтвердите изменения с коллегами.
• Убедитесь, что у вас есть резервная копия terraform.tfstate и доступ к remote backend при необходимости.
• Проверьте права доступа к Docker или облачному провайдеру.

Частые ошибки и способы их решения

1. “Provider plugin не найден”

   • Решение: выполните terraform init и убедитесь в корректности required_providers и версии Terraform.

2. “Ошибка аутентификации при доступе к Docker/облаку”

   • Решение: проверьте переменные окружения и файлы credential, убедитесь, что токен/ключ действителен.

3. “Конфликт состояния: ресурс уже существует”

   • Решение: синхронизируйте состояние — импортируйте существующий ресурс с помощью terraform import или исправьте state вручную осторожно.

4. “Тайм-аут при создании ресурса”

   • Решение: увеличьте время ожидания в конфигурации провайдера или исправьте сетевые настройки.

Работа с состоянием (state)

Ключевой момент управления Terraform — это state. Ниже — рекомендации по работе с состоянием:

• Для командной работы обязательно используйте удалённый backend (S3, GCS, Azure Blob, Terraform Cloud) с поддержкой блокировок (DynamoDB, Cloud Storage locks).
• Шифруйте файл состояния, если он содержит чувствительные данные.
• Ограничьте доступ к бэкенду через IAM/ACL.
• Не коммитьте terraform.tfstate в git.

Пример: подключение backend S3 — добавляется в блок terraform {} в конфигурации, но в этой статье мы не вносим конфигурацию вашего облака.

Мини-методология: безопасный цикл изменений

1. Создавайте изменения в ветке feature в git.
2. Проводите локально terraform fmt & validate.
3. Генерируйте план и сохраняйте его как артефакт CI.
4. Выполняйте code review и утверждение плана.
5. В CI выполняйте terraform apply с удалённым backend и логированием.
6. Включайте автоматическое тестирование после apply (smoke tests).

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

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

DevOps инженер

• Инициализация backend и управление блокировками.
• Контроль версий провайдеров.
• Настройка CI/CD для apply и rollback.

Разработчик

• Подготовка модулей и локальное тестирование.
• Проверка fmt, validate.
• Подготовка PR с описанием изменений.

Секьюрити инженер

• Ревью переменных и секретов.
• Проверка шифрования state и доступа к backend.
• Настройка аудит-логов.

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

Если apply привёл к ошибкам или избыточным изменениям:

1. Остановите дальнейшие apply в CI (блокировка merge).
2. Оцените terraform plan для восстановления нужного состояния.
3. Если ресурс был удалён ошибочно — проверьте резервные копии state и возможность recreation.
4. В критических случаях выполните terraform destroy на среде и восстановите из IaC в другом контролируемом цикле.

Ключ: заранее прогоняйте сценарии отката в непроизводственных средах.

Cheat sheet: команды Terraform CLI

• terraform init — инициализация рабочей директории и загрузка провайдеров.
• terraform fmt — автоформатирование конфигураций.
• terraform validate — статическая проверка конфигурации.
• terraform plan — просмотр предполагаемых изменений.
• terraform apply — применение изменений (подтверждение yes).
• terraform destroy — удаление всех ресурсов по конфигурации.
• terraform state list — перечисление ресурсов в state.
• terraform import . — импорт внешнего ресурса в state.

Пример импорта Docker-образа (синтаксис зависит от провайдера):

terraform import docker_image.nginx nginx:latest

Безопасность и приватность

• Храните state в удалённом и зашифрованном backend для командной работы.
• Ограничьте доступ к backend через IAM и принципы минимальных привилегий.
• Не записывайте секреты в переменные без шифрования. Используйте секрет-менеджеры (Vault, AWS Secrets Manager и т.п.).
• Для соответствия местным законам о личных данных (например, GDPR) избегайте записи персональных данных в state или обеспечьте их удаление/анонимизацию.

Важно: state может содержать чувствительные метаданные — относитесь к нему как к секрету.

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

• terraform fmt не изменяет файлов (код отформатирован).
• terraform validate проходит без ошибок.
• terraform plan показывает только ожидаемые изменения.
• После terraform apply ресурсы доступны и проходят smoke-тесты.
• Состояние успешно сохраняется в назначенный backend.

Когда не стоит использовать Terraform CLI напрямую

• Если у команды нет практики управления state и блокировок, лучше сначала внедрить Terraform Cloud или backend с блокировками.
• Для одноразовых ручных изменений в большом продакшн-окружении лучше использовать проверенный процесс change management.

Альтернативы и сочетания

• Использование Terraform Cloud/Enterprise для управления state и командной работы.
• Для простых сценариев можно использовать docker-compose для локальной разработки.
• Комбинирование Terraform (инфраструктура) и Ansible (конфигурация) — распространённая практика: Terraform создаёт ресурсы, Ansible настраивает внутри них ПО.

Примеры тест-кейсов и приёмка

1. Создать контейнер с nginx:latest и проверить, что порт 8000 хоста доступен и возвращает HTTP 200.
2. Изменить тег образа и выполнить план — проверить, что план содержит замену ресурса.
3. Удалить контейнер вручную и запустить terraform apply — он должен воссоздать контейнер.

Полезные шаблоны и команды для CI

Пример последовательности шагов в CI (последовательно):

• terraform init -input=false
• terraform fmt -check
• terraform validate
• terraform plan -out=tfplan
• terraform apply -input=false tfplan

Сохраните tfplan как артефакт для ревью перед apply.

Ментальные модели

• Конфигурация — это декларация желаемого состояния. Terraform сравнивает текущее состояние (state) и желаемое и выполняет различия.
• State — это снимок реального мира с точки зрения Terraform. Контролируйте его как код и как секрет.

Примеры шаблонов безопасности для Docker-провайдера

• Ограничьте права пользователя Docker до необходимого минимума.
• Для production используйте orchestration (Kubernetes, Nomad) и предоставляйте Terraform только управление ресурсами уровня инфраструктуры.

Локальные рекомендации для России и соседних регионов

• При использовании облачных провайдеров проверьте требования локального законодательства по хранению данных.
• Для команд, работающих с чувствительными данными, используйте локальные KMS и шифрование state.

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

Terraform CLI — мощный инструмент для быстрого прототипирования и управления инфраструктурой. При правильной организации работы с state, блокировками и CI он легко масштабируется от локальной разработки до командной эксплуатации.

Ключевые практики: всегда планируйте изменения, храните состояние удалённо и шифруйте доступ, прогоняйте автоматические проверки перед применением.

Если вы хотите, могу добавить подробный пример main.tf из этого репозитория с разбивкой по строкам и объяснениями каждой строки, либо подготовить конфигурацию с remote backend для S3/GCS.