Terraform-provider-aws: aws_alb_target_group no puede recrear con oyentes adjuntos

Creado en 13 jun. 2017  ·  33Comentarios  ·  Fuente: hashicorp/terraform-provider-aws

_Este problema lo abrió originalmente @AlexShuraits como hashicorp/terraform#13076. Se migró aquí como parte de la división del proveedor . El cuerpo original del problema se encuentra a continuación._


Hola,

Cambié el puerto para aws_alb_target_group, eso fuerza un nuevo recurso.
Que al intentar eliminar el grupo objetivo. me sale el siguiente error:

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

Entonces, supongo que primero debería eliminar el oyente. Eso es lo que he hecho manualmente para resolver el problema.

Versión Terraform

Terraform v0.9.1

Recursos afectados

  • aws_alb_target_group
  • aws_alb_listener_rule
servicelbv2

Comentario más útil

La combinación de mover name a tags y habilitar create_before_destroy resuelve el problema.

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

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


  tags {
    Name = "test"
  }
}

Todos 33 comentarios

También me encuentro con esto con 0.9.8

@radeksimko Este también es un tema complicado. ¿Nos ayudarías a resolverlo por favor? ¿Cuál es la forma correcta de resolverlo?

Hay dos posibilidades de "recurso en uso" para evitar la destrucción, hasta donde yo sé.

  1. Acción por defecto de un aws_alb_listener
  2. Parte de aws_alb_listener_rule

Estoy considerando agregar un parámetro como "force_destroy". Habilitándolo, obliga a iterar todos los balanceadores de carga, que los oyentes, que las reglas. En caso de una relación con una regla, la regla también se eliminará. Esto resolverá el segundo problema. No estoy seguro sobre el primero, pero se puede configurar un próximo candidato target para que sea el predeterminado. Esto no suena tan mal.

¿Qué opinas @radeksimko?

Por cierto, este problema fue uno de los principales en los rastreadores anteriores. :)

Lo mismo en 0.9.11

yo añadí

  lifecycle {
    create_before_destroy = true
  }

para el oyente y el grupo objetivo y fue capaz de volver a aplicar con éxito con los cambios. No estoy seguro de cuál hizo el truco.

@spanktar No parece que eso funcione si el nombre de su grupo objetivo no cambia, ya que los nombres de los grupos objetivo deben ser únicos. ¿Puedes confirmar o negar?

La solución de @spanktar no funciona si el nombre del grupo objetivo no cambia.

@varjoinen necesita usar name_prefix con create_before_destroy.

@hoffmannliu-ayla sería bueno si esto se arreglara https://github.com/terraform-providers/terraform-provider-aws/issues/1301

Puede agregar un random_id|pet al ID de recurso del grupo de destino con un create_before_destroy en la política de ciclo de vida y usar guardianes en el ID aleatorio para las cosas que terminarían intentando hacer circular el recurso como un solución alterna.

@GrantSheehan que funcionó, gracias. Horrible, pero hace el trabajo.

Para mi caso de uso, terminé modificando ligeramente su idea:

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"]
  }
}

sin guardianes para actualizar automáticamente cualquier cambio.

@hraban Terraform no le gusta de mi lado
El error es
aws_alb_target_group.blabla-tg: aws_alb_target_group.blabla-tg: las diferencias no coincidieron durante la aplicación. Este es un error con Terraform y debe informarse como un problema de GitHub

ok, ¡manténganos informados sobre el progreso de su informe de errores!

La solución de @hraban no funciona para mí en 11.1.0

*(Supongo que podría ir y eliminar manualmente las reglas o los archivos adjuntos en conflicto antes de volver a aplicar; esto no es lo ideal)

-- Golpear mi cara contra el escritorio detiene el dolor --

La combinación de mover name a tags y habilitar create_before_destroy resuelve el problema.

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

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


  tags {
    Name = "test"
  }
}

Estoy usando https://www.terraform.io/docs/providers/random/r/id.html para solucionar el problema también.

Como descubrimos, el problema realmente es que no podemos eliminar el recurso antes de que se cree un nuevo grupo objetivo. Solucionamos eso con el atributo lifecycle estableciendo create_before_destroy en verdadero.
Desafortunadamente, si el nombre del recurso es estático, nos encontramos con el problema, donde tenemos una colisión de nombres. Esto es solo un problema, cuando se cambia un atributo que fuerza la creación de un nuevo grupo objetivo. Los atributos que imponen ese comportamiento están bien definidos en https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_lb_target_group.go#L48

