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 do_not_destroy в том, что «уничтожение» в этом контексте является операцией Terraform, которая, в свою очередь, вызывает другие операции в целевой системе. на самом деле не предотвратит уничтожение экземпляра ресурса Terraform. Вместо этого он регулирует действия, предпринимаемые Terraform _когда_ он уничтожает экземпляр ресурса.)

@apparentlymart Я попытался решить проблему в № 10, буду рад любым отзывам.

Привет,
Тот же вариант использования и та же проблема, что и у @alanbchristie. какие-либо обновления, касающиеся этого билета? Заранее спасибо.

Спасибо за ваше терпение @abn , пока мы улучшаем наш процесс сортировки для поставщиков HashiCorp. Я хотел бы узнать больше о вашем варианте использования здесь: поскольку вы вызываете terraform destroy , но хотите сохранить этот ресурс, он должен быть частью более крупной конфигурации с дополнительными видами ресурсов, которые вы хотите уничтожить. Не могли бы вы описать шаги этого процесса и как используется конфигурация?

@kmoe Честно говоря, я плохо помню исходный вариант использования. Но, как говорится в описании, конкретный случай, который привел к этому, состоял в том, что мы создали несколько ресурсов на AWS, которые генерировали токены и/или конфигурации, которые необходимо было использовать для очистки ресурсов, которые были созданы после применения за пределами tf, которое нужно было очистить с помощью ansible playbook после вызова destroy. Простое требование состоит в том, чтобы иметь возможность не удалять сгенерированный файл; есть различные другие случаи, когда это вообще пригодится.

то же самое

здесь еще то же самое нужно

Я бы хотел сказать, что меня все еще интересует эта проблема, но это не так. Вместо этого, как было указано в начале статьи, я использую Ansible в качестве контроллера, поэтому я просто копирую файл с пути Terraform после подготовки инфраструктуры. Затем, после того как я вызову команду destroy, когда управление вернется к моему плейбуку Ansible, у меня будет файл до его удаления, и я смогу выполнить необходимую обработку.

Что касается более раннего вопроса, в 2020 году зачем кому-то хранить такой файл? В отличие от других ресурсов тот факт, что это "локальный" ресурс, должен намекать на то, что обычно он не играет решающей роли в инфраструктуре... в конце концов, он "локальный" (и в любом случае будет переписан, когда вы запустите apply ). И, может быть, тот факт, что трое других также считают это хорошей идеей, также может указывать на то, что, возможно, это так?

В любом случае, для меня было более продуктивно кодировать поведение с помощью внешнего инструмента.