Terraform-provider-aws: Permintaan Fitur: Berhenti, jangan hancurkan instance pada pembaruan data pengguna

_Komentar ini awalnya dibuka oleh @JeanMertz sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -100605772. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Ini menarik. Saya tidak berpikir Terraform saat ini memiliki siklus berhenti/mulai, hanya menghancurkan atau tidak menghancurkan.

Saya dapat melihat banyak nilai untuk kasus penggunaan ini (karena kami juga menggunakan banyak data pengguna), tetapi saya juga dapat melihat ini menjadi rumit.

Jika saya tidak salah, pada AWS sebuah instance tanpa perangkat penyimpanan yang didukung EBS hanya akan mengatur ulang penyimpanan, jadi dalam hal ini penghentian/mulai akan memiliki hasil yang sama dengan penghancuran.

Berikut daftar properti yang AWS izinkan Anda ubah dalam keadaan berhenti:

Anda dapat mengubah atribut berikut dari sebuah instance hanya ketika dihentikan:

• Jenis instans
• Data pengguna
• Inti
• disk RAM

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -101095776. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Jadi masalah khusus ini bukan masalah dengan GCE karena Anda dapat memperbarui metadata tanpa forceNew. Namun ada masalah serupa jika Anda ingin mengubah zona / cakupan tanpa kehilangan data di disk Anda.

Cara saya melakukan ini adalah dengan menggunakan sumber daya disk terpisah dalam situasi apa pun di mana konten disk berharga dalam beberapa hal. Misalnya jelas untuk database ini benar, tetapi biasanya dalam sebuah node dari cluster beban seimbang disk dibuang. Memiliki disk terpisah memungkinkan Terraform untuk membuat ulang instance tanpa kehilangan disk (karena disk tidak dibuat ulang). Saya percaya ini setara dengan siklus reboot.

_Komentar ini awalnya dibuka oleh @Pryz sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -138493574. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Bagaimana dengan tidak melakukan apa-apa saat kami memperbarui user_data ?

Jika Anda menggunakan Terraform dan solusi manajemen konfigurasi, sebagian besar waktu data pengguna hanya untuk bootstrap contoh. Jadi, ketika Anda mengubah data pengguna, itu mungkin hanya untuk instance baru, bukan yang sekarang.

_Komentar ini awalnya dibuka oleh @jwaldrip sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -138559228. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Tidak setuju. Saya menggunakan CoreOS dalam produksi dan mengelola semuanya dengan data pengguna. Bahkan contoh yang ada.

_Komentar ini awalnya dibuka oleh @Pryz sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -138591063. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Ok, jadi bagaimana dengan argumen untuk menentukan strategi? (Reboot, Buat Ulang, Tidak Ada)

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -138654976. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Demi perbandingan: Untuk metadata instance komputasi google, kami memulai dengan metadata yang dapat diperbarui (yaitu jangan membuat ulang instance, tetapi perbarui metadata sehingga instance dapat melihat nilai baru). Ini sebenarnya sangat berguna karena Anda dapat melakukan hang get di server metadata yang berarti Anda dapat menjalankan agen di VM Anda yang mendapat pemberitahuan tentang perubahan pada metadata. Ini memungkinkan Anda untuk mengontrol VM (misalnya meluncurkan perangkat lunak aplikasi baru) dengan memperbarui metadata. Saya tidak tahu apakah AWS mengizinkan Anda melakukan itu, tetapi saya menganggap itu benar-benar berguna.

Namun jika Anda tidak memiliki agen seperti itu, dan satu-satunya hal yang harus Anda tangani (jika Anda ingin melakukan konfigurasi simpul yang benar-benar deklaratif) adalah skrip startup (data pengguna di AWS), maka Anda ingin mengubah skrip startup menjadi buat ulang instance sehingga akan menjalankan kembali skrip startup. Bagi banyak orang, terutama server tanpa kewarganegaraan, itu sudah cukup baik. Satu-satunya biaya adalah waktu yang dibutuhkan untuk membuat ulang instans (agennya seketika).

