Cp-ansible: دعم Ansible Galaxy

أي تحديث على ذلك؟ سيكون استخدام كتيبات اللعبة هذه أسهل كثيرًا

حاليا لا توجد خطط للنشر في المجرة غير المرئية. سوف أقوم بتقديم طلب جيرة داخلي لمعرفة ما إذا كان سيتم التحقيق في هذا الأمر من أجل إصدار مستقبلي.

التوقع العام هو استنساخ الريبو ، ثم تشغيل دليل التشغيل المطلوب للإعداد المحدد.

قدم Ansible 2.9 تنسيق توزيع جديد يسمى المجموعات. يبدو أنه مناسب بشكل أفضل لحل هذه المشكلة نظرًا لأن المجموعة يمكن أن تتضمن كتيبات اللعب والأدوار والوحدات النمطية والمكونات الإضافية.

بعض المؤشرات:

• 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

لقد اتخذت خطوة في إعادة الهيكلة كمجموعة مجرة ​​، واختبرت العمل مع كتاب التشغيل all.yml وبعض التكوينات الأساسية في الغالب (مستمعي ssl و sasl / عادي). أجزاء منه عالية الكعب ، في المقام الأول بقدر ما أستطيع أن أقول للإشارة إلى أي مرشحات ووحدات يجب أن تشير إلى مساحة اسم المجرة بأكملها. إنه يعمل مع حالة الاستخدام الخاصة بي ، ويسعدني أن أفتح العلاقات العامة إذا كان الفريق يعتقد أنه يستحق الإضافة.

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

@ aig787 يعجبني! لطالما شعرت أن كتيبات التشغيل يجب أن تكون في دليل "playbook"
الأدوار لها حق الوصول إلى ما هو موجود في الملحقات دير أليس كذلك؟
أيضا هل من الضروري دير confluentinc_cp؟

قطعة واحدة صعبة هي ansible.cfg ، لقد أحببت دائمًا وجود ذلك بجوار كتيبات التشغيل ، لأنني أشترط استخدام التكوين غير القابل للتصرف في هذا الملف أثناء التثبيت

تتمتع جميع الأدوار بإمكانية الوصول إلى ما هو موجود في دليل الملحقات (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory). أعتقد أنه عليك فقط استخدام الاسم الكامل للوصول إليه ، على سبيل المثال ، اضطررت إلى تغيير KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" إلى KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" حتى يعمل الفلتر من أجلي. قد يكون هناك طريقة ما للتغلب على ذلك ولكني لم أتمكن من العثور عليه.

حاولت للتو إزالة دليل confluentinc_cp وعمل جيدًا ، لذلك أعتقد أنه ليس ضروريًا. قمت في البداية بتمهيده بـ ansible-galaxy collection init وذهبت مع الهيكل الذي تم إنشاؤه.

هل هناك سبب لعدم إمكانية نقل ansible.cfg إلى دليل playbooks مع البقية؟ أعتقد أنه من أجل استخدام كتيبات اللعبة ، سيظل الناس بحاجة إلى استنساخ الريبو وتشغيله كما يفعلون الآن. تتمثل ميزة وجوده في المجرة في منح الأشخاص إمكانية الوصول إلى الأدوار في إعداداتهم الخاصة بدلاً من تسهيل قواعد اللعبة. هذا هو 2 سنتي على أي حال.

أنا شخصياً لا أهتم بمكان وضع ansible.cfg ، فأنا أعرف فقط ما إذا كنت تشغل كتاب اللعبة وديرك الحالي ليس في المكان الذي يوجد فيه ansible.cfg ، فهناك مشاكل.

أستطيع أن أرى قيمة الالتزام بأفضل الممارسات واتباع بنية دليل المجموعات ، لكنني أشعر بالفضول بشأن فوائد نشر هذه المجموعة في المجرة. المزيد من الرؤية؟

بالنسبة لي ، يبدو الأمر وكأنه الكثير من النفقات العامة لإدارة الإصدار في المجرة وفي فروعنا.

سيكون كسب سهولة الاستخدام. إذا كان لدي كتاب تشغيل يقوم ببعض التهيئة الأساسية لجميع العقد الخاصة بي ، فيمكنني إضافة هذا إلى ملف المتطلبات وتشغيل "ansible-galaxy install-r requirements.yml" والإشارة إلى دور kafka في دليل التشغيل الحالي الخاص بي بدلاً من الاضطرار إلى الاستنساخ الريبو وتوسيع كتاب التشغيل أو نسخ أدلة الأدوار حولها.

بالنسبة إلى سبب وجوب نشره بالفعل ، لا أعتقد أن المجموعات تدعم مراجع git مثل الأدوار (https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -ملف مقابل https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file). أوافق على مقدار النفقات العامة للإصدار ، يبدو ثقيلًا بعض الشيء.

