Terraform-provider-aws: data.aws_ecs_task_definition: no se pudo obtener la definición de la tarea

también reproducido en terraform 1.0

¡También estoy experimentando el mismo problema! Lo curioso es que al intentar la búsqueda utilizando un estado vainilla (completamente vacío), el plan y la aplicación funcionan como se esperaba. Es solo cuando tengo un archivo de estado existente que no funciona.

Aún más curioso, los recursos no existen en el archivo de estado de todos modos y, sin embargo, ¿falla? 🤔

Buceando en la depuración ... Me di cuenta de que func dataSourceAwsEcsTaskDefinitionRead no se llama en un proyecto básico, pero sí en uno existente. Esto parece ser un patrón de terraforma. Pude reproducir esto creando primero un recurso simple (un grupo de seguridad) y luego tratando de realizar una búsqueda. El plan falló cuando un recurso ya estaba presente en un archivo de estado (el grupo de seguridad en este caso). Verifiqué mi hipótesis creando también una fuente de datos diferente que buscó un grupo de seguridad inexistente. El plan para esto también fracasó.

Si los argumentos de una instancia de datos no contienen referencias a valores calculados, como atributos de recursos que aún no se han creado, la instancia de datos se leerá y su estado se actualizará durante la fase de "actualización" de Terraform, que de forma predeterminada se ejecuta antes de creando un plan. Esto asegura que los datos recuperados estén disponibles para su uso durante la planificación y la diferencia mostrará los valores reales obtenidos.

Los argumentos de la instancia de datos pueden referirse a valores calculados, en cuyo caso los atributos de la instancia en sí no se pueden resolver hasta que se definan todos sus argumentos. En este caso, la actualización de la instancia de datos se aplazará hasta la fase de "aplicar", y todas las interpolaciones de los atributos de la instancia de datos se mostrarán como "calculadas" en el plan, ya que los valores aún no se conocen.

Esto me resulta doblemente interesante. Según los documentos anteriores , la configuración de OP no debería fallar porque data.aws_ecs_task_definition.my-service depende de aws_ecs_task_definition.my-service.family , pero está fallando en la fase del plan * (mi problema también). ¿Quizás este es un error a nivel de terraforma y no a nivel de proveedor?

• Editar: dijo incorrectamente que falló en la fase de aplicación en lugar de en la fase del plan.

@radeksimko , ¿podríamos poner sus ojos en esto? No quiero enviar spam al repositorio principal si no es un problema de terraformación.

También veo este problema.

De hecho, no necesito datos y recursos para lo mismo en el mismo archivo. Comenté los datos y ahora parece estar funcionando mejor.

Relacionado: https://github.com/terraform-providers/terraform-provider-aws/issues/632
Explicación: https://github.com/terraform-providers/terraform-provider-aws/issues/13#issuecomment -318700677

Pude solucionar este problema agregando un "depends_on" a la fuente de datos:

resource "aws_ecs_task_definition" "task" {
...
}
data "aws_ecs_task_definition" "task" {
  depends_on = [ "aws_ecs_task_definition.task" ]
  ...
}

Espero eso ayude.

No es realmente un error, la solución de @parruda es correcta. El resource aws_ecs_service y el data aws_ecs_task_definition ambos esperan que los resource aws_ecs_task_definition ya estén creados.

@KIVagant eso tiene sentido, ya que también estaba experimentando el mismo problema.

Aunque diría que los documentos de Terraform para eso muestran que el objeto data y resource se usan juntos deberían actualizarse para reflejar esto. tal como está ahora, los documentos implican que si el recurso no existe, nada debería fallar.

De lo contrario, @parruda tienen sentido para mí

Probablemente debería haber probado la solución antes de responder, funciona pero hace que se produzca una detección continua de cambios.
Cuál no es el resultado esperado / deseado

La solución de @parruda funcionó para mí, pero ahora el depends_on explícito activa una actualización de las definiciones de mi tarea en cada ejecución de tf. ¿Existe una buena práctica para prevenir eso? Estoy usando Terraform v0.11.5
y provider.aws v1.10.0.

@dendrochronology , uso algo como esto:

data "aws_ecs_task_definition" "blabla" {
  task_definition = "${aws_ecs_task_definition.blabla.family}"
  depends_on = [ "aws_ecs_task_definition.blabla" ]
}


resource "aws_ecs_task_definition" "..." {
  family                = "..."
  task_role_arn         = "${aws_iam_role.blabla.arn}"

  container_definitions = "${data.template_file.task_definition.rendered}"

  depends_on = [
    "data.template_file.task_definition",
  ]

  lifecycle {
    ignore_changes = [
      "container_definitions" # if template file changed, do nothing, believe that human's changes are source of truth
    ]
  }
}


