Terraform-provider-aws: data.aws_ecs_task_definition: فشل الحصول على تعريف المهمة

مستنسخة أيضًا في terraform 1.0

أواجه نفس المشكلة أيضًا! المثير للفضول هو أنه عند محاولة البحث باستخدام حالة الفانيليا (فارغة تمامًا) ، قم بالتخطيط وتطبيق العمل كما هو متوقع. إنه فقط عندما يكون لدي ملف حالة موجود لا يعمل.

والأكثر إثارة للفضول ، أن الموارد غير موجودة في ملف الحالة على أية حال ، ومع ذلك فشلت؟ 🤔

الغوص في تصحيح الأخطاء ... لقد لاحظت أن func dataSourceAwsEcsTaskDefinitionRead لا يتم استدعاؤه في مشروع الفانيليا ، ولكنه يفعل في مشروع موجود. يبدو أن هذا نمط التضاريس. تمكنت من إعادة إنتاج هذا عن طريق إنشاء مورد بسيط أولاً (مجموعة أمان) ثم محاولة إجراء بحث. فشلت الخطة عندما كان المورد موجودًا بالفعل في ملف الحالة (مجموعة الأمان في هذه الحالة). لقد تحققت من فرضيتي من خلال إنشاء مصدر بيانات مختلف يبحث عن مجموعة أمان غير موجودة. الخطة لهذا فشلت أيضا.

إذا كانت وسيطات مثيل البيانات لا تحتوي على مراجع للقيم المحسوبة ، مثل سمات الموارد التي لم يتم إنشاؤها بعد ، فسيتم قراءة مثيل البيانات وتحديث حالته أثناء مرحلة "التحديث" الخاصة بـ Terraform ، والتي تعمل افتراضيًا قبل إنشاء خطة. هذا يضمن أن البيانات المسترجعة متاحة للاستخدام أثناء التخطيط وسيظهر الفرق القيم الحقيقية التي تم الحصول عليها.

قد تشير وسيطات مثيل البيانات إلى القيم المحسوبة ، وفي هذه الحالة لا يمكن حل سمات المثيل نفسه حتى يتم تحديد جميع الوسائط الخاصة به. في هذه الحالة ، سيتم تأجيل تحديث مثيل البيانات حتى مرحلة "تطبيق" ، وستظهر جميع عمليات الإقحام لسمات مثيل البيانات "محسوبة" في الخطة نظرًا لأن القيم غير معروفة بعد.

هذا مثير للاهتمام بشكل مضاعف بالنسبة لي. بناءً على المستندات المذكورة أعلاه ، لا ينبغي أن يفشل تكوين OP لأن data.aws_ecs_task_definition.my-service يعتمد على aws_ecs_task_definition.my-service.family ، لكنه فشل في مرحلة الخطة * (مشكلتي أيضًا). ربما هذا خطأ على مستوى التضاريس وليس على مستوى المزود؟

• تحرير: قالت بشكل غير صحيح إنها فشلت في مرحلة التقديم بدلاً من مرحلة الخطة.

radeksimko هل يمكن أن نضع عينيك على هذا؟ لا أريد إرسال بريد عشوائي غير مرغوب فيه إلى الريبو الرئيسي إذا لم تكن مشكلة تتعلق بالتصحيح.

أرى هذه المشكلة أيضًا.

لا أحتاج في الواقع إلى بيانات وموارد لنفس الشيء في نفس الملف. علقت على البيانات ويبدو الآن أنها تعمل بشكل أفضل.

ذات صلة: https://github.com/terraform-providers/terraform-provider-aws/issues/632
التفسير: https://github.com/terraform-providers/terraform-provider-aws/issues/13#issuecomment -318700677

تمكنت من التغلب على هذه المشكلة عن طريق إضافة "يعتمد على" إلى مصدر البيانات:

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 هذا منطقي ، لأنني كنت أيضًا أعاني من نفس المشكلة.

على الرغم من أنني أود أن أقول إن مستندات Terraform التي تعرض الكائن data و resource اللذين يتم استخدامهما معًا يجب تحديثهما ليعكس ذلك. كما هو الحال الآن ، يشير المستند ضمنيًا إلى أنه إذا لم يكن المورد موجودًا فلن يفشل شيء.

وإلا فإن حلول 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 ahhh ، أنا ذاهب للعب مع خطاف دورة الحياة 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'

الأشياء الوحيدة التي تغيرت هي أن هذا داخل وحدة والاسم هو الواجهة الأمامية. هل يمكن أن تكون مرتبطة بالوحدة؟
حاولت أيضًا مع يعتمد على ولن ينجح. أفكر في تطبيق الإصدار الأول لإنشاء المورد ثم استخدام البيانات بحد أقصى للحصول على أحدث مراجعة.

في الواقع ، ما قلته هو كذبة ، يبدو أن هناك مشكلة عندما يكون لديك JSON غير صالح لتعريفات الحاوية ولا يستخدم لي صيغة heredoc ولكن ملف json به قالب ويجب أن يكون مصفوفة من الحاويات ولدي كائن رئيسي واحد فقط.
هنا حيث اكتشفت ذلك https://github.com/terraform-providers/terraform-provider-aws/issues/2026

لطيفjaysonsantos. في حالتي ، حدث الخطأ بسبب خطأ نحوي json

مع ترقية الموفر إلى 1.59 و terraform 11.11 ، ما زلت أرى هذا الخطأ.

إذا تم تدمير terraform بدون أخطاء ، فإنه يعمل بشكل جيد بدون يعتمد على.

ومع ذلك ، إذا فشل تدمير terraform في شيء آخر على سبيل المثال:

 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.

يظهر الخطأ مرة أخرى ويكون ملف الحالة تالفًا.

هذه المسألة ليست واضحة جدا بالنسبة لي. يبدو أن بعض الأشخاص يزعمون أنه لا ينبغي لنا استخدام يعتمد على مصدر البيانات لتعريف المهمة ، ولكن عند التشغيل الأول ، يفشل دائمًا لأن المورد غير موجود.

لمعلوماتك لأي شخص آخر يتعثر في المشكلة: 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 (تعليق). أحد الحلول المقترحة هو إضافة صريح depends_on . ومع ذلك ، يتسبب هذا في حدوث تغيير محتمل في ناتج خطة التضاريس ، على الرغم من أنها لن تتغير بالفعل. علاوة على ذلك ، فإنه لا يشجع من خلال وثائق Terraform نفسها.

يشير هذا الموضوع إلى بعض الحلول الأخرى ، ولكن لا يبدو أن أيًا منها مناسب hashicorp / terraform # 16380

لا يمكن الإشارة إلى aws_ecs_task_definition.self.revision إلا بعد إنشاء المورد (على عكس العائلة الموجودة بالفعل في الكود). على ما يبدو ، يسمح هذا لـ Terraform بحل التبعيات بشكل صحيح ويجعل مصدر البيانات يتصرف كما هو متوقع.