Terraform-provider-aws: data.aws_ecs_task_definition: कार्य परिभाषा प्राप्त करने में विफल

टेराफ़ॉर्म 1.0 में भी प्रजनन किया गया

मैं भी इसी मुद्दे का सामना कर रहा हूँ! क्या उत्सुक है कि जब वेनिला राज्य (पूरी तरह से खाली) का उपयोग करके खोज का प्रयास करते हैं, तो योजना और उम्मीद के मुताबिक काम लागू करें। यह केवल तभी है जब मेरे पास एक मौजूदा राज्य फ़ाइल है जो काम नहीं करती है।

इससे भी अधिक उत्सुक, संसाधन किसी भी तरह से राज्य में मौजूद नहीं हैं, और फिर भी यह विफल रहता है? 🤔

डिबगिंग में गोताखोरी ... मैंने देखा है कि func dataSourceAwsEcsTaskDefinitionRead को वेनिला प्रोजेक्ट में नहीं मिलता है, लेकिन मौजूदा में है। यह एक टेराफ़ॉर्म पैटर्न प्रतीत होता है। मैं पहले एक साधारण संसाधन (एक सुरक्षा समूह) बनाकर इसे फिर से तैयार करने में सक्षम था, फिर एक लुकअप करने की कोशिश कर रहा था। यह योजना विफल हो गई जब एक संसाधन पहले से ही एक स्टेटफ़ाइल (इस मामले में सुरक्षा समूह) में मौजूद था। मैंने एक अलग डेटा स्रोत बनाकर अपनी परिकल्पना को सत्यापित किया जो एक गैर-मौजूद सुरक्षा समूह को देखता था। इसके लिए योजना भी विफल रही।

यदि किसी डेटा उदाहरण के तर्कों में संगणित मानों का कोई संदर्भ नहीं है, जैसे कि संसाधनों की विशेषताएँ जो अभी तक नहीं बनाई गई हैं, तो डेटा उदाहरण को पढ़ा जाएगा और इसके राज्य को टेराफॉर्म के "ताज़ा" चरण के दौरान अद्यतन किया जाएगा, जो डिफ़ॉल्ट रूप से पहले चलता है एक योजना बना रहा है। यह सुनिश्चित करता है कि पुनः प्राप्त डेटा योजना के दौरान उपयोग के लिए उपलब्ध है और अंतर प्राप्त वास्तविक मूल्यों को दिखाएगा।

डेटा उदाहरण तर्क संगणित मानों को संदर्भित कर सकते हैं, जिस स्थिति में उदाहरण की विशेषताओं को तब तक हल नहीं किया जा सकता जब तक कि इसके सभी तर्क परिभाषित नहीं किए जाते। इस मामले में, "लागू करें" चरण तक डेटा आवृत्ति को ताज़ा करना स्थगित कर दिया जाएगा, और डेटा उदाहरण विशेषताओं के सभी प्रक्षेप योजना में "गणना" के रूप में दिखाएंगे, क्योंकि मान अभी तक ज्ञात नहीं हैं।

यह मेरे लिए दोगुना दिलचस्प है। उपरोक्त डॉक्स के आधार पर, ओपी का विन्यास विफल नहीं होना चाहिए क्योंकि 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

मैं डेटा स्रोत में "depend_on" जोड़कर इस समस्या को हल करने में सक्षम था:

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

आशा है कि इससे सहायता मिलेगी।

यह वास्तव में एक बग नहीं है, @ अपरुडा से समाधान सही है। 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 का उपयोग कर रहा हूं
और प्रदाता .aws v1.10.0।

@ डेंड्रोकॉलॉजी , मैं कुछ इस तरह का उपयोग करता हूं:

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

@ किवगंत आह, मैं ignore_changes जीवन चक्र हुक के साथ खेलने जा रहा हूँ!

आह, अच्छा, मैं उसके साथ भी खेलूंगा। क्या इसका मतलब है कि मुझे मैन्युअल रूप से taint , जब मैं कार्य परिभाषा टेम्पलेट फ़ाइल में परिवर्तन करता हूँ?

यह आपके लक्ष्यों पर निर्भर करता है। हमारे मामले में टेम्प्लेट में उन रहस्यों के लिए खाली स्थान होता है जो टेराफॉर्म द्वारा पहली बार स्थापित किए जाने के बाद भरे जा रहे हैं और हम इसे मौजूदा परिभाषाओं को बदलने की अनुमति नहीं देना चाहते हैं। और हम उन्हें पहली बार स्थापित करने के बाद मैन्युअल रूप से नियंत्रित करते हैं।