resource "aws_ecs_service" "blabla" {
  name            = "blabla"
  cluster         = "${aws_ecs_cluster.cluster_name.id}"
  task_definition = "${aws_ecs_task_definition.blabla.family}:${max("${aws_ecs_task_definition.blabla.revision}", "${data.aws_ecs_task_definition.blabla.revision}")}"
  desired_count   = 1
  iam_role        = "${aws_iam_role.ecs_service.name}"

// Not compatible with placement_constraints:distinctInstance, commented
//  placement_strategy {
//    type  = "binpack"
//    field = "cpu"
//  }

  placement_constraints {
    type  = "distinctInstance"
  }

  load_balancer {
    elb_name       = "${aws_elb.blabla.name}"
    container_name = "internal"
    container_port = "${var.blabla_port}"
  }

  depends_on = [
    "aws_iam_role.ecs_service",
    "aws_elb.blabla",
    "aws_iam_role.blabla",
    "aws_ecs_task_definition.blabla"
  ]

  lifecycle {
    ignore_changes = ["task_definition"] # the same here, do nothing if it was already installed
  }
}

@KIVagant ahhh, ¡voy a jugar con el gancho del ciclo ignore_changes vida

Ah, bueno, jugaré con eso también. ¿Significaría eso que necesitaría taint manualmente cuando haga cambios en el archivo de plantilla de definición de tareas?

Depende de tus objetivos. En nuestro caso, la plantilla contiene un lugar vacío para los secretos que se están llenando después de la primera instalación por Terraform y no queremos permitir que cambie las definiciones de tareas existentes. Y los controlamos manualmente después de la primera instalación.

@dendrochronology perdón por la falta de respuesta. De hecho, nunca noté el problema porque queremos actualizar la definición de la tarea en cada ejecución. Espero que hayas encontrado una solución.

Esto todavía parece ser un problema, si solo usa lo que está en los documentos, obtendrá esto:

Error: Error running plan: 1 error(s) occurred:

* module.frontshop_staging.data.aws_ecs_task_definition.frontshop: 1 error(s) occurred:

* module.frontshop_staging.data.aws_ecs_task_definition.frontshop: Resource 'aws_ecs_task_definition.frontshop' not found for variable 'aws_ecs_task_definition.frontshop.family'

Lo único que ha cambiado es que está dentro de un módulo y el nombre es frontshop. ¿Podría estar relacionado con el módulo?
Intenté también con depends_on y no funcionará. Estoy pensando en aplicar una primera versión para crear el recurso y luego usar los datos con max para obtener la última revisión.

En realidad, lo que dije es una mentira, parece que hay un problema cuando tiene un JSON no válido para las definiciones de contenedores y el mío no usa la sintaxis heredoc sino un archivo json con una plantilla y debería ser una matriz de contenedores y tengo solo un objeto principal.
Aquí donde me enteré https://github.com/terraform-providers/terraform-provider-aws/issues/2026

buen @jaysonsantos. En mi caso, el error surgió debido a un error de sintaxis json

Con una actualización de proveedor a 1.59 y terraform 11.11, sigo viendo este error.

Si terraform destroy se completa sin errores, funciona bien sin un depend_on.

Sin embargo, si terraform destroy falla en otra cosa, por ejemplo:

 Error removing user, role, or group list from IAM Policy Detach bootstrap-iam-group-attach1:
– NoSuchEntity

No relacionado con el servicio ecs. Algo que ejecutar terraform destruir por segunda vez se resolvería de otra manera. En el segundo pase el

Failed getting task definition ClientException: Unable to describe task definition.

reaparece el error y el archivo de estado está dañado.

Este tema no me queda muy claro. Parece que algunas personas afirman que NO deberíamos usar un depend_on en la fuente de datos para la definición de la tarea, pero en la primera ejecución siempre falla porque el recurso no existe.

FYI para todos los demás que tropiezan con el problema: @skorfmann ilustra en este MR https://github.com/terraform-providers/terraform-provider-aws/pull/10247 una mejor solución usando aws_ecs_task_definition.self.revision y explica por qué el ¡El enfoque depends_on discutido no es lo que quieres!

Esto soluciona el problema de no tener una definición de tarea cuando los recursos se implementan inicialmente. El ejemplo de documentación de referencia directa a "task_family" no funciona y se cierra con un error al aplicarlo inicialmente. Vea también este número # 1274

La razón es que las fuentes de datos no manejan correctamente los datos faltantes. Desafortunadamente, eso no se abordará, como se indica aquí: hashicorp / terraform # 16380 (comentario). Una de las soluciones sugeridas es agregar un depends_on explícito. Sin embargo, esto provoca un cambio potencial en la salida del plan de terraformación, aunque en realidad no va a cambiar. Además, la documentación de Terraform lo desalienta.

Este hilo menciona algunas otras soluciones, pero ninguna de ellas parece ser adecuada para hashicorp / terraform # 16380

aws_ecs_task_definition.self.revision solo se puede hacer referencia, una vez que se crea el recurso (en contraste con la familia, que ya está presente en el código). Aparentemente, esto permite que Terraform resuelva correctamente las dependencias y hace que la fuente de datos se comporte como se esperaba.