Terraform-provider-local: أضف القدرة على الحفاظ على ملف local_file عند التدمير

مرحباalanbchristie! شكرًا لطلب الميزة هذا ونأسف للتأخير في الرد عليه.

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

هناك بعض السوابق لخيارات مثل هذه للموارد حيث يكون من الشائع استخدام Terraform لإنشائها ولكن لتمرير الإدارة إلى نظام آخر بعد فترة. عادةً ما يكون لهذه الأسماء أسماء مثل verb_on_destroy ، حيث "فعل" هو بعض المصطلحات المناسبة للمورد المعني. في هذه الحالة ، أقترح تسمية الوسيطة delete_on_destroy ، بحيث تكون افتراضيًا على true ، وبعد ذلك يكون التكوين الصريح هو delete_on_destroy = false . يتوافق هذا مع الميزات الأخرى المشابهة الموجودة مثل الوسيطة nomad_job deregister_on_destroy .

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

apparentlymart لقد حاولت الحصول على حل في رقم 10 ، ويسعدني تلقي أي ملاحظات.

أهلا،
نفس حالة الاستخدام ونفس المشكلة مثل @ alanbchristie. أي تحديث regading هذه التذكرة؟ شكرا مقدما.

نشكرك على سعة صدرك abn أثناء قيامنا بتحسين عملية الفرز الخاصة بنا لموفري HashiCorp. أود أن أفهم المزيد عن حالة الاستخدام الخاصة بك هنا: نظرًا لأنك تتصل بـ terraform destroy ولكنك تريد الحفاظ على هذا المورد ، يجب أن يكون جزءًا من تكوين أكبر مع أنواع إضافية من الموارد التي تريد تدميرها. هل يمكنك تحديد خطوات هذه العملية وكيف يتم استخدام التكوين؟

kmoe لأكون صادقًا ، فإن ذاكرتي لحالة الاستخدام الأصلية رديئة بعض الشيء. ولكن ، كما يقول الوصف ، كانت الحالة المعينة التي أدت إلى ذلك منذ أن أنشأنا بعض الموارد على AWS التي أنشأت الرموز و / أو التكوينات التي يجب استخدامها لتنظيف الموارد التي تم إنشاؤها بعد التقديم خارج حالة tf ، التي كانت بحاجة إلى التنظيف باستخدام كتاب لعب غير صالح بعد استدعاء التدمير. الشرط البسيط هو أن تكون قادرًا على عدم حذف ملف تم إنشاؤه ؛ هناك العديد من الحالات الأخرى التي يكون فيها هذا مفيدًا بشكل عام.

نفس الشيء هنا

لا يزال هو نفسه المطلوب هنا

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

فيما يتعلق بالسؤال السابق في عام 2020 لماذا قد يرغب أي شخص في الاحتفاظ بمثل هذا الملف؟ على عكس الموارد الأخرى ، يجب أن تشير حقيقة أنه مورد "محلي" إلى أنه لا يلعب دورًا حاسمًا في البنية التحتية ... فهو "محلي" في النهاية (وستتم إعادة كتابته على أي حال عند تشغيل apply ). وربما حقيقة أن ثلاثة آخرين يعتقدون أيضًا أن هذه فكرة جيدة قد تشير أيضًا إلى أنه ربما يكون كذلك؟

على أي حال - كان الأمر أكثر إنتاجية بالنسبة لي أن أكتب حول السلوك باستخدام أداة خارجية.