Terraform-provider-aws: aws_alb_target_group не может воссоздать с подключенными слушателями

Созданный на 13 июн. 2017  ·  33Комментарии  ·  Источник: hashicorp/terraform-provider-aws

_Эта проблема была первоначально открыта @AlexShuraits как hashicorp/terraform#13076. Он был перенесен сюда как часть разделения провайдера . Исходное тело вопроса ниже._


Всем привет,

Я изменил порт для aws_alb_target_group, что заставляет использовать новый ресурс.
Чем при попытке удалить целевую группу. Я получаю следующую ошибку:

Error deleting Target Group: ResourceInUse: Target group 'xxxx' is currently in use by a listener or a rule status code: 400, request id: 747913f1-1213-11e7-916c-3f605d5e091b

Итак, я предполагаю, что он должен сначала удалить слушателя. Это то, что я сделал вручную, чтобы решить проблему.

Терраформ-версия

Терраформ v0.9.1

Затронутые ресурсы

  • aws_alb_target_group
  • aws_alb_listener_rule
servicelbv2

Самый полезный комментарий

Сочетание перемещения name в tags и включения create_before_destroy решает проблему.

resource "aws_alb_target_group" "test" {
  lifecycle {
    create_before_destroy = true
  }

  port     = "8081"
  protocol = "HTTP"
  vpc_id   = "${var.vpc_id}"


  tags {
    Name = "test"
  }
}

Все 33 Комментарий

Я тоже сталкиваюсь с этим с 0.9.8

@radeksimko Это тоже сложный вопрос. Не могли бы вы помочь нам решить ее, пожалуйста? Каков правильный способ ее решения?

Насколько я знаю, есть две возможности «использовать ресурс», чтобы предотвратить уничтожение.

  1. Действие по умолчанию aws_alb_listener
  2. Часть aws_alb_listener_rule

Я подумываю добавить такой параметр, как «force_destroy». Включение этого заставляет перебирать все балансировщики нагрузки, затем слушатели, чем правила. В случае связи с правилом, правило также будет удалено. Это решит вторую проблему. Я не уверен в первом, но следующий кандидат target может быть установлен по умолчанию. Это звучит не так уж и плохо.

Как вам @radeksimko?

Кстати, эта проблема была одной из главных в предыдущих трекерах. :)

То же самое в 0.9.11

я добавил

  lifecycle {
    create_before_destroy = true
  }

слушателю и целевой группе и смог повторно подать заявку с изменениями. Не уверен, кто из них сделал трюк.

@spanktar Не похоже, что это сработает, если имя вашей целевой группы не изменится, поскольку имена целевых групп должны быть уникальными. Вы можете подтвердить или опровергнуть?

Решение @spanktar не работает, если имя целевой группы не меняется.

@varjoinen вам нужно использовать name_prefix с create_before_destroy.

@hoffmannliu-ayla было бы неплохо, если бы это было исправлено https://github.com/terraform-providers/terraform-provider-aws/issues/1301

Вы можете добавить random_id|pet к идентификатору ресурса целевой группы с create_before_destroy в политике жизненного цикла и использовать киперы со случайным идентификатором для вещей, которые в конечном итоге попытаются циклически использовать ресурс как обходной путь.

@GrantSheehan , это сработало, спасибо. Ужасно, но со своей задачей справляется.

Для моего варианта использования я немного изменил вашу идею:

resource "random_string" "target_group" {
  length = 8
  special = false
}


resource "aws_lb_target_group" "preview" {
  # Target group names conflict on update, hence the random 
  name     = "my-name-${random_string.target_group.result}"
  ...

  lifecycle {
    create_before_destroy = true
    ignore_changes = ["name"]
  }
}

без хранителей для автоматического обновления при любых изменениях.

@hraban Terraform это не нравится с моей стороны
Ошибка
aws_alb_target_group.blabla-tg: aws_alb_target_group.blabla-tg: различия не совпадали во время применения. Это ошибка Terraform, о которой следует сообщать как о проблеме GitHub.

хорошо, держите нас в курсе ваших отчетов об ошибках!

Решение @hraban не работает для меня в 11.1.0

*(я полагаю, я мог бы вручную удалить конфликтующие правила/вложения перед повторным применением - это не идеально)

-- ударившись лицом об стол, боль прекращается --

Сочетание перемещения name в tags и включения create_before_destroy решает проблему.

resource "aws_alb_target_group" "test" {
  lifecycle {
    create_before_destroy = true
  }

  port     = "8081"
  protocol = "HTTP"
  vpc_id   = "${var.vpc_id}"


  tags {
    Name = "test"
  }
}

Я также использую https://www.terraform.io/docs/providers/random/r/id.html , чтобы обойти эту проблему.

Как мы выяснили, проблема на самом деле в том, что мы не можем удалить ресурс до того, как будет создана новая целевая группа. Мы обходим это с помощью атрибута lifecycle , установив для create_before_destroy значение true.
К сожалению, если имя ресурса статичное, мы сталкиваемся с проблемой, когда возникает конфликт имен. Это проблема только в том случае, если атрибут изменен, что приводит к созданию новой целевой группы. Атрибуты, обеспечивающие такое поведение, четко определены в https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_lb_target_group.go#L48 .

Решение проблемы может быть реализовано, абстрагировано в модуле или решено в строке, я опубликую свое решение о том, как мы исправили это в строке.

