Terraform-provider-aws: data.aws_ecs_task_definition：タスク定義の取得に失敗しました

terraform1.0でも再現

私も同じ問題を経験しています！ 不思議なのは、バニラ状態（完全に空）を使用して検索を試みると、計画と適用が期待どおりに機能することです。 それが機能しないのは、既存の状態ファイルがある場合のみです。

さらに不思議なことに、リソースはとにかく状態ファイルに存在しませんが、それでも失敗しますか？ 🤔

デバッグに飛び込む... func dataSourceAwsEcsTaskDefinitionReadはバニラプロジェクトでは呼び出されないが、既存のプロジェクトでは呼び出されることに気づきました。 これはテラフォームパターンのようです。 最初に単純なリソース（セキュリティグループ）を作成してからルックアップを実行することで、これを再現することができました。 リソースがすでに状態ファイル（この場合はセキュリティグループ）に存在する場合、計画は失敗しました。 存在しないセキュリティグループを検索する別のデータソースも作成して、仮説を検証しました。 この計画も失敗しました。

データインスタンスの引数に、まだ作成されていないリソースの属性など、計算値への参照が含まれていない場合、データインスタンスが読み取られ、Terraformの「更新」フェーズ中にその状態が更新されます。計画の作成。 これにより、取得したデータを計画中に使用できるようになり、差分に取得した実際の値が表示されます。

データインスタンスの引数は計算値を参照する場合があります。その場合、インスタンス自体の属性は、すべての引数が定義されるまで解決できません。 この場合、データインスタンスの更新は「適用」フェーズまで延期され、値がまだわからないため、データインスタンス属性のすべての補間はプランで「計算済み」として表示されます。

これは私にとって二重に興味深いものです。 上記のドキュメントに基づくとdata.aws_ecs_task_definition.my-serviceはaws_ecs_task_definition.my-service.familyに依存しているため、OPの構成は失敗しないはずですが、計画*フェーズでは失敗しています（私の問題も）。 おそらくこれはテラフォームレベルのバグであり、プロバイダーレベルではありませんか？

• 編集：計画フェーズではなく適用フェーズで失敗したと誤って述べました。

@radeksimkoこれに注目してもらえますか？ テラフォームの問題でない場合は、メインリポジトリにスパムを送信したくありません。

この問題も発生しています。

実際、同じファイル内の同じものにデータとリソースは必要ありません。 私はデータをコメントアウトしました、そして今それはより良く働いているようです。

関連： https ：
説明： https ：

データソースに「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がすでに作成されている必要があることを想定しています。

私も同じ問題を経験していたので、それは理にかなっている

そのためのTerraformドキュメントには、 dataオブジェクトと一緒に使用されているresourceが表示されていると思いますが、これを反映するように更新する必要があります。 現在のところ、ドキュメントは、リソースが存在しない場合、何も失敗しないはずであることを暗示しています。

そうでなければ、 @ parrudaソリューションは私にとって理にかなっています

おそらく、返信する前に修正を試す必要があります。それは機能しますが、継続的な変更検出が発生します。
これは期待される/望ましい結果ではありません

@parrudaの修正は私にとってはうまくdepends_onが、tfの実行ごとにタスク定義の更新をトリガーするようになりました。 それを防ぐためのベストプラクティスはありますか？ Terraformv0.11.5を使用しています
およびprovider.awsv1.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'

唯一の変更点は、これがモジュール内にあり、名前がフロントショップであるということです。 モジュールに関連している可能性がありますか？
私もdepends_onで試しましたが、機能しません。 最初のバージョンを適用してリソースを作成し、maxのデータを使用して最新のリビジョンを取得することを考えています。

実際、私が言ったことは嘘です。コンテナ定義に無効なJSONがあり、ヒアドキュメント構文ではなくテンプレート付きのjsonファイルを使用していて、コンテナの配列である必要がある場合に問題があるようです。 1つの主要なオブジェクトのみ。
ここで私はそれについて知りましたhttps://github.com/terraform-providers/terraform-provider-aws/issues/2026

素敵な@jaysonsantos。 私の場合、json構文エラーが原因でエラーが発生しました

プロバイダーを1.59およびterraform11.11にアップグレードしても、このエラーが引き続き表示されます。

terraform destroyがエラーなしで完了する場合、depends_onがなくても正常に機能します。

ただし、たとえば、テラフォームの破棄が他の何かで失敗した場合：

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

ecsサービスとは無関係です。 実行中のテラフォームが2回目に破壊するものは、そうでなければ解決します。 2回目のパスで

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

エラーが再表示され、状態ファイルが破損しています。

この問題は私にはあまり明確ではありません。 一部の人々は、タスク定義のデータソースでdepends_onを使用すべきではないと主張しているようですが、最初の実行では、リソースが存在しないため、常に失敗します。

この問題に遭遇した他のすべての人のための@skorfmann https://github.com/terraform-providers/terraform-provider-aws/pull/10247 aws_ecs_task_definition.self.revisionを使用したより良い回避策とその理由を説明します議論されたdepends_onアプローチはあなたが望むものではありません！

これは、リソースが最初にロールアウトされたときにタスク定義がないという問題を回避しています。 「task_family」を直接参照するドキュメントの例は機能せず、最初に適用したときにエラーで終了します。 この問題＃1274も参照してください

その理由は、データソースが欠落データを適切に処理しないためです。 残念ながら、ここで述べられているように、それは対処されません：hashicorp / terraform＃16380（コメント）。 推奨される回避策の1つは、明示的なdepends_onを追加することです。 ただし、これにより、実際には変更されない場合でも、テラフォームプランの出力に変更が生じる可能性があります。 さらに、Terraformのドキュメント自体によってはお勧めできません。

このスレッドは他のいくつかの回避策に言及していますが、それらのどれも適切ではないようですhashicorp / terraform＃16380

aws_ecs_task_definition.self.revisionは、リソースが作成された後でのみ参照できます（コードにすでに存在するファミリとは対照的です）。 どうやら、これによりTerraformは依存関係を正しく解決し、データソースを期待どおりに動作させることができます。