Модуль Terraform использует data "aws_ami" "latest" с фильтром по имени для получения ID последнего образа, который публикует другая команда вне этого Terraform-проекта, и несколько месяцев всё работало, а затем один terraform apply неожиданно пересоздал все инстансы. Какой риск создаёт зависимость resource от внешнего data source, и как снизить вероятность неожиданного пересоздания ресурсов при обновлении внешних данных?

Короткий ответ

Data source каждый раз запрашивает текущее состояние у провайдера при plan/apply, поэтому если внешняя команда опубликовала новый AMI, подходящий под тот же фильтр, значение data.aws_ami.latest.id меняется без единого изменения в самом Terraform-коде, и ресурс, использующий этот id (например, aws_instance с ami = data.aws_ami.latest.id без lifecycle.create_before_destroy/ignore_changes), будет пересоздан при следующем apply, что и произошло — изменение пришло «снаружи» конфигурации.

Как это работает подробнее

data source в Terraform не версионируется и не фиксируется в конфигурации так, как явный resource: он выполняет live-запрос к API на этапе plan и подставляет свежий результат в граф зависимостей; если результат отличается от предыдущего apply, Terraform видит разницу в значении атрибута, который использует зависимый resource, и планирует соответствующее действие (в данном случае replace, если ami требует пересоздания).

Пример кода

main.tfКопировать

data "aws_ami" "latest" {
  most_recent = true
  owners      = ["self"]
  filter {
    name   = "name"
    values = ["app-*"]
  }
}
resource "aws_instance" "app" {
  ami           = data.aws_ami.latest.id
  instance_type = "t3.medium"
  lifecycle {
    ignore_changes = [ami]
  }
}

Что использовать на практике

• Практика. если нужна предсказуемость, стоит либо зафиксировать конкретный ID образа как явную переменную/значение (а обновление версии образа делать осознанным PR), либо явно задать ignore_changes = [ami] в lifecycle, если автоматическое обновление образа нежелательно для уже работающих инстансов, либо, наоборот, осознанно спроектировать create_before_destroy и rolling-замену, если обновление образа — ожидаемое поведение; выбор зависит от того, управляется ли жизненный цикл образа тем же процессом релиза, что и инфраструктура.

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

• Ошибка. частая ошибка — использовать data с фильтром "последний/latest" для production-ресурсов без понимания, что это делает apply недетерминированным во времени (результат одного и того же кода меняется сам по себе); другая ошибка — добавить ignore_changes «чтобы не пересоздавалось» без отдельного процесса обновления образа, из-за чего инстансы годами работают на устаревшем, неисправленном образе.