Terraform-provider-local: 破棄時にlocal_fileを保持する機能を追加します

こんにちは@alanbchristie！ この機能のリクエストに感謝し、応答が遅れて申し訳ありません。

HashiCorpのTerraformチームは、他の場所に焦点を当てているため、近い将来これに取り組むことができなくなりますが、あなたまたは他の誰かがそれを実装する時間と動機を持っている場合は、プルリクエストを確認できます。

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と同じユースケースと同じ問題。 このチケットを再評価する更新はありますか？ 前もって感謝します。

HashiCorpプロバイダーのトリアージプロセスを改善する間、@abnにご理解いただきありがとうございます。 ここであなたのユースケースについてもっと理解したいと思いますterraform destroyを呼び出しているが、このリソースを保持したいので、破棄したい追加の種類のリソースを含むより大きな構成の一部である必要があります。 このプロセスの手順と、構成の使用方法の概要を教えてください。

@kmoe正直なところ、元のユースケースの私の記憶は少し見苦しいです。 ただし、説明にあるように、これにつながる特定のケースは、AWSでいくつかのリソースを作成し、適用後に作成されたリソースをクリーンアップするために使用する必要のあるトークンや構成を生成したためです。 tf状態。destroyが呼び出された後、ansibleプレイブックを使用してクリーンアップする必要がありました。 単純な要件は、生成されたファイルを削除できないようにすることです。 これが一般的に役立つ他のさまざまなケースがあります。

こっちも一緒

ここでも同じことが必要です

私はまだこの問題に興味があると言いたいのですが、そうではありません。 代わりに、問題の冒頭で示したように、私はAnsibleをコントローラーとして使用しているため、インフラストラクチャがプロビジョニングされたら、Terraformの邪魔にならないようにファイルをコピーします。 次に、destroyを呼び出した後、コントロールがAnsibleプレイブックに戻ると、削除する前のファイルがあり、必要な処理を実行できます。

2020年の以前の質問に関して、なぜ誰かがそのようなファイルを保持したいと思うのでしょうか。 他のリソースとは異なり、「ローカル」リソースであるという事実は、通常、インフラストラクチャ内で重要な役割を果たしていないことを示唆しているはずです...結局のところ「ローカル」です（そして、 applyを実行するととにかく書き直されます

とにかく、外部ツールを使用して動作をコーディングする方が生産的です。