Jadi, saya menambahkan bidang metadata_startup_script di instance google yang sama dengan metadata.startup-script kecuali ForceNew. Seseorang tidak diperbolehkan untuk menentukan keduanya. Oleh karena itu, pengguna dapat memilih apakah akan memiliki perilaku ForceNew atau tidak.

Anda dapat melakukan hal yang sama untuk aws_instance: Memiliki bidang updateable_user_data yang bukan ForceNew untuk memungkinkan orang membuat perubahan tanpa membuat ulang instance dan menjalankan agen di dalam VM untuk mengambil perubahan ini. Dan simpan bidang user_data saat ini untuk kasus non-agen sederhana.

_Komentar ini awalnya dibuka oleh @Pryz sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -138859642. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya suka gagasan memiliki dua bidang user_data yang berbeda karena ini untuk dua cara yang sama sekali berbeda untuk mengelola instance.

_Komentar ini awalnya dibuka oleh @FergusNelson sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -149802063. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya pikir akan menyenangkan untuk menghentikan dan memulai opsi baris perintah secara umum. Kasus penggunaan akan menjadi lingkungan pementasan atau pengujian yang tidak diperlukan sepanjang waktu; daripada merusak dan menciptakan kembali lingkungan setiap kali dibutuhkan, alangkah baiknya jika bisa melakukannya

terraform stop
terraform start

Dan minta terraform memulai mesin dalam urutan yang benar sehubungan dengan grafik ketergantungan.

_Komentar ini awalnya dibuka oleh @c4milo sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -150636511. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Sejauh yang saya pahami, satu-satunya tujuan skrip cloud-init atau data pengguna adalah untuk melakukan inisialisasi awal instance. Dari perspektif itu, mungkin tidak masuk akal untuk menggunakannya sebagai cara untuk menyediakan kembali atau mengonfigurasi ulang instance karena untuk itulah alat seperti Wayang, Koki, Ansiable, dan Garam. Terraform dianggap sebagai cara untuk menciptakan dan menghancurkan sumber daya infrastruktur, dan kekekalan sumber daya ada di mana-mana. Mungkin @mitchellh dapat menjelaskan lebih banyak di sini.

_Komentar ini awalnya dibuka oleh @jwaldrip sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -150648445. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Tentu, ini adalah kasus dalam beberapa kasus. Tetapi dalam kasus kami, kami menggunakan core-os
dan gunakan data pengguna untuk mem-bootstrap mesin. Kami TIDAK PERNAH menggunakan boneka, koki,
garam dll, untuk membuat instance lebih jauh. Mungkin ini buruk
praktik, tetapi saya tahu bahwa data pengguna dapat berubah. Selain itu kami
tidak dapat menghancurkan instance etcd kami untuk menyediakan data pengguna baru seperti yang kami inginkan
memiliki risiko kehilangan kuorom.

Pada Jumat, 23 Okt 2015 jam 11:13, Camilo Aguilar [email protected]
menulis:

Sejauh yang saya pahami, satu-satunya tujuan skrip cloud-init atau data pengguna
adalah melakukan inisialisasi awal instance. Dari perspektif itu, mungkin—
tidak masuk akal untuk menggunakannya sebagai cara untuk menyediakan kembali atau mengonfigurasi ulang instance
karena untuk itulah alat-alat seperti Wayang, Koki, Ansiable, dan Garam.
Terraform dianggap sebagai cara untuk menciptakan dan menghancurkan
sumber daya infrastruktur dan kekekalan sumber daya ada di mana-mana.
Mungkin @mitchellh https://github.com/mitchellh bisa menumpahkan lagi
cahaya di sini.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/hashicorp/terraform/issues/1887#issuecomment -150636511
.

Jason Waldrip
m: 646-460-5959
e: [email protected]
http://www.facebook.com/jason.waldrip
http://www.linkedin.com/in/jasonwaldrip

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -150649603. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Ini bukan praktik yang buruk, ini bekerja dengan sangat baik dan semakin umum.

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -150662423. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Apakah Anda mencoba menggunakan sumber daya disk terpisah? Jika Anda juga menggunakan ip yang ditetapkan secara statis maka saya pikir itu harus setara dengan reboot?