@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 है। क्या यह मॉड्यूल से संबंधित हो सकता है?
मैंने depend_on के साथ भी कोशिश की और यह काम नहीं करेगा। मैं संसाधन बनाने के लिए पहले संस्करण को लागू करने के बारे में सोच रहा हूं और फिर नवीनतम संशोधन प्राप्त करने के लिए अधिकतम डेटा का उपयोग कर सकता हूं।

वास्तव में, मैंने जो कहा है वह झूठ है, ऐसा लगता है कि एक समस्या है जब आपके पास कंटेनर परिभाषाओं के लिए अमान्य JSON है और मेरा heredoc सिंटैक्स का उपयोग नहीं कर रहा है, लेकिन एक टेम्पलेट के साथ एक json फ़ाइल है और इसमें कंटेनरों की एक सरणी होनी चाहिए और मेरे पास है केवल एक मुख्य वस्तु।
यहाँ मुझे इसके बारे में पता चला जहाँ https://github.com/terraform-providers/terraform-provider-aws/issues/2026

एक अच्छा @jaysonsantos। मेरे मामले में, त्रुटि सिंसैक्स त्रुटि के कारण सामने आई

प्रदाता को 1.59 पर अपग्रेड करने और 11.11 पर टेराफॉर्म के साथ, मैं अभी भी इस त्रुटि को देख रहा हूं।

यदि टेराफ़ॉर्म नष्ट बिना किसी त्रुटि के पूरा हो जाता है, तो यह एक depend_on के बिना ठीक काम करता है।

हालाँकि, यदि टेराफ़ॉर्म नष्ट उदाहरण के लिए कुछ और पर विफल रहता है:

 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.

त्रुटि resurfaces और स्थिति फ़ाइल दूषित है।

यह मुद्दा मेरे लिए बहुत स्पष्ट नहीं है। लगता है कि कुछ लोगों का दावा है कि हमें टास्क डेफिनिशन के लिए डेटा स्रोत में depend_on का उपयोग नहीं करना चाहिए, लेकिन पहले रन पर यह हमेशा विफल रहता है क्योंकि संसाधन मौजूद नहीं है।

FYI करें सबके लिए किसी और मुद्दे पर ठोकर: @skorfmann इस एमआर में सचित्र https://github.com/terraform-providers/terraform-provider-aws/pull/10247 एक बेहतर समाधान का उपयोग करते हुए aws_ecs_task_definition.self.revision और क्यों बताते हैं चर्चा की गई depends_on दृष्टिकोण वह नहीं है जो आप चाहते हैं!

यह कार्य परिभाषा के आसपास काम कर रहा है जब संसाधनों को शुरू में रोल आउट किया जाता है। "टास्क_फैमिली" को सीधे संदर्भित करने का डॉक्यूमेंटेशन उदाहरण काम नहीं करता है और शुरू में इसे लागू करते समय एक त्रुटि के साथ बाहर निकलता है। यह अंक # 1274 भी देखें

इसका कारण यह है, कि डेटा स्रोत गुम डेटा को इनायत से नहीं संभालते हैं। दुर्भाग्य से, यह संबोधित नहीं किया जाएगा, जैसा कि यहां बताया गया है: हैशिकॉर्प / टेराफॉर्म # 16380 (टिप्पणी)। सुझाए गए वर्कअराउंड में से एक है, एक खोज depends_on जोड़ना। हालाँकि, यह टेराफ़ॉर्म प्लान आउटपुट में संभावित बदलाव का कारण बनता है, भले ही यह वास्तव में बदलने वाला न हो। इसके अलावा, यह Terraform प्रलेखन द्वारा ही हतोत्साहित है।

इस धागे में कुछ अन्य कार्यदलों का उल्लेख है, लेकिन उनमें से कोई भी उपयुक्त हैशिकॉर्प / टेराफॉर्म # 16380 नहीं है

aws_ecs_task_definition.self.revision केवल संदर्भित किया जा सकता है, एक बार संसाधन बनने के बाद (परिवार के विपरीत, जो पहले से ही कोड में मौजूद है)। जाहिर है, यह टेराफॉर्म को निर्भरता को सही ढंग से हल करने की अनुमति देता है और डेटा स्रोत को अपेक्षित रूप से व्यवहार करता है।