أنا شخصياً لا أهتم بالحصول عليها في Galaxy أم لا ، ولكن القدرة على الإشارة بسهولة إلى الأدوار المختلفة في ملف المتطلبات سيكون موضع تقدير حقًا: ابتسم:

كنت على وشك تسجيل مشكلة جديدة ، لكنني أعتقد أن مشكلتي مرتبطة بطريقة ما بهذه المشكلة. لذا ابدأ بتعليق هنا للحصول على بعض التعليقات الأولية من المشرفين وغيرهم ممن يشاهدون.

أرغب في استخدام الأدوار الموجودة في هذا المستودع ، لكنني أريد استخدامها كتبعيات للأدوار في الأدوار المخصصة (امتدادات الأدوار). بدأنا في استخدام كتاب التشغيل (all.yml) ، ولكن واجهنا الكثير من المتاعب في تطبيق ملحقاتنا بالتوقيت الصحيح. تم إصلاح مشكلتي الأولى (المنع) مع هذا الأسلوب من خلال https://github.com/confluentinc/cp-ansible/pull/442. ولكن بعد الاطلاع عن كثب على سجلاتنا في دليل التشغيل ، أدركت أنه قد تكون لدينا مشكلات إضافية:

[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.

بالنظر إلى التفاصيل ، أعتقد أن المشكلة العامة هي أن الأدوار ليست قائمة بذاتها حاليًا. سيكون إصلاح ذلك خطوة إلزامية نحو نشر الأدوار أو مجموعة الأدوار في نهاية المطاف إلى Ansible Galaxy. وأعتقد أن هذا يمكن إصلاحه بسهولة تامة ، لأنه يتلخص في الإشارات إلى أدلة المستوى الأعلى التالية /filter_plugins و /tasks من داخل الأدوار.

ما رأيك في المهام التالية كطلبات سحب:

1. انقل المجلد /filter_plugins إلى الدور confluent.variables - مما يجعله جزءًا من هذا الدور؟ ملحقات التصفية قيد الاستخدام على الأقل في هذا الدور.

2. انقل ملفات المهام القابلة لإعادة الاستخدام في /tasks إلى أحد الأدوار الحالية ، ربما يكون confluent.common هو الأنسب للأدوار الحالية ، أو إنشاء دور مخصص جديد لهم ( confluent.common_tasks )؟ وتحديث المراجع إلى ملفات المهام المعاد استخدامها مع include_role # features_from . مثال:

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 إنه شيء ناقشناه داخليًا في الماضي. على وجه الخصوص ، كان هناك الكثير من النقاش حول الأدوار المستقلة ، مقابل تقليل تكرار الكود. يبدو أنه سيتعين علينا تغيير هذا لـ 2.12. إصدار Ansible ، بناءً على التحذير ، لذلك أعتقد أنه قد يكون من المنطقي نقل كل من /filter_plugins و /tasks إلى الدور confluent.common ، ثم استخدام مناسب استيراد البيانات في جميع الأدوار الأخرى.

domenicbove ما هي أفكارك؟

ليست لدي مشكلة في نقل مواقع الملفات طالما ظلت الوظائف ثابتةerikgbJumaX.
يبدو أن هذا عمل كبير بما يكفي بحيث يجب أن ينتقل إلى الفرع الرئيسي ، مستهدفًا إصدارنا التالي بالرغم من ذلك.

domenicbove موافق على أنه يعمل erikgb سنضيف JIRA داخلي لتتبع ذلك ومعرفة ما إذا كان بإمكاننا وضعه على خريطة الطريق

أو erikgb إذا كان لديك عمل موجود في أحد الفروع ، فنحن نرحب بك لتقديم العلاقات العامة في الفرع الرئيسي

الإصدار الرئيسي التالي؟ هل هذا سيكون Confluent Platform 7؟ أعتقد أن هذا التغيير يمكن أن يكون متوافقًا مع الإصدارات السابقة - طالما اعتبر المرء أن نقاط الدخول الرئيسية هي كتب اللعب والأدوار. أفضل إصلاح هذا قبل CP 7. 😄

erikgb سيكون من أجل CP 6.1 ، ونحن نميل إلى عدم وضع وظائف جديدة ، خاصة إذا كانت تنطوي على إعادة هيكلة كبيرة في الإصدارات القديمة. لدينا الكثير من عملاء المؤسسات الذين لديهم سياسات / مشكلات عندما نغير الريبو كثيرًا للإصدار الحالي ، نحاول الاحتفاظ به لإصلاح الأخطاء فقط.

domenicbove @ JumaX CP 6.1 يبدو أكثر منطقية. سأرى ما إذا كان لدي بعض الوقت للعمل على طلب (طلبات) السحب في وقت لاحق من هذا الأسبوع. أوصي بتقسيم إعادة البناء إلى أجزاء ذات مغزى. WDYT؟

erikgb إذا كنت تريد تقسيمها إلى عدة علاقات عامة قادرة على الاستمرار في العمل بدون