how/resources

lifecycle: четыре рычага управления ресурсом

create_before_destroy для zero-downtime, prevent_destroy для критичного, ignore_changes для дрейфа, replace_triggered_by для каскадной пересборки. Что каждый делает на практике.

Блок lifecycle внутри resource - это мета-блок. Он не описывает, что ресурс делает в облаке, он описывает, как Terraform должен с этим ресурсом обращаться: в каком порядке создавать и удалять, разрешать ли менять, что пересоздавать при смене зависимостей.

Четыре аргумента, каждый для своего сценария. Жми ▶ - пройдём по ним и посмотрим, что меняется в поведении apply и destroy.

step 1/6·00 · дефолт: destroy → create

§ шаги

Без блока lifecycle Terraform ведёт себя предсказуемо: если изменился атрибут, который требует replace (force-new), он сначала уничтожает старый инстанс, потом создаёт новый.

Между этими двумя моментами ресурса нет. Для EC2-инстанса под балансировщиком это секундный пинок. Для базы данных - потеря коннектов и кэша. Для уникального IP - окно без сервиса.

Дальше - четыре способа повлиять на это поведение.

итого

Краткий гид «когда что»:

create_before_destroy = true - нужен zero-downtime. Подходит для замены EC2-инстансов, AMI, контейнерных задач. Не подходит, если у ресурса уникальное имя или уникальный IP/порт, который не может одновременно существовать в двух копиях (классический ботлнек: aws_security_group с одинаковым именем).
prevent_destroy = true - для продакшн-БД, S3 с данными пользователей, IAM-ролей с историей. Это «отказ apply'у», если он попытается удалить ресурс. Чтобы реально снести - нужно сначала руками снять флаг и сделать новый apply, а потом только destroy.
ignore_changes = [...] - когда дрейф ожидаем. Например, auto-scaling меняет desired_capacity, облако ставит свои timestamp-теги, кто-то прикручивает теги другим инструментом. Список путей-полей, где дрейф разрешён. Не использовать как «временный костыль» - забудешь, и поле тихо отстанет.
replace_triggered_by = [...] - когда смена одного ресурса обязательно требует пересоздания другого. Типичный кейс: меняется aws_launch_template, и нужно, чтобы все aws_instance, использующие его, тоже перезапустились (иначе они будут жить на старой версии).

Подводный камень общий: lifecycle нельзя задать через variable. Все четыре поля принимают только литералы. То есть create_before_destroy = var.zero_downtime - не сработает. Это дизайн-решение HashiCorp, потому что граф зависимостей строится до evaluation.

Дальше: tf-variable-precedence про то, откуда Terraform берёт значения переменных.

§ копнуть в базу знаний

§ попробовать руками

§ шаги

Без блока lifecycle Terraform ведёт себя предсказуемо: если изменился атрибут, который требует replace (force-new), он сначала уничтожает старый инстанс, потом создаёт новый.

Между этими двумя моментами ресурса нет. Для EC2-инстанса под балансировщиком это секундный пинок. Для базы данных - потеря коннектов и кэша. Для уникального IP - окно без сервиса.

Дальше - четыре способа повлиять на это поведение.