Terraform-provider-local: नष्ट होने पर local_file को संरक्षित करने की क्षमता जोड़ें

को निर्मित 5 जन॰ 2018 · 8टिप्पणियाँ · स्रोत: hashicorp/terraform-provider-local

_यह मुद्दा मूल रूप से @alanbchristie द्वारा हैशिकॉर्प /टेराफॉर्म#17040 के रूप में खोला गया था। प्रदाता विभाजन के परिणामस्वरूप इसे यहां माइग्रेट किया गया था। मुद्दे का मूल भाग नीचे है।_

क्या do_not_destroy तर्क को local_file कॉन्फ़िगरेशन आइटम में जोड़ना संभव होगा ताकि जब terraform destroy निष्पादित हो तो जेनरेट की गई स्थानीय फ़ाइल बरकरार रहे? कारण? मैं एक पोस्ट-नष्ट Ansible स्क्रिप्ट के लिए गतिशील सामग्री बनाता हूं और इस प्लेबुक के लिए स्थानीय रूप से जेनरेट की गई फ़ाइल की सामग्री को रखना उपयोगी होगा।

यानी क्या ऐसा करने की क्षमता प्रदान करना स्वीकार्य होगा ...

resource "local_file" "cleanup_vars" {
  content = "${data.template_file.cleanup_vars.rendered}"
  filename = "../../../ansible/aws-cleanup/vars.yml"
  do_not_destroy = true
}

उपरोक्त के साथ यदि terraform apply को फिर से एक्सक्यूट किया जाता है तो किसी भी मौजूदा फ़ाइल को ओवर-राइट करने के लिए बिल्कुल ठीक (और अपेक्षित) है।

टेराफॉर्म संस्करण

Terraform v0.11.1

टेराफॉर्म कॉन्फ़िगरेशन फ़ाइलें

data "template_file" "cleanup_vars" {
  template = "${file("../../../ansible/aws-cleanup/vars.yml.tpl")}"

  vars {
    aws_region = "${var.aws_region}"
  }
}

resource "local_file" "cleanup_vars" {
  content = "${data.template_file.cleanup_vars.rendered}"
  filename = "../../../ansible/aws-cleanup/vars.yml"
}

डीबग आउटपुट

एन/ए

क्रैश आउटपुट

एन/ए

अपेक्षित् व्यवहार

एन/ए

वास्तविक व्यवहार

एन/ए

प्रजनन के चरण

एन/ए

अतिरिक्त संदर्भ

एन/ए

संदर्भ

एन/ए

enhancement

स्रोत

hashibot

👍5

सबसे उपयोगी टिप्पणी

हाय @alanbchristie! इस सुविधा अनुरोध के लिए धन्यवाद और इसका जवाब देने में देरी के लिए खेद है।

हमारा ध्यान कहीं और होने के कारण हाशिकॉर्प की टेराफॉर्म टीम निकट भविष्य में इस पर काम नहीं कर पाएगी, लेकिन अगर आपके या किसी और के पास इसे लागू करने के लिए समय और प्रेरणा है तो हमें पुल अनुरोध की समीक्षा करने में खुशी होगी।

संसाधनों के लिए इस तरह के विकल्पों के लिए कुछ उदाहरण हैं जहां टेराफॉर्म का उपयोग उन्हें बनाने के लिए किया जाता है लेकिन कुछ समय बाद प्रबंधन को किसी अन्य सिस्टम पर पास करना आम है। आम तौर पर इनके नाम verb_on_destroy जैसे होते हैं, जहां "क्रिया" प्रश्न में संसाधन के लिए कुछ उपयुक्त शब्दावली है। इस स्थिति के लिए, मैं तर्क का नामकरण करने का सुझाव दूंगा delete_on_destroy , यह डिफ़ॉल्ट रूप से true है, और फिर स्पष्ट कॉन्फ़िगरेशन delete_on_destroy = false होना चाहिए। यह nomad_job deregister_on_destroy तर्क जैसी अन्य समान मौजूदा सुविधाओं के अनुरूप है।

(यहां *_on_destroy शब्दावली का कारण यह है कि इस संदर्भ में "नष्ट" टेराफॉर्म का संचालन है, जो बदले में लक्ष्य प्रणाली में अन्य संचालन का कारण बनता है। इसे do_not_destroy कॉल करना इसे सेट करने के बाद से भ्रमित हो सकता है वास्तव में टेराफॉर्म को संसाधन इंस्टेंस को नष्ट करने से नहीं रोकेगा। इसके बजाय, यह टेराफॉर्म द्वारा की जाने वाली क्रियाओं को समायोजित करता है _जब_ यह संसाधन इंस्टेंस को नष्ट कर देता है।)

