Cp-ansible: Dukungan Galaxy yang memungkinkan

Ada pembaruan tentangnya? Akan jauh lebih mudah menggunakan buku pedoman ini

Saat ini tidak ada rencana untuk mempublikasikan ke galaksi yang memungkinkan. Saya akan mengajukan jira internal untuk melihat tentang menyelidiki ini untuk rilis mendatang.

Harapan umum adalah mengkloning repo, dan kemudian menjalankan buku pedoman yang diperlukan untuk pengaturan yang diberikan.

Ansible 2.9 memperkenalkan format distribusi baru yang disebut Collections. Sepertinya lebih cocok untuk menyelesaikan masalah ini karena koleksi dapat menyertakan buku pedoman, peran, modul, dan plugin.

Beberapa petunjuk:

• https://www.ansible.com/blog/getting-started-with-ansible-collections
• https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
• https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html

Saya mencoba restrukturisasi sebagai koleksi galaksi, diuji bekerja dengan buku pedoman all.yml dan sebagian besar konfigurasi dasar (ssl dan sasl/pendengar biasa). Bagian-bagiannya sangat kikuk, terutama sejauh yang saya tahu untuk referensi filter dan modul apa pun, Anda harus merujuk seluruh namespace galaksi. Ini berfungsi untuk kasus penggunaan saya, dan saya senang membuka PR jika tim menganggapnya layak untuk ditambahkan.

https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack

@aig787 Saya menyukainya! Saya selalu merasa bahwa upgrade playbook harus berada di direktori "playbook"
Peran memiliki akses ke apa yang ada di direktori plugin, kan?
Juga apakah direktori confluentinc_cp diperlukan?

Satu bagian yang rumit adalah ansible.cfg, saya selalu suka memilikinya tepat di sebelah playbook, karena mengharuskan konfigurasi yang memungkinkan dalam file itu digunakan selama instalasi

Semua peran memiliki akses ke apa yang ada di direktori plugin (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory). Saya pikir Anda hanya perlu menggunakan nama lengkap untuk mengaksesnya, misalnya saya harus mengubah KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" menjadi KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" agar filter berfungsi untuk saya. Mungkin ada beberapa cara untuk mengatasinya tetapi saya tidak dapat menemukannya.

Baru saja mencoba dengan direktori confluentinc_cp dihapus dan itu berfungsi dengan baik, jadi saya kira itu tidak perlu. Saya awalnya mem-bootstrapnya dengan ansible-galaxy collection init dan menggunakan struktur yang dibuat.

Apakah ada alasan mengapa ansible.cfg tidak bisa dipindahkan begitu saja ke direktori playbooks dengan yang lainnya? Saya _berpikir_ bahwa untuk menggunakan buku pedoman, orang masih perlu mengkloning repo dan menjalankannya seperti sekarang. Keuntungan memilikinya di galaksi akan lebih memberi orang akses ke peran dalam pengaturan mereka sendiri daripada membuat buku pedoman lebih mudah. Itu 2 sen saya pula.

Saya pribadi tidak peduli di mana ansible.cfg ditempatkan, saya hanya tahu jika Anda menjalankan buku pedoman dan dir Anda saat ini tidak berada di tempat ansible.cfg maka ada masalah.

Saya dapat melihat nilai dari mengikuti praktik terbaik yang memungkinkan dan mengikuti struktur direktori koleksi, tetapi saya ingin tahu apa manfaat menerbitkan koleksi ini ke galaksi bagi kita. Lebih banyak visibilitas?

Bagi saya sepertinya terlalu banyak biaya untuk mengelola pembuatan versi di galaksi dan di cabang kami.