_Komentar ini awalnya dibuka oleh @JamiKarvanen sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -152194919. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya memiliki kasus penggunaan yang sama dengan @jwaldrip. Saat menggunakan CloudFormation AWS, itu memperbarui user_data tetapi tidak membuat ulang atau mem-boot ulang instans. Amazon menyediakan skrip cnf-hup yang mendeteksi perubahan user_data dalam instans dan memperbaruinya sesuai dengan itu, jadi akan sangat bagus jika hanya memperbarui user_data dengan terraform dan membiarkan AWS menangani pembaruan.

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -152232461. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Meningkatkan ke "Ini bukan praktik yang buruk, ini bekerja dengan sangat baik, semakin umum, dan secara aktif didorong oleh AWS dan Google" :)

_Komentar ini awalnya dibuka oleh @manojlds sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -165428494. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Tidak ada gerakan ini?

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -168040430. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya pikir itu harus menjadi PR yang cukup mudah untuk menambahkan atribut sumber daya baru untuk mengontrol data pengguna dengan cara yang tidak baru. Jika seseorang memiliki motivasi yang sesuai :)

_Komentar ini awalnya dibuka oleh @yogin sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -191015474. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya akan sangat tertarik dengan cara untuk mencegah instance dibuat ulang ketika ada perubahan pada data pengguna. Saya mengerti beberapa orang menggunakannya untuk tujuan yang berbeda, dan saya menyukai ide untuk menentukan strategi (membuat ulang, tidak ada, ...).

Dalam kasus kami, kami hanya menggunakan userdata untuk mem-bootstrap instance baru, nanti, chef akan mengambil alih dan melakukan sisanya, tetapi kadang-kadang template userdata mungkin mendapatkan pembaruan kecil, dan jika saya dapat menghindari keharusan membuat ulang instance, itu akan menjadi luar biasa!

_Komentar ini awalnya dibuka oleh @mcortinas sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -198468223. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Tidak ada gerakan ini?

_Komentar ini awalnya dibuka oleh @modax sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -219944854. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya bukan pengembang terraform tetapi saya telah melihat sekilas kode terraform saat ini dan tampaknya satu-satunya solusi yang mungkin tanpa perubahan inti terraform (besar) dapat menambahkan atribut lain seperti live_user_data (karena nilai ForceNew tidak dapat bergantung pada konteks sejauh ini seperti yang bisa dikatakan). Kode mungkin masih berakhir berantakan karena dua atribut memodifikasi hal yang sama (berkenaan dengan perhitungan diff). Oleh karena itu saya tidak yakin apakah tim terraform akan menerima PR seperti itu.

_Komentar ini awalnya dibuka oleh @sparkprime sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -220068197. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

@modax Seperti yang saya katakan lebih lanjut di utas, inilah yang dilakukan google_compute_instance dan berfungsi dengan baik

_Komentar ini awalnya dibuka oleh @markmaas sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -224507714. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Menghancurkan dan membuat ulang instance ketika data pengguna berubah membuatnya jadi saya bisa:

• Tidak menggunakan data pengguna (Dan karenanya cloud-config)
• Tidak menggunakan Terraform (Artinya saya harus belajar cloud-formation: ugh)

Karena cloud-config semakin banyak digunakan untuk melakukan bootstrap awal sebuah instance, saya akan berpikir ini bukan lagi "penyempurnaan" tetapi lebih seperti "pemblokiran"

_Komentar ini awalnya dibuka oleh @cheungpat sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -224561306. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Jika Anda tidak ingin instance Anda dibuat ulang saat user-data berubah, Anda dapat mencoba memasukkan kunci ini di ignore_changes .

