Terraform-provider-local: Tambahkan kemampuan untuk melestarikan local_file saat dihancurkan

Dibuat pada 5 Jan 2018 · 8Komentar · Sumber: hashicorp/terraform-provider-local

_Masalah ini awalnya dibuka oleh @alanbchristie sebagai hashicorp/terraform#17040. Itu dimigrasikan ke sini sebagai akibat dari pemisahan penyedia . Isi asli masalah ada di bawah._

Apakah mungkin untuk menambahkan argumen do_not_destroy ke item konfigurasi local_file sehingga ketika terraform destroy dijalankan, file lokal yang dihasilkan dibiarkan utuh? Alasannya? Saya membuat konten dinamis untuk skrip Ansible pasca-penghancuran dan akan berguna untuk menyimpan konten file yang dibuat secara lokal untuk buku pedoman ini.

yaitu apakah dapat diterima untuk memberikan kemampuan untuk melakukan ini ...

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

Dengan di atas jika terraform apply dijalankan ulang tidak apa-apa (dan diharapkan) untuk menimpa file yang ada.

Versi Terraform

Terraform v0.11.1

File Konfigurasi Terraform

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

Keluaran Debug

tidak ada

Keluaran Kerusakan

tidak ada

Perilaku yang Diharapkan

tidak ada

Perilaku Sebenarnya

tidak ada

Langkah-langkah untuk Reproduksi

tidak ada

Konteks Tambahan

tidak ada

Referensi

tidak ada

enhancement

Sumber

hashibot

👍5

Komentar yang paling membantu

Hai @alanbchristie! Terima kasih atas permintaan fitur ini dan maaf atas keterlambatan dalam menanggapinya.

Tim Terraform di HashiCorp tidak akan dapat mengerjakan ini dalam waktu dekat karena fokus kami berada di tempat lain, tetapi kami akan dengan senang hati meninjau permintaan penarikan jika Anda atau orang lain memiliki waktu dan motivasi untuk menerapkannya.

Ada beberapa preseden untuk opsi seperti ini untuk sumber daya di mana biasanya digunakan Terraform untuk membuatnya tetapi untuk meneruskan manajemen ke beberapa sistem lain setelah beberapa saat. Biasanya ini memiliki nama seperti verb_on_destroy , di mana "kata kerja" adalah beberapa terminologi yang cocok untuk sumber yang dimaksud. Untuk situasi ini, saya sarankan untuk menamai argumen delete_on_destroy , dengan default true , dan kemudian memiliki konfigurasi eksplisit menjadi delete_on_destroy = false . Ini konsisten dengan fitur serupa lainnya yang ada seperti argumen nomad_job deregister_on_destroy .

(Alasan dari terminologi *_on_destroy di sini adalah bahwa "menghancurkan" dalam konteks ini adalah operasi Terraform, yang pada gilirannya menyebabkan operasi lain di sistem target. Menyebutnya do_not_destroy dapat membingungkan karena menyetelnya tidak akan benar-benar mencegah Terraform menghancurkan instance sumber daya itu sendiri. Sebaliknya, itu menyesuaikan tindakan yang diambil Terraform _when_ ia menghancurkan instance sumber daya.)

apparentlymart pada 20 Feb 2018

👍3

Semua 8 komentar

Hai @alanbchristie! Terima kasih atas permintaan fitur ini dan maaf atas keterlambatan dalam menanggapinya.

apparentlymart pada 20 Feb 2018

👍3

@apparentlymart Saya telah mencoba resolusi di # 10, dengan senang hati menerima umpan balik.

abn pada 31 Mar 2018

Halo,
Kasus penggunaan yang sama dan masalah yang sama dengan @alanbchristie. ada update tentang tiket ini? Terima kasih sebelumnya.

MOURIK pada 9 Apr 2020

Terima kasih atas kesabaran Anda @abn sementara kami meningkatkan proses triase kami untuk penyedia HashiCorp. Saya ingin memahami lebih lanjut tentang kasus penggunaan Anda di sini: karena Anda memanggil terraform destroy tetapi ingin mempertahankan sumber daya ini, itu harus menjadi bagian dari konfigurasi yang lebih besar dengan jenis sumber daya tambahan yang ingin Anda hancurkan. Bisakah Anda menguraikan langkah-langkah proses ini dan bagaimana konfigurasi digunakan?

kmoe pada 7 Agu 2020

@kmoe Sejujurnya, ingatan saya tentang kasus penggunaan asli agak buruk. Namun, seperti yang dijelaskan dalam deskripsi, kasus khusus yang menyebabkan hal ini adalah karena kami membuat beberapa sumber daya di AWS yang menghasilkan token dan/atau konfigurasi yang perlu digunakan untuk membersihkan sumber daya yang dibuat pasca-pendaftaran di luar tf state, yang perlu dibersihkan menggunakan playbook yang memungkinkan setelah penghancuran dipanggil. Persyaratan sederhananya adalah tidak dapat menghapus file yang dihasilkan; ada berbagai kasus lain di mana ini akan berguna secara umum.

abn pada 7 Agu 2020

sama disini

HaveFun83 pada 7 Jun 2021

masih sama dibutuhkan disini

crazychatting pada 26 Okt 2021

Saya ingin mengatakan bahwa saya masih tertarik dengan masalah ini, tetapi tidak. Sebagai gantinya, seperti yang ditunjukkan di awal masalah, saya menggunakan Ansible sebagai pengontrol jadi saya hanya menyalin file dari cara Terraform setelah infrastruktur disediakan. Kemudian, setelah saya memanggil penghancuran, ketika kontrol beralih kembali ke buku pedoman Ansible saya, saya memiliki file sebelum dihapus dan dapat melakukan pemrosesan yang diperlukan.

Berkenaan dengan pertanyaan sebelumnya pada tahun 2020 mengapa ada orang yang ingin menyimpan file seperti itu? Tidak seperti sumber daya lain, fakta bahwa itu adalah sumber daya "lokal" harus mengisyaratkan bahwa itu biasanya tidak memainkan peran penting dalam infrastruktur ... itu "lokal" setelah semua (dan akan tetap ditulis ulang ketika Anda menjalankan apply ). Dan, mungkin fakta bahwa tiga orang lainnya juga berpikir ini adalah ide yang bagus mungkin juga menunjukkan bahwa, mungkin, memang demikian?

Bagaimanapun - sudah lebih produktif bagi saya untuk mengkodekan perilaku menggunakan alat eksternal.