apparentlymart 20 फ़र॰ 2018

👍3

सभी 8 टिप्पणियाँ

apparentlymart 20 फ़र॰ 2018

👍3

@apparentlymart मैंने #10 में एक संकल्प का प्रयास किया है, कोई भी प्रतिक्रिया लेने में खुशी हुई।

abn 31 मार्च 2018

नमस्ते,
वही उपयोग का मामला और @alanbchristie जैसा ही मुद्दा। इस टिकट के बारे में कोई अपडेट? अग्रिम में धन्यवाद।

MOURIK 9 अप्रैल 2020

आपके धैर्य के लिए धन्यवाद @abn जबकि हम हाशीकॉर्प प्रदाताओं के लिए अपनी ट्राइएज प्रक्रिया में सुधार करते हैं। मैं यहां आपके उपयोग के मामले के बारे में अधिक समझना चाहता हूं: चूंकि आप terraform destroy पर कॉल कर रहे हैं लेकिन इस संसाधन को संरक्षित करना चाहते हैं, यह अतिरिक्त प्रकार के संसाधनों के साथ एक बड़े कॉन्फ़िगरेशन का हिस्सा होना चाहिए जिसे आप नष्ट करना चाहते हैं। क्या आप इस प्रक्रिया के चरणों को रेखांकित कर सकते हैं और कॉन्फ़िगरेशन का उपयोग कैसे किया जाता है?

kmoe 7 अग॰ 2020

@kmoe ईमानदार होने के लिए, मूल उपयोग के मामले की मेरी याददाश्त थोड़ी कमजोर है। लेकिन, जैसा कि विवरण में कहा गया है, विशेष मामला यह था कि हमने एडब्ल्यूएस पर कुछ संसाधन बनाए थे जो टोकन और/या कॉन्फ़िगरेशन उत्पन्न करते थे जिन्हें संसाधनों को साफ करने के लिए उपयोग करने की आवश्यकता होती थी, जिन्हें पोस्ट-अप्लाई के बाहर बनाया गया था। tf राज्य, जिसे नष्ट करने के बाद एक उत्तरदायी प्लेबुक का उपयोग करके साफ करने की आवश्यकता थी, कहा जाता था। साधारण आवश्यकता यह है कि जेनरेट की गई फ़ाइल को मिटाने में सक्षम न हो; ऐसे कई अन्य मामले हैं जहां यह सामान्य रूप से काम आएगा।

abn 7 अग॰ 2020

मेरा भी यही विचार है

HaveFun83 7 जून 2021

यहाँ अभी भी वही चाहिए

crazychatting 26 अक्तू॰ 2021

मुझे यह कहना अच्छा लगेगा कि मुझे अभी भी इस समस्या में दिलचस्पी है, लेकिन मैं नहीं हूं। इसके बजाय, जैसा कि इस मुद्दे की शुरुआत में संकेत दिया गया है, मैं एक नियंत्रक के रूप में Ansible का उपयोग करता हूं, इसलिए बुनियादी ढांचे के प्रावधान के बाद मैं फ़ाइल को टेराफॉर्म के रास्ते से कॉपी कर लेता हूं। फिर, जब मैं नष्ट कर देता हूं, जब नियंत्रण मेरी उत्तरदायी प्लेबुक पर वापस आ जाता है, तो मेरे पास इसे हटाने से पहले फ़ाइल होती है और आवश्यक प्रसंस्करण कर सकती है।

2020 में पहले के प्रश्न के संबंध में कोई ऐसी फाइल क्यों रखना चाहेगा? अन्य संसाधनों के विपरीत तथ्य यह है कि यह एक "स्थानीय" संसाधन है, यह संकेत देना चाहिए कि यह आम तौर पर बुनियादी ढांचे के भीतर एक महत्वपूर्ण भूमिका नहीं निभाता apply ...

वैसे भी - बाहरी उपकरण का उपयोग करके व्यवहार के आसपास कोड करना मेरे लिए अधिक उत्पादक रहा है।

alanbchristie 27 अक्तू॰ 2021

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Terraform-provider-local: नष्ट होने पर local_file को संरक्षित करने की क्षमता जोड़ें

टेराफॉर्म संस्करण

टेराफॉर्म कॉन्फ़िगरेशन फ़ाइलें

डीबग आउटपुट

क्रैश आउटपुट

अपेक्षित् व्यवहार

वास्तविक व्यवहार

प्रजनन के चरण

अतिरिक्त संदर्भ

संदर्भ

सबसे उपयोगी टिप्पणी

सभी 8 टिप्पणियाँ

संबंधित मुद्दों