Se puede implementar una solución al problema, abstraerla en un módulo o resolverla en línea. Publicaré mi solución sobre cómo solucionamos esto en línea.

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
  }
}

En mi caso name , protocol , vpc_id y target_type son atributos potencialmente cambiantes que, si se modifican, fuerzan la creación de un nuevo grupo objetivo. Los extraje en variables locales y los pasé al recurso random_id como guardianes, que básicamente dice entre líneas "si ninguno de los atributos en el mapa de guardianes cambia, la salida del recurso random_id permanece estática". Deliberadamente no agregué port al mapa de guardianes (y variables locales), ya que no obliga a crear un nuevo grupo objetivo, pero se puede actualizar en su lugar.

Tenga en cuenta que uso random_id.LB.hex dentro del nombre de target_groups, de modo que si cambia un atributo de los guardianes, cambia el nombre del grupo objetivo, lo que nos permite solucionar el problema de la colisión de nombres.

Dicho esto, esta es una solución genérica de alto nivel para el problema y tal vez sería mejor si se pudiera solucionar dentro del proveedor o del núcleo. La solución seguramente también se puede abstraer en un módulo.

Experimenté este problema recientemente.

Eliminé a mis oyentes en mi consola de AWS. y luego ejecuté un plan/aplicación de terrafrom y funcionó.

Usar ${substr(uuid(),0, 3)} funcionó para mí

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"]
  }
}

Realmente no veo el punto de cortar una cadena aleatoria de 3 caracteres, las colisiones son una posibilidad en esa granularidad.

sigue siendo un problema el 0.11.13

Y sigue siendo un problema en 0.12.3

Probé la solución uuid, pero necesito que no cambie si otras cosas no han cambiado y no puedo entender cómo.

Encontré un éxito decente hasta ahora usando random_integer , similar a la solución anterior. Me aseguro de sacar los valores a través de los guardianes.

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
}

Ver esto en v0.12.4

Ver esto en v0.12.8

Ver esto en v0.12.9

Ver esto en v0.12.10

Este problema ya tiene tres años.

Obtuve esto en Terraform v0.12.24 y provider.aws v2.58.0.

mismo problema con v0.12.24:
Error: error al eliminar el grupo de destino: ResourceInUse: el grupo de destino ' arn:aws :elasticload balanceing :XXXXXXXXXXXX ' está siendo utilizado actualmente por un agente de escucha o una regla
código de estado: 400, ID de solicitud: XXXXXXXX

¿Hay una solución para esto? Parece que tampoco puedo superarlo.

Hola a todos.

Como puede ver, la API de AWS no permite que se elimine un grupo objetivo cuando hay una regla de escucha adjunta. Cuando se cambia un número de puerto en el grupo de destino, obliga a que se vuelva a crear el grupo de destino. Desafortunadamente, actualmente no hay forma en Terraform de decir "también elimine este recurso cuando se elimine otro recurso", pero tenemos algunas ideas sobre cómo abordarlo .

Además del argumento name , aws_alb_target_group admite name_prefix y también generará un nombre aleatorio si no se proporciona ninguno de los dos. Como se sugiere en https://github.com/terraform-providers/terraform-provider-aws/issues/636#issuecomment -397459646, el nombre se puede establecer en una etiqueta Name en su lugar. Debido a cómo funciona name_prefix y al límite de longitud de los nombres de los grupos objetivo, el prefijo solo puede tener seis caracteres.

Algunas de las otras soluciones que usan el proveedor random para agregar unicidad a los nombres también funcionarán.

También se necesita establecer lifecycle { create_before_destroy = true } para romper el ciclo de dependencia entre los recursos.

Voy a cerrar este problema porque esta es una limitación de la API de AWS y de cómo Terraform maneja los recursos, y el proveedor de AWS no puede abordarla. Hay una serie de soluciones alternativas que se pueden utilizar para solucionar el problema.

Superó esto renombrando y eliminando el nombre de aws_alb_target_group

Voy a bloquear este problema porque ha estado cerrado por _30 días_ ⏳. Esto ayuda a nuestros mantenedores a encontrar y concentrarse en los problemas activos.

Si cree que este problema debe reabrirse, lo alentamos a crear un nuevo problema que se vincule a este para agregar contexto. ¡Gracias!

¿Fue útil esta página
0 / 5 - 0 calificaciones