terraform apply: применить план в реальном облаке

Что делает apply

terraform apply выполняет три шага подряд:

1. Генерирует план (как terraform plan).
2. Показывает план и спрашивает подтверждение: «Будут такие-то изменения. Применить? Введи yes».
3. После подтверждения вызывает API облака и реально создаёт/меняет/удаляет ресурсы.
4. Обновляет state-файл (terraform.tfstate): записывает туда что получилось.

То есть это первая команда, которая что-то реально делает в облаке. До неё, только разговоры.

Два способа запустить

Способ 1: с интерактивным подтверждением (рекомендуется)

terraform apply

Terraform покажет план, в конце спросит:

Do you want to perform these actions?

  Terraform will perform the actions described above.

  Only 'yes' will be accepted to approve.

  Enter a value:

Введите yes (ровно три буквы, без y, без Y, без Yes): apply начнёт выполнение. Любой другой ввод отменит.

Способ 2: применить заранее сохранённый план

terraform plan -out=tfplan.bin

# ... Вы смотрите план, ревьюер согласовывает ...

terraform apply tfplan.bin

Когда apply запускают с файлом плана. Terraform не спрашивает подтверждения. Считается, что согласование уже было на этапе ревью plan'а.

Этот способ, стандарт в CI/CD. Один pipeline-шаг строит план в PR, второй применяет его после мержа.

-auto-approve: когда можно, когда нельзя

Флаг -auto-approve пропускает интерактивный вопрос:

terraform apply -auto-approve

Когда это нормально:

• Учебные/демонстрационные задачи (как в этом курсе с LocalStack).
• CI/CD пайплайны, где план уже был сохранён и заревьюен.
• Локальные ephemeral-окружения, которые вы регулярно сносите.

Когда это опасно:

• Прод. Никогда не запускайте apply -auto-approve в продакшен-окружение из локального терминала. Один опечатанный символ в HCL, и вы пересоздадите production-базу.
• Чужой код. Скачали репозиторий с GitHub, не читали внимательно HCL, apply -auto-approve может удалить ваши ресурсы.

Правило: -auto-approve допустим только когда вы уверены, что план уже был проверен (либо вами, либо ревьюером, либо тестами).

Что показывает apply во время выполнения

aws_s3_bucket.demo: Creating...

aws_s3_bucket.demo: Still creating... [10s elapsed]

aws_s3_bucket.demo: Creation complete after 12s [id=my-bucket-12345]

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

Разбор:

• Creating.... Terraform отправил запрос в API, ждёт.
• Still creating... [10s elapsed], операция длительная, Terraform периодически напоминает что ждёт.
• Creation complete after 12s [id=my-bucket-12345], ресурс создан, ID известен.
• Apply complete! Resources: 1 added, 0 changed, 0 destroyed, итоговая сводка.

Параллельность и почему apply иногда долгий

По умолчанию Terraform применяет до 10 ресурсов параллельно. Если у вас 100 независимых бакетов, apply создаст их в 10 параллельных потоков.

Зависимости вычисляются автоматически: если в одном ресурсе есть ${aws_s3_bucket.demo.id}. Terraform создаст бакет первым, потом тот ресурс, который на него ссылается. Это называется граф зависимостей.

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

terraform apply -parallelism=20    # больше потоков

terraform apply -parallelism=1     # последовательно (для отладки)

Если apply упал на полпути

Бывает: половина ресурсов создалась, половина, нет. API облака вернул ошибку (превышен квота, конфликт имени).

Что произошло:

• Уже созданные ресурсы записаны в state. Они существуют.
• Не созданные, отсутствуют и в state, и в облаке.
• State валиден, не повреждён.

Что делать:

• Исправить причину (увеличить квоту, поменять имя).
• Запустить apply ещё раз. Terraform увидит существующие в state и пропустит их; попробует доделать остальные. Это называется идемпотентность.

Подводные камни

• Между plan и apply что-то может измениться. Кто-то руками удалил ресурс в консоли AWS, apply упадёт. Решение: либо применять сохранённый план через apply tfplan.bin, либо смириться и запустить plan заново.

• yes пишется строчными буквами. Yes, YES, y, отменяют операцию. Это сделано специально: подтверждение должно быть осознанным.

• Apply не откатывает изменения. Если 5 из 10 ресурсов создались и шестой упал. Terraform НЕ удалит уже созданные пять. State обновлён, ресурсы существуют. Откатывать можно только новым apply (с корректным HCL) или destroy.

• Время выполнения зависит от облака. AWS S3-бакет, секунды. AWS RDS-инстанс, 10-20 минут. Это нормально, Terraform не виноват.

• Не запускайте два apply одновременно. State-файл блокируется на время apply. Если запустить второй, он либо подождёт, либо упадёт с ошибкой locking.