locals {
  LB-name = "${terraform.workspace}-LB"
  LB-protocol = "HTTP"
  LB-vpc-id = "${var.vpc-id}"
  LB-target-type = "ip"
}

resource "random_id" "LB" {
  keepers {
    name = "${local.LB-name}"
    protocol = "${local.LB-protocol}"
    vpc_id ="${local.LB-vpc-id}"
    target_type = "${local.LB-target-type}"
  }
  byte_length = 4
}

resource "aws_lb_target_group" "LB" {
  name = "${local.LB-name}-${random_id.LB.hex}"
  port = 9292
  protocol = "${local.LB-protocol}"
  vpc_id ="${local.LB-vpc-id}"
  target_type = "${local.LB-target-type}"

  lifecycle {
    create_before_destroy = true
  }
}

В моем случае name , protocol , vpc_id и target_type являются потенциально изменяющимися атрибутами, изменение которых приводит к созданию новой целевой группы. Я извлек их в локальные переменные и передал их в ресурс random_id в качестве киперов, что в основном читается между строк: «Если ни один из атрибутов в карте киперов не изменится, вывод ресурса random_id останется статичным». Я намеренно не добавлял port в карту хранителей (и локальные переменные), так как это не требует создания новой целевой группы, но может быть обновлено на месте.

Обратите внимание, что я использую random_id.LB.hex внутри имени target_groups, поэтому при изменении атрибута хранителя меняется и имя целевой группы, что заставляет нас обойти проблему коллизии имен.

Тем не менее, это общее высокоуровневое решение проблемы, и, возможно, было бы лучше, если бы его можно было исправить внутри провайдера или ядра. Решение, безусловно, также может быть абстрагировано в модуль.

Недавно я столкнулся с этой проблемой.

Я удалил своих слушателей в своей консоли AWS. а затем запустил terrafrom plan/apply и все заработало.

Использование ${substr(uuid(),0, 3)} сработало для меня

resource "aws_lb_target_group" "preview" {
  # Target group names conflict on update, hence the random 
  name     = "my-name-${${substr(uuid(),0, 3)}}"
  ...

  lifecycle {
    create_before_destroy = true
    ignore_changes = ["name"]
  }
}

На самом деле не вижу смысла резать случайную строку из 3 символов, коллизии возможны при такой степени детализации.

все еще проблема на 0.11.13

И еще проблема на 0.12.3

Я попробовал решение uuid, но мне нужно, чтобы оно не менялось, если другие вещи не изменились, и я не могу понять, как это сделать.

До сих пор я добился приличного успеха, используя random_integer , аналогично обходному пути выше. Я обязательно вытаскиваю значения через хранителей.

resource "random_integer" "web_target_group_id" {
  min = 1
  max = 999

  keepers = {
    port        = "${local.web_port}"
    protocol    = "HTTP"
    vpc_id      = "${var.vpc_id}"
  }
}
resource "aws_lb_target_group" "web" {
  name                 = "foo-web-${random_integer.web_target_group_id.result}"
  port                 = "${random_integer.web_target_group_id.keepers.port}"
  protocol             = "${random_integer.web_target_group_id.keepers.protocol}"
  vpc_id               = "${random_integer.web_target_group_id.keepers.vpc_id}"

  lifecycle {
    create_before_destroy = true
  }

  # ...etc
}

Видя это в v0.12.4

Видя это в v0.12.8

Видя это в v0.12.9

Видя это в v0.12.10

Этой проблеме уже три года.

Я получил это в Terraform v0.12.24 и provider.aws v2.58.0.

та же проблема с v0.12.24:
Ошибка: ошибка при удалении целевой группы: ResourceInUse: целевая группа ' arn :aws :elasticload balance :XXXXXXXXXXXX ' в настоящее время используется прослушивателем или правилом
код состояния: 400, идентификатор запроса: XXXXXXXX

Есть ли обходной путь для этого? Я тоже не могу пройти мимо.

Всем привет.

Как видите, API AWS не позволяет удалять целевую группу, если к ней прикреплено правило прослушивателя. Когда номер порта в целевой группе изменяется, это вызывает пересоздание целевой группы. К сожалению, в настоящее время в Terraform нет способа сказать «также удалить этот ресурс при удалении другого ресурса», но у нас есть некоторые мысли о том, как решить эту проблему .

В дополнение к аргументу name aws_alb_target_group поддерживает name_prefix и также генерирует случайное имя, если ни одно из них не указано. Как предлагается в https://github.com/terraform-providers/terraform-provider-aws/issues/636#issuecomment -397459646, вместо этого имя можно установить в теге Name . Из-за принципа работы name_prefix и ограничения длины имен целевых групп префикс может состоять только из шести символов.

Некоторые другие решения, использующие поставщика random для добавления уникальности именам, также будут работать.

Установка lifecycle { create_before_destroy = true } также необходима для разрыва цикла зависимости между ресурсами.

Я собираюсь закрыть эту проблему, потому что это ограничение API AWS и того, как Terraform обрабатывает ресурсы, и поставщик AWS не может решить эту проблему. Существует ряд обходных путей, которые можно использовать для решения проблемы.

Преодолели это, переименовав и переименовав группу aws_alb_target_group.

Я собираюсь заблокировать эту проблему, потому что она была закрыта _30 дней_ ⏳. Это помогает нашим специалистам по сопровождению находить активные проблемы и фокусироваться на них.

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

Была ли эта страница полезной?
0 / 5 - 0 рейтинги