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

_Основы Terraform · TerraformLab Knowledge Base_

**TL;DR:** apply берёт результат plan и реально вызывает API облака: создаёт, изменяет, удаляет ресурсы. После apply state обновляется. Это та команда, которая меняет деньги на инфру.

## Что делает `apply`

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

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

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

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

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

```bash
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: применить заранее сохранённый план

```bash
terraform plan -out=tfplan.bin
# ... Вы смотрите план, ревьюер согласовывает ...
terraform apply tfplan.bin
```

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

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

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

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

```bash
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 создаст бакет первым, потом тот ресурс, который на него ссылается. Это называется **граф зависимостей**.

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

```bash
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.


## Команды

```bash
terraform apply
```
Стандартный запуск с интерактивным подтверждением. Рекомендуется для локальной работы.

```bash
terraform apply -auto-approve
```
Без подтверждения. Только для учебных задач и CI.

```bash
terraform apply tfplan.bin
```
Применить ранее сохранённый план. Не спрашивает подтверждения.

```bash
terraform apply -parallelism=20
```
Увеличить число параллельных операций (по умолчанию 10).

```bash
TF_LOG=DEBUG terraform apply
```
Подробный лог: что отправляется в API облака. Для дебага сложных ошибок.


## См. также

- [terraform init: первая команда в любом проекте](/terraform/kb/tf-init.md)
- [terraform plan: посмотреть, что Terraform собирается сделать](/terraform/kb/tf-plan.md)
- [terraform destroy: снести всё, что было создано](/terraform/kb/tf-destroy.md)
- [State: память Terraform о созданном](/terraform/kb/tf-state.md)