Ini akan menjadi keuntungan kemudahan penggunaan. Jika saya memiliki buku pedoman yang melakukan beberapa konfigurasi dasar ke semua node saya, saya dapat menambahkan ini ke file persyaratan dan menjalankan `ansible-galaxy install -r requirements.yml' dan merujuk peran kafka dalam buku pedoman saya yang ada daripada harus mengkloning repo dan perpanjang buku pedoman atau salin direktori peran.

Adapun mengapa Anda benar-benar harus mempublikasikannya, saya tidak percaya koleksi mendukung referensi git seperti peran (https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -file vs. https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file). Saya setuju tentang jumlah overhead untuk versi, tampaknya agak berat.

Saya pribadi tidak peduli untuk memilikinya di Galaxy atau tidak, tetapi, dapat dengan mudah mereferensikan peran yang berbeda dalam file persyaratan akan sangat dihargai :smile:

Akan mendaftarkan masalah baru, tapi saya pikir masalah saya entah bagaimana terkait dengan masalah ini. Jadi mulailah dengan komentar di sini untuk mendapatkan umpan balik awal dari pengelola dan orang lain yang menonton.

Saya ingin menggunakan peran dalam repositori ini, tetapi saya ingin menggunakannya sebagai dependensi peran dalam peran khusus saya (ekstensi peran). Kami mulai menggunakan buku pedoman (all.yml), tetapi mengalami banyak masalah dalam menerapkan ekstensi kami dengan waktu yang tepat. Masalah (pemblokiran) pertama saya dengan pendekatan ini telah diperbaiki dengan https://github.com/confluentinc/cp-ansible/pull/442 . Namun setelah melihat lebih dekat pada log kami untuk menjalankan playbook, saya menyadari bahwa kami mungkin memiliki masalah tambahan:

[DEPRECATION WARNING]: Included file 
'/builds/kafka/provisioner/tasks/failure_handling.yml' not found, however since
 this include is not explicitly marked as 'static: yes', we will try and 
include it dynamically later. In the future, this will be an error unless 
'static: no' is used on the include task. If you do not want missing includes 
to be considered dynamic, use 'static: yes' on the include or set the global 
ansible.cfg options to make all includes static for tasks and/or handlers. This
 feature will be removed from ansible-base in version 2.12. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Melihat detailnya, saya pikir masalah umum adalah bahwa peran saat ini tidak mandiri. Memperbaiki itu akan menjadi langkah wajib untuk akhirnya menerbitkan peran atau pengumpulan peran ke Ansible Galaxy. Dan saya pikir ini dapat diperbaiki dengan cukup mudah, karena ini bermuara pada referensi ke direktori tingkat atas berikut /filter_plugins dan /tasks dari dalam peran.

Apa pendapat Anda tentang tugas-tugas berikut sebagai permintaan tarik:

1. Pindahkan folder /filter_plugins ke dalam peran confluent.variables - menjadikannya bagian dari peran itu? Plugin filter setidaknya digunakan dalam peran ini.

2. Pindahkan file tugas yang dapat digunakan kembali di /tasks ke salah satu peran yang ada, mungkin confluent.common adalah yang paling sesuai dengan peran yang ada, atau buat peran khusus baru untuk mereka ( confluent.common_tasks )? Dan perbarui referensi ke file tugas yang digunakan kembali dengan include_role#tasks_from . Contoh:

Index: roles/confluent.zookeeper/tasks/health_check.yml
<+>UTF-8
===================================================================
--- roles/confluent.zookeeper/tasks/health_check.yml    (revision 0d369ae20c8215dd2ec469f269dc804539f58190)
+++ roles/confluent.zookeeper/tasks/health_check.yml    (date 1602793473938)
@@ -25,7 +25,9 @@
   ignore_errors: true

 - name: Fetch Files for Debugging Failure
-  include: tasks/failure_handling.yml
+  include_role:
+    name: confluent.common
+    tasks_from: failure_handling.yml
   vars:
     service_name: "{{zookeeper_service_name}}"
     config_file: "{{zookeeper.config_file}}"

@erikgb Itu adalah sesuatu yang telah kami diskusikan secara internal di masa lalu. Secara khusus, ada cukup banyak diskusi seputar peran mandiri, vs meminimalkan duplikasi kode. Sepertinya kita harus mengubah ini untuk 2.12. rilis Ansible, berdasarkan peringatan, jadi saya pikir mungkin paling masuk akal untuk memindahkan /filter_plugins dan /tasks ke dalam peran confluent.common , dan kemudian menggunakan yang tepat impor pernyataan di semua peran lainnya.

@domenicbove apa pendapat Anda?

Saya tidak punya masalah dengan memindahkan lokasi file selama fungsionalitas tetap konsisten @erikgb @JumaX.
Ini sepertinya pekerjaan yang cukup besar sehingga harus masuk ke cabang master, menargetkan rilis kami berikutnya.

@domenicbove Setuju tentang itu berfungsi untuk rilis besar kami berikutnya. @erikgb Kami akan menambahkan

Atau @erikgb Jika Anda memiliki pekerjaan yang duduk di cabang, Anda dipersilakan untuk membuat PR ke cabang master dan kami akan meninjau. Saya tidak berpikir itu akan menyelesaikan masalah ini secara keseluruhan, kita masih perlu membuat galaksi.

Rilisan besar berikutnya? Apakah itu Platform Konfluen 7? Perubahan ini dapat dibuat kompatibel ke belakang, saya pikir - selama orang menganggap titik masuk utama adalah buku pedoman dan peran. Saya lebih suka memperbaiki ini sebelum CP 7.

@erikgb itu akan untuk CP 6.1, kami cenderung tidak menempatkan fungsionalitas baru, terutama jika melibatkan refactoring besar ke rilis yang lebih lama. Kami memiliki banyak pelanggan perusahaan yang memiliki kebijakan/masalah ketika kami mengubah repo terlalu banyak untuk versi yang ada, kami mencoba untuk menyimpannya hanya untuk perbaikan bug.

@domenicbove @JumaX CP 6.1 lebih masuk akal. Saya akan melihat apakah saya punya waktu untuk mengerjakan pull request akhir minggu ini. Saya akan merekomendasikan untuk membagi refactoring menjadi bagian-bagian yang bermakna. WDYT?

@erikgb Jika Anda ingin membaginya menjadi beberapa PR, tidak apa-apa dengan asumsi bahwa setiap PR masih dapat berjalan tanpa PR tambahan. Tidak yakin saya telah menyatakan bahwa sangat baik. :). Harus bertujuan untuk Cabang Master.