Terraform-provider-aws: data.aws_ecs_task_definition : 작업 정의를 가져 오지 못했습니다.

terraform 1.0에서도 재현

나도 같은 문제가 발생합니다! 흥미로운 점은 바닐라 상태 (완전히 비어 있음)를 사용하여 검색을 시도 할 때 예상대로 작업을 계획하고 적용한다는 것입니다. 작동하지 않는 기존 상태 파일이있을 때만 발생합니다.

더 궁금한 것은 리소스가 어떻게 든 상태 파일에 존재하지 않지만 실패한다는 것입니다. 🤔

디버깅에 대해 자세히 살펴보면 func dataSourceAwsEcsTaskDefinitionRead 가 바닐라 프로젝트에서 호출되지 않고 기존 프로젝트에서 호출된다는 것을 알게되었습니다. 이것은 테라 폼 패턴으로 보입니다. 먼저 간단한 리소스 (보안 그룹)를 만든 다음 조회를 시도하여이를 재현 할 수있었습니다. 리소스가 상태 파일 (이 경우 보안 그룹)에 이미있을 때 계획이 실패했습니다. 존재하지 않는 보안 그룹을 조회하는 다른 데이터 소스도 생성하여 내 가설을 확인했습니다. 이에 대한 계획도 실패했습니다.

데이터 인스턴스의 인수에 아직 생성되지 않은 리소스의 속성과 같은 계산 된 값에 대한 참조가 포함되지 않은 경우 데이터 인스턴스를 읽고 해당 상태가 Terraform의 "새로 고침"단계 동안 업데이트됩니다.이 단계는 기본적으로 이전에 실행됩니다. 계획 만들기. 이렇게하면 검색된 데이터를 계획 중에 사용할 수 있으며 diff는 얻은 실제 값을 표시합니다.

데이터 인스턴스 인수는 계산 된 값을 참조 할 수 있으며,이 경우 모든 인수가 정의 될 때까지 인스턴스 자체의 속성을 확인할 수 없습니다. 이 경우 데이터 인스턴스 새로 고침은 "적용"단계까지 연기되며 데이터 인스턴스 속성의 모든 보간은 값이 아직 알려지지 않았기 때문에 계획에서 "계산 됨"으로 표시됩니다.

이것은 나에게 두 배로 흥미 롭습니다. 위의 문서를 기반으로 data.aws_ecs_task_definition.my-service 이 aws_ecs_task_definition.my-service.family 에 의존하기 때문에 OP의 구성이 실패해서는 안되지만 계획 * 단계에서 실패했습니다 (내 문제도 마찬가지입니다). 아마도 이것은 공급자 수준이 아닌 테라 폼 수준의 버그일까요?

• 편집 : 계획 단계 대신 적용 단계에서 실패했다고 잘못 말했습니다.

@radeksimko 우리가 이것에 당신의 눈을 얻을 수 있습니까? 테라 폼 문제가 아닌 경우 메인 저장소를 스팸하고 싶지 않습니다.

이 문제도보고 있습니다.

실제로 동일한 파일에서 동일한 데이터와 리소스가 필요하지 않습니다. 나는 데이터를 주석 처리했으며 이제 더 잘 작동하는 것 같습니다.

관련 : https://github.com/terraform-providers/terraform-provider-aws/issues/632
설명 : https://github.com/terraform-providers/terraform-provider-aws/issues/13#issuecomment -318700677

데이터 소스에 "depends_on"을 추가하여이 문제를 해결할 수있었습니다.

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

도움이 되었기를 바랍니다.

실제로 버그가 아니며 @parruda 의 솔루션이 정확합니다. resource aws_ecs_service 및 data aws_ecs_task_definition 모두 관련 resource aws_ecs_task_definition 이 (가) 이미 생성되어 있어야한다고 예상합니다.

동일한 문제가 발생했기 때문에 @KIVagant 가 의미가 있습니다.

data 개체와 함께 사용되는 resource 표시에 대한 Terraform 문서는이를 반영하도록 업데이트해야한다고 말하고 싶습니다. 현재 문서는 리소스가 존재하지 않으면 실패하지 않아야 함을 암시합니다.

그렇지 않으면 @parruda 솔루션이 나에게 의미가 있습니다.

Ya 나는 아마도 답장하기 전에 수정을 시도해야했지만 작동하지만 지속적인 변경 감지가 발생합니다.
예상 / 원하는 결과가 아님

@parruda 의 수정이 저에게 depends_on 가 모든 tf 실행에서 내 작업 정의에 대한 업데이트를 트리거합니다. 이를 방지하기위한 모범 사례가 있습니까? Terraform v0.11.5를 사용하고 있습니다.
및 provider.aws v1.10.0.

