Метааргумент lifecycle

На странице Поведение ресурсов описан общий жизненный цикл ресурсов. Некоторые детали этого поведения можно настроить с помощью специального вложенного блока lifecycle внутри тела блока ресурса:

resource "azurerm_resource_group" "example" {
  # ...

  lifecycle {
    create_before_destroy = true
  }
}

Синтаксис и аргументы​

lifecycle — это вложенный блок, который может находиться внутри блока ресурса. Блок lifecycle и его содержимое — это метааргументы, доступные для всех блоков resource независимо от их типа.

В блоке lifecycle доступны аргументы create_before_destroy, prevent_destroy, ignore_changes и replace_triggered_by.

• create_before_destroy (bool) — по умолчанию, если OpenTofu должен изменить аргумент ресурса, который нельзя обновить на месте из-за ограничений удалённого API, OpenTofu вместо этого уничтожит существующий объект, а затем создаст новый объект с настроенными аргументами.

  Метааргумент create_before_destroy меняет это поведение: новый объект-замена создаётся сначала, а предыдущий объект уничтожается после создания замены.

  Это поведение включается явно, поскольку для многих типов удалённых объектов требуются уникальные имена или существуют другие ограничения, которые нужно учитывать, чтобы новый и старый объекты могли существовать одновременно. Например, некоторые типы ресурсов предлагают специальные параметры для добавления случайного суффикса к имени каждого объекта во избежание конфликтов. OpenTofu CLI не может включить такие функции автоматически, поэтому перед использованием create_before_destroy необходимо разобраться в ограничениях каждого типа ресурса.

  Обратите внимание: OpenTofu распространяет и применяет поведение метаатрибута create_before_destroy ко всем зависимостям ресурса. Например, если для ресурса A включён create_before_destroy, но для ресурса B он не включён, а ресурс A зависит от ресурса B, OpenTofu по умолчанию неявно включает create_before_destroy для ресурса B и сохраняет это значение в файле состояния. Нельзя переопределить create_before_destroy на false для ресурса B, поскольку это привело бы к циклическим зависимостям в графе.

  Провижинеры уничтожения этого ресурса не запускаются, если для create_before_destroy задано значение true. Подробнее см. в этом обсуждении на GitHub.

• prevent_destroy (bool) — если для этого метааргумента задано значение true, OpenTofu выдаст ошибку и отклонит любой план, который уничтожил бы объект инфраструктуры, связанный с ресурсом, пока этот аргумент присутствует в конфигурации.

  Это можно использовать как меру защиты от случайной замены объектов, восстановление которых может обойтись дорого, например экземпляров баз данных. Однако это сделает невозможным применение некоторых изменений конфигурации и не позволит использовать команду tofu destroy после создания таких объектов, поэтому использовать этот параметр следует с осторожностью.

  Поскольку для применения защиты этот аргумент должен присутствовать в конфигурации, учтите, что эта настройка не предотвратит уничтожение удалённого объекта, если блок resource будет полностью удалён из конфигурации: в этом случае настройка prevent_destroy также будет удалена, и OpenTofu позволит выполнить уничтожение.

• ignore_changes (список имён атрибутов) — по умолчанию OpenTofu обнаруживает любые различия между текущими настройками реального объекта инфраструктуры и конфигурацией и планирует обновить удалённый объект в соответствии с конфигурацией.

  Функция ignore_changes предназначена для использования в случаях, когда ресурс создаётся со ссылками на данные, которые могут измениться в будущем, но эти изменения не должны влиять на ресурс после его создания. В некоторых редких случаях настройки удалённого объекта изменяются процессами вне OpenTofu, после чего OpenTofu пытается «исправить» их при следующем запуске. Чтобы OpenTofu мог совместно с отдельным процессом управлять одним объектом, метааргумент ignore_changes задаёт атрибуты ресурса, которые OpenTofu должен игнорировать при планировании обновлений соответствующего удалённого объекта.

  Аргументы, соответствующие указанным именам атрибутов, учитываются при планировании операции создания, но игнорируются при планировании обновления. Аргументы задают относительный адрес атрибутов ресурса. Элементы отображений и списков можно указывать с помощью индексной нотации, например tags["Name"] и list[0] соответственно.

  resource "aws_instance" "example" {
    # ...
  
    lifecycle {
      ignore_changes = [
        # Ignore changes to tags, e.g. because a management agent
        # updates these based on some ruleset managed elsewhere.
        tags,
      ]
    }
  }

  Вместо списка можно использовать специальное ключевое слово all, чтобы указать OpenTofu игнорировать все атрибуты. Это означает, что OpenTofu сможет создавать и уничтожать удалённый объект, но никогда не будет предлагать его обновление.

  Игнорировать можно только атрибуты, определённые типом ресурса. ignore_changes нельзя применять к самому себе или к другим метааргументам.

• replace_triggered_by (список ссылок на ресурсы или атрибуты) — заменяет ресурс при изменении любого из указанных элементов. Передайте список выражений, ссылающихся на управляемые ресурсы, экземпляры или атрибуты экземпляров. Если используется в ресурсе с count или for_each, в выражении можно использовать count.index или each.key, чтобы сослаться на определённые экземпляры других ресурсов, настроенных с тем же параметром count или той же коллекцией.

  Ссылки вызывают замену в следующих случаях:

  • Если ссылка ведёт на ресурс с несколькими экземплярами, план обновления или замены любого экземпляра вызовет замену.
  • Если ссылка ведёт на один экземпляр ресурса, план обновления или замены этого экземпляра вызовет замену.
  • Если ссылка ведёт на один атрибут экземпляра ресурса, любое изменение значения атрибута вызовет замену.

  В выражениях replace_triggered_by можно ссылаться только на управляемые ресурсы. Благодаря этому такие выражения можно изменять без принудительной замены.

  resource "aws_appautoscaling_target" "ecs_target" {
    # ...
    lifecycle {
      replace_triggered_by = [
        # Replace `aws_appautoscaling_target` each time this instance of
        # the `aws_ecs_service` is replaced.
        aws_ecs_service.svc.id
      ]
    }
  }

  В replace_triggered_by разрешены только адреса ресурсов, поскольку решение принимается на основе запланированных действий для всех указанных ресурсов. У простых значений, таких как локальные значения или входные переменные, нет собственных запланированных действий, однако им можно придать жизненный цикл, аналогичный жизненному циклу ресурса, используя их с типом ресурса terraform_data.

Пользовательские проверки условий​

В блок lifecycle можно добавить блоки precondition и postcondition, чтобы задать предположения и гарантии относительно работы ресурсов и источников данных. В следующих примерах создаётся предварительное условие, проверяющее, правильно ли настроен AMI.

resource "aws_instance" "example" {
  instance_type = "t2.micro"
  ami           = "ami-abc123"

  lifecycle {
    # The AMI ID must refer to an AMI that contains an operating system
    # for the `x86_64` architecture.
    precondition {
      condition     = data.aws_ami.example.architecture == "x86_64"
      error_message = "The selected AMI must be for the x86_64 architecture."
    }
  }
}

Пользовательские условия помогают зафиксировать предположения, чтобы будущие сопровождающие могли понять замысел и принципы разработки конфигурации. Они также позволяют раньше и в контексте получать полезную информацию об ошибках, помогая пользователям быстрее выявлять проблемы в своих конфигурациях.

Подробнее см. в разделе Пользовательские условия.

Только литеральные значения​

Все настройки lifecycle влияют на то, как OpenTofu строит граф зависимостей и проходит по нему. Поэтому можно использовать только литеральные значения: обработка происходит слишком рано, чтобы вычислять произвольные выражения.