Когда terraform apply действительно выполняется: что происходит после утверждения плана

Вы просмотрели вывод плана. Вы убедились, что Terraform создаст два EC2-инстанса, не удалит существующую базу данных и прикрепит правильную группу безопасности. Теперь вы вводите terraform apply и нажимаете Enter. Терминал заполняется сообщениями вроде aws_instance.app_server: Creating..., и вы ждёте.

Этот момент — когда инфраструктура-как-код перестаёт быть конфигурационным файлом и становится реальной инфраструктурой. Серверы запускаются. Сети настраиваются. DNS-записи создаются. Но что именно происходит во время terraform apply, и как убедиться, что этот шаг не вызовет проблем?

Почему стоит использовать сохранённый файл плана

Самый безопасный способ запуска terraform apply — передать ему файл плана, который вы сгенерировали ранее. После выполнения terraform plan -out=plan.tfplan вы можете выполнить terraform apply plan.tfplan. Это гарантирует, что Terraform применит именно то, что вы просмотрели, ни больше, ни меньше.

Вот точная последовательность команд для генерации и применения сохранённого файла плана:

terraform plan -out=plan.tfplan
terraform apply plan.tfplan

Риск запуска terraform apply без файла плана неочевиден, но реален. Между моментом выполнения terraform plan и terraform apply кто-то из вашей команды может смержить изменения в ту же конфигурацию. Или вы можете изменить файл переменных, не заметив этого. Когда вы запускаете terraform apply без сохранённого плана, Terraform пересчитывает план, используя текущую конфигурацию. Результат может отличаться от того, что вы просматривали десять минут назад.

Для production-сред всегда используйте сохранённый файл плана. Это создаёт аудиторский след: вы можете указать на plan.tfplan и сказать: «это именно то, что было утверждено». Для staging- или dev-сред, где изменения малы и часты, удобство запуска terraform apply без файла плана может быть приемлемым. Просто осознавайте компромисс.

Что происходит в процессе apply

Когда terraform apply выполняется, он не просто «применяет конфиг». Он взаимодействует с API провайдера для каждого ресурса, который нужно изменить. Если вы создаёте aws_instance, Terraform вызывает AWS EC2 API для запуска инстанса. Если вы обновляете google_storage_bucket, он вызывает Google Cloud Storage API.

Каждый вызов API может занимать от миллисекунд до нескольких минут. Создание виртуальной машины обычно занимает от 30 секунд до нескольких минут. Развёртывание управляемого Kubernetes-кластера может занять 10-15 минут. Terraform показывает прогресс в терминале, но не даёт индикатора выполнения для отдельных ресурсов. Вы видите сообщения вроде:

Следующая блок-схема обобщает поток apply и ветвления при успехе или сбое:

flowchart TD A[Запуск terraform apply] --> B[Чтение файла плана или перепланирование] B --> C[Получение блокировки состояния] C --> D[Для каждого ресурса: вызов API провайдера] D --> E{Все ресурсы созданы/обновлены?} E -- Да --> F[Запись полного состояния в файл состояния] F --> G[Снятие блокировки состояния] G --> H[Apply выполнен успешно] E -- Нет --> I[Частичное сохранение состояния для созданных ресурсов] I --> J[Снятие блокировки состояния] J --> K[Требуется ручное вмешательство] K --> L[Исправить проблему и повторно применить] K --> M[Вручную уничтожить или использовать terraform destroy] 
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]

В течение этого времени Terraform удерживает блокировку состояния. Никто из вашей команды не сможет запустить terraform apply или terraform plan, пока текущая операция не завершится или не истечёт таймаут. Это сделано намеренно: чтобы два человека не могли одновременно изменять одну и ту же инфраструктуру.

Что происходит при успешном apply

После успешного создания или обновления всех ресурсов Terraform записывает текущее состояние в файл состояния. Этот файл состояния содержит каждый ресурс с его уникальным ID, всеми атрибутами и связями между ресурсами. Например, если вы создали EC2-инстанс и прикрепили группу безопасности, файл состояния знает, что aws_instance.app_server связан с aws_security_group.web_sg.

Этот файл состояния становится единственным источником истины для вашей инфраструктуры. При следующем запуске terraform plan Terraform сравнивает вашу конфигурацию с файлом состояния, а не с реальными облачными ресурсами. Вот почему повреждённые или отсутствующие файлы состояния вызывают так много проблем: Terraform теряет точку отсчёта.

Что происходит при сбое apply

Сбои apply случаются достаточно часто, и вы должны знать, как с ними работать. Создание ресурса может завершиться ошибкой из-за:

  • Достижения лимита квоты (например, слишком много EC2-инстансов в регионе)
  • Истечения срока действия или недействительности учётных данных провайдера
  • Конфликта с существующим ресурсом (например, попытка создать DNS-запись, которая уже существует)
  • Сбоя или троттлинга облачного провайдера

При сбое Terraform не откатывает всё. Он помечает ресурсы, которые не удалось создать, и сохраняет состояние для того, что было успешно создано. Это означает, что вы оказываетесь в частичном состоянии: некоторые ресурсы существуют, некоторые — нет. Terraform не очищает автоматически ресурсы, созданные до сбоя.

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

  • Исправить проблему (например, запросить увеличение квоты) и снова запустить terraform apply. Terraform попытается создать оставшиеся ресурсы.
  • Вручную уничтожить созданные ресурсы и начать заново.
  • Использовать terraform destroy для очистки всего, но только если вы уверены, что хотите удалить все ресурсы.

Такое поведение с частичным состоянием — одна из причин, почему стоит тестировать изменения инфраструктуры в непроизводственной среде. Сбой apply в production может оставить вашу инфраструктуру в несогласованном состоянии, требующем ручного вмешательства.

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

Прежде чем ввести terraform apply в любой значимой среде, проверьте следующее:

  • Просмотрели ли вы вывод плана на предмет неожиданных изменений, особенно удалений?
  • Сделан ли бэкап файла состояния или хранится ли он в удалённом бэкенде с версионированием?
  • Есть ли у вас учётные данные для отката, если что-то пойдёт не так?
  • Есть ли окно обслуживания или уведомление для команды?
  • Для production: использовали ли вы сохранённый файл плана (terraform apply plan.tfplan)?
  • Для изменений в базе данных: есть ли у вас отдельный план отката миграции, не зависящий от Terraform?

Конкретный вывод

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