Метааргумент 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 не может автоматически включить такие возможности, поэтому перед использованием 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 следует игнорировать при планировании обновлений связанного удалённого объекта.

  Аргументы, соответствующие указанным именам атрибутов, учитываются при планировании операции создания, но игнорируются при планировании обновления. Аргументы задаются относительными адресами атрибутов ресурса. На элементы map и списка можно ссылаться с помощью индексной нотации, например 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. Поэтому можно использовать только литеральные значения: обработка происходит слишком рано для вычисления произвольных выражений.