Ansible-role-nginx-config: Default untuk nginx_main_template tidak ada.*

Setuju banget @alexsegura. Opsi untuk menentukan parameter tunggal ada di backlog. Pengembangan peran sedikit lebih lambat dari yang saya inginkan akhir-akhir ini, tetapi hal-hal akan mulai meningkat lagi dalam beberapa bulan ke depan. Karena itu, jangan ragu untuk mengirimkan PR jika Anda mau

Terima kasih untuk pesan Anda.
Ya, saya dapat menyumbangkan permintaan tarik

Masalah yang saya lihat di sana-sini dalam peran ini, adalah defaultnya di-hardcode.
Jadi jika default berubah, Anda harus ingat untuk mengubah keduanya di defaults/main.yml , dan di templates.

https://github.com/nginxinc/ansible-role-nginx/blob/a92d424bdb5dc51b143c702754bed761e919a576/tasks/conf/upload-config.yml#L8 -L14

Saya kira itu karena ketika menggunakan dicts untuk default, mereka diganti. Ada pengaturan hash_behavior tapi menurut saya itu global.

Apakah Anda tahu cara untuk mengambil vars default "tak tersentuh" ​​untuk sebuah peran?
Sesuatu seperti role_defaults['var_name'] ?

@alexsegura Saya tidak tahu cara yang bagus untuk mencapai perilaku ini. Idealnya, Anda menginginkan pengaturan di mana peran dapat menerapkan konfigurasi yang berguna tanpa menggunakan nilai apa pun di defaults/main.yml .

Pikiran utama yang muncul di benak adalah menggunakan vars/main.yml untuk membuat hardcode beberapa nilai default dan kemudian melakukan sesuatu seperti | default(var_main_upload_src) , tetapi saya tidak yakin itu jalan terbaik ke depan.

Mungkin satu-satunya cara untuk melakukannya adalah dalam template itu sendiri dengan filter default.

Benar, itu adalah solusi yang baik untuk parameter terkait template (dan jika Anda melihat file template, filter default sudah digunakan di beberapa tempat). Dan memang itu akan mengatasi masalah aslinya. Ini akan menjadi tugas yang cukup memakan waktu tetapi bisa dilakukan.

Namun, pertanyaannya tetap tentang apa pendekatan terbaik untuk variabel yang tidak terkait dengan templat, dan terlebih lagi, apakah ada pendekatan terbaik?

Dari apa yang saya lihat di sana-sini, pendekatan terbaik untuk default adalah menghindari penggunaan dicts, mis

nginx_main_template_user: www-data

dari pada

nginx_main_template:
  user: www-data

Itu sebagian akan mengatasi masalah, dan pada awalnya begitulah peran terstruktur. Tetapi ketika saya mulai memperkenalkan opsi templating yang lebih kompleks (mis. beberapa blok lokasi), kamus dan daftar mulai lebih masuk akal.

Atau Anda dapat menggunakan kamus terpisah untuk konfigurasi default dan pengguna dan menggabungkannya dengan filter combine . Saya telah menggunakan peran untuk menyebarkan aliran udara di mana metode ini digunakan:
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
Saya kira ini juga akan menghapus kebutuhan untuk memiliki default hardcoded di template?

Peran yang saya maksud dapat dilihat di sini .

Hm, itu pendekatan yang menarik, dan saya bisa melihatnya berhasil. Mungkin ada baiknya membuat PoC kecil dengan salah satu kamus yang lebih kecil (saya sedang memikirkan template main atau stream ) untuk melihat seberapa baik praktiknya.

Saya sudah mencoba ini untuk templat utama dan berfungsi seperti yang diharapkan. Namun, karena saya menempuh jalan yang paling sedikit berusaha, saya menggabungkan dua kamus nginx_default_main_template dari default dan nginx_user_main_template dari buku pedoman pengguna menjadi nginx_main_template .
Ini akan memperkenalkan perubahan yang melanggar jadi saya akan refactor peran untuk menggunakan kamus gabungan dengan nama baru dan mengirimkan PR.

Template http jauh lebih sulit karena mungkin ada beberapa kamus pengguna untuk digabungkan. Anchor dan alias yang digabungkan dengan operator merge bisa menjadi alternatif tetapi kemudian pengguna bertanggung jawab untuk melakukan merge.
Saya akan menghabiskan beberapa waktu di depan itu juga.

BTW: Apakah ada alasan mengapa Anda memilih untuk menggunakan kamus daripada daftar untuk mendefinisikan beberapa templat http? Dari apa yang saya temukan, kuncinya tidak pernah benar-benar digunakan.

BTW: Apakah ada alasan mengapa Anda memilih untuk menggunakan kamus daripada daftar untuk mendefinisikan beberapa templat http? Dari apa yang saya temukan, kuncinya tidak pernah benar-benar digunakan.

Tidak terlalu. Di belakang saya pikir itu dapat meningkatkan keterbacaan untuk memiliki kunci untuk setiap templat HTTP yang Anda tentukan, tetapi saya tidak menentang mengubahnya ke daftar jika itu membuat segalanya lebih mudah.

Saya mengalami masalah serupa dan kemudian ke masalah ini. Saya ingin menawarkan perspektif alternatif:

Nilai default untuk konfigurasi tidak boleh di-hard-code sama sekali, dan diserahkan kepada perangkat lunak yang sedang diinstal.

Seperti yang sudah ditunjukkan oleh @alexsegura , masalahnya adalah Anda harus menjaga agar nilainya tetap sinkron, yang pada dasarnya tidak akan selalu demikian (manusia rawan kesalahan).

Jika Anda merasa harus menyediakan konfigurasi default, saya sarankan untuk menyimpan sub-bagian dalam direktori terpisah, dan menggabungkannya pada tingkat terendah jika pengguna menentukan nilai, dan kemudian menggabungkannya ke dalam konfigurasi.

Tetapi bahkan itu, imo, tidak berada dalam lingkup peran - itu harus menyalin konfigurasi ke target, dan tidak memastikan bahwa nilainya ok; Paling-paling, saya akan memberikan kesalahan jika perangkat lunak tidak dapat memulai karena kesalahan konfigurasi (atau menggunakan fungsi validasi perangkat lunak, jika tersedia).

Lucunya, saat ini saya sedang mengerjakan cara untuk meningkatkan cara kerja templating dalam peran tersebut. Ini merupakan proses yang sangat lambat (saya memiliki bandwidth yang agak terbatas untuk didedikasikan untuk peran saat ini), tetapi saya pikir saya telah menemukan solusi OK yang akan mengatasi masalah ini. Berharap untuk memiliki perubahan langsung di cabang terpisah dalam beberapa bulan maks

Ada kemajuan dengan masalah ini?

Tidak. Masih ada rencana untuk kembali ke ini dalam "dekat" di masa depan, tetapi beberapa tugas lain telah diprioritaskan.