@dendrochronology , 나는 다음과 같이 사용합니다.

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 아 , 저는 ignore_changes 라이프 사이클 후크를 가지고 놀겠습니다!

아, 좋아, 나도 그걸 가지고 놀게. 그러면 작업 정의 템플릿 파일을 변경할 때 수동으로 taint 해야합니까?

그것은 당신의 목표에 달려 있습니다. 우리의 경우 템플릿에는 Terraform이 처음 설치 한 후 채우는 비밀에 대한 빈 공간이 포함되어 있으며 기존 작업 정의를 변경하는 것을 허용하지 않습니다. 그리고 처음 설치 후 수동으로 제어합니다.

@dendrochronology 응답이 없어서 죄송합니다. 매 실행마다 작업 정의를 업데이트하기를 원하기 때문에 실제로 문제를 발견하지 못했습니다. 해결책을 찾으 셨기를 바랍니다.

이것은 여전히 ​​문제인 것 같습니다. 문서에있는 것을 사용하면 다음과 같은 결과를 얻을 수 있습니다.

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'

유일한 변경 사항은 이것이 모듈 내부에 있고 이름이 frontshop이라는 것입니다. 모듈과 관련이 있습니까?
나는 또한 dependent_on으로 시도했지만 작동하지 않습니다. 리소스를 생성하기 위해 첫 번째 버전을 적용한 다음 max와 함께 데이터를 사용하여 최신 버전을 가져올 생각입니다.

사실, 내가 말한 것은 거짓입니다. 컨테이너 정의에 잘못된 JSON이 있고 내 것이 heredoc 구문을 사용하지 않고 템플릿이있는 json 파일을 사용하는 경우 문제가있는 것처럼 보이며 컨테이너의 배열이어야합니다. 단 하나의 주요 개체.
여기에서 내가 찾은 곳 https://github.com/terraform-providers/terraform-provider-aws/issues/2026

좋은 사람 @jaysonsantos. 제 경우에는 json 구문 오류로 인해 오류가 발생했습니다.

공급자를 1.59 및 terraform 11.11로 업그레이드해도 여전히이 오류가 표시됩니다.

terraform destroy가 오류없이 완료되면 dependent_on없이 정상적으로 작동합니다.

그러나 예를 들어 terraform destroy가 다른 작업에서 실패하는 경우 :

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

ecs 서비스와 관련이 없습니다. 테라 폼을 실행하면 두 번째로 파괴되는 문제가 해결됩니다. 두 번째 패스에서

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

오류가 다시 발생하고 상태 파일이 손상되었습니다.

이 문제는 저에게 명확하지 않습니다. 일부 사람들은 작업 정의를 위해 데이터 소스에서 dependent_on을 사용해서는 안된다고 주장하는 것처럼 보이지만 처음 실행하면 리소스가 존재하지 않기 때문에 항상 실패합니다.

이 문제를 해결하는 다른 모든 사람을위한 참고 자료 : @skorfmann 은이 MR https://github.com/terraform-providers/terraform-provider-aws/pull/10247에 설명되어 있으며 aws_ecs_task_definition.self.revision 사용하는 더 나은 해결 방법 과 그 이유를 설명합니다. 논의 된 depends_on 접근 방식은 당신이 원하는 것이 아닙니다!

이것은 자원이 처음에 롤아웃 될 때 작업 정의가없는 문제를 해결하는 것입니다. "task_family"를 직접 참조하는 문서화 예제는 작동하지 않고 처음 적용 할 때 오류와 함께 종료됩니다. 이 호 # 1274 참조

그 이유는 데이터 소스가 누락 된 데이터를 정상적으로 처리하지 않기 때문입니다. 불행히도 여기에 언급 된대로 hashicorp / terraform # 16380 (주석)은 해결되지 않습니다. 제안 된 해결 방법 중 하나는 depends_on 을 추가하는 것입니다. 그러나 이로 인해 실제로 변경되지는 않더라도 테라 폼 계획 출력에 잠재적 인 변경이 발생합니다. 또한 Terraform 문서 자체에 의해 권장되지 않습니다.

이 스레드는 몇 가지 다른 해결 방법을 언급하지만 그중 어느 것도 적절한 hashicorp / terraform # 16380으로 보이지 않습니다.

aws_ecs_task_definition.self.revision 는 리소스가 생성 된 후에 만 ​​참조 할 수 있습니다 (코드에 이미있는 패밀리와 달리). 분명히 이것은 Terraform이 종속성을 올바르게 해결하고 데이터 소스가 예상대로 작동하도록합니다.