_Komentar ini awalnya dibuka oleh @br0ch0n sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -233416285. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya setuju dengan @cheungpat bahwa abaikan_perubahan mungkin menangani tiket ini (setelah #5627 selesai)

_Komentar ini awalnya dibuka oleh @gdubicki sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -263675038. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Saya mengonfirmasi bahwa apa yang disarankan @cheungpat adalah solusi yang baik. Jika Anda menggunakan penyedia GCE, maka untuk mengabaikan perubahan skrip startup gunakan kode ini:

lifecycle {
  ignore_changes = ["metadata_startup_script"]
}

Tetapi akan lebih baik jika Anda dapat menyetelnya sekali, secara global - tidak di setiap sumber daya bertipe google_compute_instance . Apakah itu mungkin?

UPDATE: AFAIK itu tidak mungkin dan Anda bahkan tidak dapat menggunakan variabel untuk mengatur ignore_changes . :( Lihat #10730.

_Komentar ini awalnya dibuka oleh @kirkmadera sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -264654270. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Ini juga berlaku untuk mengubah ukuran instans AWS. Kami akhirnya masuk ke admin AWS, menghentikan instance, mengubah jenis instance, lalu memulainya lagi. Kemudian kami memperbarui konfigurasi terraform agar sesuai dengan jenis instans baru dan menjalankan terraform apply yang menyinkronkan status terraform ke ukuran baru.

Idealnya kita hanya akan mengubah ukuran dari Terraform. Mengubah ukuran server AWS juga mengubah ip publik dan pribadinya. Menjalankan pengubahan ukuran dari terraform akan memungkinkan kita untuk segera mengubah DNS juga jika diperlukan, daripada menunggu kita menjalankan terraform setelah pengubahan ukuran selesai.

_Komentar ini awalnya dibuka oleh @stack72 sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -282127593. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Teman-teman terkasih, sekarang saya telah menangani masalah perubahan instance_type dan itu akan menjadi bagian dari terraform 0.8.8, saya akan mulai membuat prototipe ini

paul

_Komentar ini awalnya dibuka oleh @cnoffsin sebagai https://github.com/hashicorp/terraform/issues/1887#issuecomment -294035120. Itu dimigrasikan ke sini sebagai bagian dari pemisahan penyedia . Komentar asli ada di bawah._

Kasus penggunaan bagi saya di sini adalah saya harus membuat perubahan tipe di AWS ke cluster cloudera.

Para insinyur mematikannya dengan anggun sehingga saya bisa membuat perubahan.

Saya ingin mengubah jenisnya, tetapi TINGGALKAN. Sehingga mereka dapat membawa mereka dalam urutan yang tepat.

Ada berita tentang permintaan fitur ini? Saya berada di posisi yang sama dan fitur ini (berhenti/mulai saat mengubah data pengguna di AWS) akan banyak mengurangi pola penerapan panas kami.

Jika saya mengerti dengan benar maka TL;DR sejauh ini adalah ini:

Menggunakan ignore_changes (meskipun baik untuk diperhatikan) tidak memenuhi kasus penggunaan Terraform yang benar-benar mengelola user_data dari sumber daya yang ada tanpa membuatnya kembali. Dengan kata lain, alur kerja yang diinginkan adalah "berhenti, perbarui, mulai" alih-alih "hancurkan, perbarui, buat".

Dengan ignore_changes = ["user_data"] , jika konten user_data berubah maka TF mengabaikannya -- yang akan baik-baik saja untuk host yang hanya menggunakan user_data untuk penyediaan pada boot pertama. Tetapi jika user_data adalah mekanisme Anda untuk memperbarui konfigurasi host yang sedang berjalan (dan memulai ulang alih-alih membuat ulang) maka perubahan tidak akan didorong.

Apakah saya benar bahwa pemblokir utama adalah Terraform tidak (AFAIK) saat ini mendukung pengelolaan status naik/turun dari instans EC2 (untuk mencapai "berhenti, perbarui, mulai")?

Tujuan akhir dari ini bagi saya adalah untuk dapat mengubah tipe instans EC2 dan membuat Terraform memodifikasinya alih-alih menghancurkan dan membangunnya kembali. Saya yakin versi terbaru sudah melakukan ini.

Saya membutuhkannya.

Ini akan menyenangkan

Saya ingin memberikan suara saya. Harap berhenti menandai sumber daya ini sebagai diubah. Jika Anda benar-benar harus melakukannya, Anda dapat menggunakan atribut untuk mengaktifkan perilaku ini, tetapi saya berpendapat bahwa pengguna dapat dengan sengaja mencemari sumber daya jika mereka perlu mengubahnya. Seperti biasa, ini tentang bekerja di sekitar manusia, meskipun saya menyukai kekakuan, saya telah menemukannya rusak ketika pekerjaan didistribusikan dan beberapa bulan telah berlalu. Anda mempelajari atau mengubah banyak hal, dan ingin menyesuaikan kode yang sesuai, mungkin sesuatu yang 100% diverifikasi menggunakan simpul yang berbeda, tetapi jadwalkan perubahan di kemudian hari. Saat ini strategi kami adalah meninggalkan blok komentar yang besar, tetapi rasanya berantakan.

FWIW, saya membutuhkan sesuatu yang serupa dan berakhir dengan skrip ini untuk menghentikan instance dan melakukan apa yang kami butuhkan di luar terraform. Mungkin membantu seseorang dari google berakhir di sini untuk aws.

terraform apply -auto-approve \
    -var "instance_name=${INSTANCENAME}" \
    -var "environment=${DEPLOY_ENV}" \
    -var "security_group=sg-0a9cf274" \
    -var "ami_name=${AMINAME}" \
    -var "vpc_id=${VPCID}" \
    -var "keypair_name=bastion.${DEPLOY_ENV}"

....................

INSTANCEID=`aws ec2 describe-instances --filters "Name=tag:Name,Values=${INSTANCENAME}" \
            --query "Reservations[0].Instances[0].InstanceId" --output text | tail -1`

if [[ "${INSTANCEID}" == "" ]]; then
    echo "There was a problem getting instance id from AWS. Exiting."
    exit 1
fi

aws ec2 stop-instances --instance-ids ${INSTANCEID}

Tidak yakin bagaimana komentar saya menambah diskusi, tetapi saya menemukan masalah ini setelah terkena perubahan user_data . Tampaknya entah bagaimana berubah "dari luar" (?), AWS melakukan sesuatu dalam semalam mungkin? Tidak tahu.

Saya tidak menggunakan atau bergantung pada user_data Saya tidak mendeklarasikannya di bawah sumber daya aws_inctance saya dll. Semuanya berfungsi dengan baik ( terraform plan dan status jarak jauh). Saya belum melakukan pembaruan apa pun pada terraform atau penyedia. Setelah menjalankan terraform plan Hari ini sebagian besar EC2 saya ditandai untuk dibuat ulang karena perubahan user_data . Bahkan beberapa EC2 yang dihentikan ️

Saya akhirnya melakukan ignore_changes , tetapi tetap tidak mengerti apa yang terjadi.

@rmldsky kedengarannya menakutkan. silakan ajukan masalah/bug terpisah, dan rujuk yang ini.

Harap dicatat bahwa saat ini ada 46 suara untuk masalah ini di https://github.com/hashicorp/terraform/issues/1887

Semoga bermanfaat, apakah kami memiliki informasi terkini tentang yang satu ini?

Bagaimana ini masih tidak apa-apa? Ini adalah salah satu dari sedikit tempat di mana CloudFormation jauh lebih unggul daripada Terraform. Perubahan data pengguna TIDAK memerlukan penghancuran sebuah instance dan Terraform harus diperbarui agar kesalahan di sisi non-penghancuran.

Saya memiliki masalah yang sama di sini - use case:
Kami memiliki sejumlah sistem yang dihentikan/dimulai pada jadwal otomatis (berdasarkan tag) dan kami menggunakan <persist>true</persist> untuk memungkinkan data pengguna berjalan pada setiap boot tersebut untuk melakukan berbagai tugas. Jika kita perlu menambah, menghapus, atau menyesuaikan tugas-tugas itu, maka diperlukan pembaruan data pengguna. Saat ini jika kita melakukan ini melalui Terraform (tanpa interaksi manual) instance ditandai untuk dihancurkan seperti yang disebutkan di atas.

Pekerjaan manual adalah memperbarui data pengguna sendiri di luar terraform dan kemudian pada penerapan/rencana berikutnya keadaan akan cocok, tidak memerlukan penghancuran. Ini membosankan dan memakan waktu di banyak contoh, terutama jika Anda menggunakan penyedia template untuk mengisi nilai di data pengguna (kami melakukannya..) karena Anda juga harus membuat skrip nilai tersebut untuk diisi atau menyesuaikan secara manual sebelum menerapkan ke setiap contoh .

Saya akan berpikir ini harus bekerja mirip dengan jenis contoh perubahan seperti yang disebutkan di atas - hentikan contoh (jika berjalan), ubah data pengguna, mulai contoh (jika itu berjalan sebelum perubahan).

Ada pembaruan tentang ini? Apakah ada yang bisa kita lakukan untuk bergerak maju dengan masalah ini?

Mengapa Anda tidak bisa menggunakan opsi lifecycle { ignore_changes = [ what-to-ignore ] } ?
https://www.terraform.io/docs/configuration/resources.html#ignore_changes

@Andor karena kami ingin menerapkan pembaruan data pengguna. Pembaruan tidak perlu menghancurkan instance.

@et304383 apakah Anda yakin itu akan berhasil? Karena data pengguna (sejauh yang saya tahu) hanya digunakan untuk inisialisasi misalnya dan tidak lebih.

Intinya adalah memperbarui data pengguna didukung tanpa menghapus instance (itu hanya harus dihentikan selama pembaruan). Terraform harus mendukung ini seperti CloudFormation.

Saya setuju dengan @et304383. Data pengguna dievaluasi oleh cloud-init pada _setiap_ boot dan dimungkinkan untuk memperbaruinya saat host dihentikan. Jarang yang berguna di luar boot _first_ tetapi ada beberapa kasus penggunaan (misalnya konfigurasi runtime vyos).

@boweeb itu tidak benar. Ini hanya berjalan pada peluncuran pertama. Ini akan berjalan jika Anda membuat instance baru melalui AMI untuk Linux, dan hanya untuk Windows jika Anda menjadwalkannya untuk dijalankan sebelum membuat AMI:

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html#user -data-execution

@et304383 terima kasih telah mengemukakannya, ini harus diklarifikasi. Anda benar: Windows tidak menjalankan cloud-init pada setiap boot. Ini adalah masalah khusus implementasi.

Pada setidaknya sebagian besar AMI Linux (RedHat/CentOS dan Amazon Linux dikonfirmasi), cloud-init dikonfigurasi untuk berjalan pada setiap boot dan mengevaluasi langkah apa yang perlu dijalankan. Misalnya, runcmd berjalan pada boot pertama saja dan bootcmd berjalan (agak di awal proses boot) pada _setiap_ boot.

https://cloudinit.readthedocs.io/en/latest/topics/examples.html#run -commands-on-first-boot

Ya. Fokus di sini adalah bahwa data pengguna hanya berjalan satu kali. Memperbaruinya pada instance yang ada tidak memicu eksekusinya.

Ringkasan/Catatan dari atas -

• AWS API mendukung pembaruan data pengguna (ketika instans dalam keadaan berhenti)
• Pembaruan instans AWS lainnya mendukung penghentian, pembaruan, dan memulai instans, contoh: tipe instans
• Data pengguna instans dapat dinamis menggunakan data dari fungsi status/tfvars dan template TF. Ini membuat pembaruan secara manual melalui API/GUI jauh lebih sulit karena jumlah instance bertambah.
• Baik Windows dan Linux mampu dikonfigurasi untuk menjalankan data pengguna pada setiap peluncuran atau saat dijadwalkan. Ada kompleksitas dan pekerjaan yang diperlukan tetapi mungkin untuk keduanya.
• Ada berbagai gaya penerapan dan beberapa termasuk menggunakan data pengguna untuk lebih dari inisialisasi peluncuran pertama (peluncuran multi-boot, pembaruan saat peluncuran (OS, AV), beri tahu/tindakan saat peluncuran). Meskipun ini bersifat situasional, ini masih merupakan fitur AWS yang didukung dan didokumentasikan.

Mengingat hal di atas, apakah tidak masuk akal untuk memasukkan fungsi ini ke dalam penyedia?

Karena ada beberapa kasus penggunaan, ini dapat diimplementasikan dengan argumen tambahan, seperti:
'user_data_update_action'
Contoh opsi: reboot, buat ulang, abaikan

Untuk mempertahankan fungsionalitas saat ini, ini dapat menjadi default untuk 'membuat ulang' dan kemudian mengizinkan mereka yang membutuhkannya untuk menyesuaikan dari sana.

@phinze , @bflad , atau siapa pun di Hashicorp, bisakah Anda melakukan ping ke seseorang secara internal untuk melihat ini. Sudah buka hampir 2 tahun...

Ini akan sangat berguna bagi saya juga.

++^
Ini akan sangat membantu. Saat ini saya memiliki masalah ini dan saya perlu perbaikan sehingga tidak merusak server direktori yang saya butuhkan.
Saya juga tidak yakin bagaimana data pengguna tidak sinkron.

Ya. Fokus di sini adalah bahwa data pengguna hanya berjalan satu kali. Memperbaruinya pada instance yang ada tidak memicu eksekusinya.

Ini tidak sepenuhnya benar. Untuk memahami alasannya, penting untuk mempertimbangkan perbedaan antara data pengguna, dan apa yang _dilakukan_ oleh gambar tertentu dengan data pengguna. Ini berlaku di banyak cloud yang berbeda, bukan hanya AWS.

Di AWS, saat Anda menentukan data pengguna, data tersebut akan tersedia di titik akhir metadata untuk instans. Fakta bahwa cloudinit tidak menanggapi pembaruan sepenuhnya ortogonal dengan kemampuan untuk memperbarui konfigurasi ini di penyedia - ada banyak gambar yang digunakan yang tidak menggunakan cloudinit sama sekali, dan sebaliknya meneruskan jenis data konfigurasi lainnya melalui data pengguna. Salah satu contohnya adalah gambar Windows modern, yang menggunakan ec2config alih-alih cloudinit.

_Namun_, Terraform tidak memiliki konsep dan pembaruan yang memerlukan restart sumber daya dalam konteks ini - tetapi mungkin harus belajar melakukannya dan memungkinkan memilih di tempat yang masuk akal.

Saya kira itu adil, tetapi maksud saya adalah bahwa admin mengetahui konteks ini dan mungkin hanya ingin merekam perubahan yang dimaksudkan untuk permintaan instance berikutnya, tetapi saya sudah mulai menggunakan aturan siklus hidup untuk mengabaikan perubahan ini, yang sesuai dengan penggunaan saya kasus. Pada titik ini, saya lebih suka Anda semua fokus untuk membersihkan backlog Anda.

Apakah PR untuk menambahkan sumber daya aws_instance_user_data yang berbeda kemungkinan akan diterima?

Memperbarui instance_type (yang juga memerlukan siklus stop-update-start serupa) telah didukung untuk sementara waktu: https://github.com/terraform-providers/terraform-provider-aws/issues/4838

Bisakah kita mengadopsi solusi serupa di sini? Kami harus merancang cara berbeda dalam memperbarui konfigurasi instans (melalui lampiran Dokumen SSM), sebagian besar karena keterbatasan ini di Terraform untuk user_data .

EDIT: untuk konteksnya, kami memiliki aplikasi berpemilik pihak ketiga yang harus melewati beberapa konfigurasi instance melalui user_data , dan itu membuat pembaruan apa pun pada konfigurasi ini sangat bermasalah. Aplikasi ini juga tidak dapat mentolerir penggantian instans, karena terkait dengan ID instans tertentu untuk aktivasi lisensi..

Ya. Fokus di sini adalah bahwa data pengguna hanya berjalan satu kali. Memperbaruinya pada instance yang ada tidak memicu eksekusinya.

Pernyataan ini tidak benar di AWS. Dimungkinkan untuk menambahkan tag persist , yang memastikan bahwa data pengguna dijalankan pada setiap boot.

Contoh data pengguna dengan tag persist :

<script>
net start codedeployagent
net start AmazonCloudWatchAgent
</script>
<persist>true</persist>