Ansible: ملفات متعددة في الدليل الافتراضي للدور

يمكن أن يكون لديك main.yml في tasks ، يتضمن ملفات أخرى ، حتى في الدلائل الفرعية tasks ، على سبيل المثال لتكوين المكونين الرئيسيين foo والشريط لهذا الدور الكبير:

- include: foo/main.yml
- include: bar/main.yml

يؤدي استخدام وحدة include_vars لمتغيرات الدور الافتراضية إلى إبطال سبب وجود المتغيرات الافتراضية في المقام الأول ، أي استخدامها لتوفير "الإعدادات الافتراضية للملاذ الأخير" والتي يمكن استبدالها بسهولة بواسطة أجزاء أخرى من الدور / كتاب التشغيل.

تمت مناقشة فكرة وجود ملفات متعددة في دليل defaults/ سابقًا على IRC ، وخلصنا إلى أن تحليل الدليل defaults/ غرار الدلائل inventory/group_vars/ و inventory/host_vars/ سيكون كذلك من الجميل أن يكون لديك. الكود المطلوب موجود بالفعل ، ونأمل أن يتم تكييفه بسهولة مع الإعدادات الافتراضية للأدوار.

+1

+1

سيكون من الجيد الحصول عليه!

+1

نعم ، افترضت للتو أنه تم العثور على الإعدادات الافتراضية / * وتحميلها تلقائيًا كما هو مذكور أعلاه. يبدو أن الحل البديل المقترح (بما في ذلك ملفات الإعدادات الافتراضية الإضافية في المهام) سوف يتجاوز متغيرات المخزون بسبب الأسبقية المتغيرة ، لذلك يبدو أننا قد نضطر إلى تجميع ملف واحد لتجنب هذه المشكلة حتى تتم معالجتها.

أسبقية متغيرة 2.x غير صالحة

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

قد يكون هذا متعلقًا بـ # 8121

+1

+1

بالتأكيد يجب أن يكون لها ميزة بسبب قيود الأسبقية المتغيرة.
يسمح هذا أيضًا بتحديد ملف الإعدادات الافتراضية لكل فئة من المتغيرات والحفاظ على فصل نظيف ؛ على سبيل المثال ، في الشبكات ، سيسمح لي ذلك بتعريف ملف افتراضي واحد لـ IPv4 ، وآخر لـ IPv6 ، والآخر لـ SNMP وما إلى ذلك ...
أخيرًا ، يبدو أنه من الضروري أن تكون قادرًا على وضع هذه الملفات في مجلدات مختلفة ضمن "الإعدادات الافتراضية".

فقط اضغط على هذا بنفسي ، لذلك ، بالتأكيد +1

هذا حقا بيتا.
إذا كان بإمكاني اقتراح حل ، فسيكون إضافة خيار مشابه لـ include_vars ، ولكن في meta/main.yml ، لتحديد أمر التحميل.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

سيسمح هذا للخيار بالتعيين الافتراضي إلى ["main.yml"] وعدم كسر الكود الحالي ، مع منح المطورين القدرة على تحديد المتغيرات الدقيقة بناءً على السياقات التي يختارونها.

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

بالتأكيد +1

بالنسبة إلى vars/ نفس الشيء ، لكن يبدو أن # 2958 كان يتخذ قرارًا ضد هذا

يتطابق مثال

سيكون خيار الواجهة الآخر:

• أضف خيارًا إلى الوحدة النمطية include_vars ، "as_default" ، التي تعالج الملف المضمن كما لو كان افتراضيًا.

بالنسبة لي ، يبدو الأمر غريبًا / بديهيًا أن هناك دليلًا "افتراضيًا" يحتوي على ملف واحد بداخله.
أعني ، هل سبق لك أن رأيت وحدة Python بملف واحد __main__.py بداخلها؟

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

يتيح لك include_role تحديد ملفات "بديلة" الآن http://docs.ansible.com/ansible/include_role_module.html عبر الخيار defaults_from

لقد دخلت للتو في موقف عندما يكون تقسيم defaults/main.yml مطلوبًا. تمت إضافة إلى المشكلة.

بالمثل هنا ، أحتاجه أيضًا
+1

+1

bcoca إنها إضافة لطيفة وتضيف المرونة ، لكنها لا تتناول المشكلة هنا ،

يرجى مراجعة تعليقي أعلاه

نعم ، هذه ميزة مفيدة للغاية لتجنب الملفات التي تحتوي على 2k سطر.
+1

+1

+1

👍

+1

+1

+1
نفس المشكلة هنا. main.yml كبير جدًا ، مقسم إلى عدة ملفات. افترضنا أنها "تعمل فقط" وتحميل جميع المتغيرات في الملفات في ظل الإعدادات الافتراضية / لأنها dir. لا فرح.

+1

+1

+1

👍

+1

+1

👍

يمكنكم يا رفاق رفض كل تعليق +1 ، لكنني أشك بشدة في أنه يمكنك تتبع عدد المشتركين ، لذا فإن إضافة +1 لا تزال طريقة جيدة لإظهار الدعم المطلوب.

حتى يتم ربط الاهتمام بالمشكلة بشكل واضح بعدد المشتركين في إحدى المشكلات ، توقع دائمًا رؤية تعليقات 1+.

ما يمكنك توقعه هو أن يقوم الفريق الثابت بتأمين تعليقات القضية بدلاً من ذلك ، لذلك لا تكن مرسلاً رسائل غير مرغوب فيها ولا تدافع عنها من فضلك.

ما يمكنك توقعه هو أن يقوم الفريق الثابت بتأمين تعليقات القضية بدلاً من ذلك ، لذلك لا تكن مرسلاً رسائل غير مرغوب فيها ولا تدافع عنها من فضلك.

يمكنهم القيام بذلك ولكن هذه مشكلة أساسية للقدرة على تطوير الأدوار بشكل صحيح خاصة منذ إدخال include_role في 2.x جنبًا إلى جنب مع طريقة التضمين القديمة roles . إذا قمت بتصميم دورك ليكون متوافقًا مع include_role ، وهو الأفضل لأنه يجعل التطوير أكثر مرونة ووحدات مقارنة بالطريقة القديمة roles وحدها ، إذن فلا يزال لديك لتتبع إما تضمين الإعدادات الافتراضية كمهام في كتب اللعب الخاصة بك ، أو تمرير المسؤولية إلى المستخدم النهائي الذي لا يجب أن يعرف كيفية القيام بذلك حتى يعمل دورك بشكل صحيح ، أو تتبع النظام الأساسي / التوزيعة / الإصدار كمستوى متداخل من متغيرات الدور التي تعقد الجحيم من التطوير (على الرغم من أنها تعمل كما أنشأت دورًا يمكنه دعم 20 إصدارًا مختلفًا للنظام الأساسي هنا ). هل حاولت بالفعل كتابة دور يدعم بالفعل أكثر من بضع منصات؟ ليس من المستغرب عدم وجود معظم الأدوار في Ansible Galaxy ، فهذه المشكلة ربما تكون رقم واحد في تلك القائمة IMO.

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

هذه مشكلة فقط لأنهم أطلقوا include_role دون التفكير في كيفية تأثير استخدامه في الواقع على الإعدادات الافتراضية. إن إجبار شخص ما على الاختيار بين استخدام roles و include_role أجل جعل الدور يعمل بشكل صحيح أو إضافة عمل إضافي لتمكين كليهما من العمل في وقت واحد هو جوهر المشكلة هنا.

2 سنتي.

ملاحظة: إذا كنت تقوم بالتصويت على زر إلغاء الاشتراك 1+ لأنك لا تريد الإشعارات .... اضغط على زر إلغاء الاشتراك في أعلى اليمين ولن تحصل عليها بعد الآن.

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

أود إضافة صوتي إلى طلب هذه القدرة وتفاصيل حالة الاستخدام الخاصة بي. بالإضافة إلى القدرة البسيطة على تفكيك main.yml الكبيرة ، فإن القدرة على فعل شيء كهذا ستكون رائعة:

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

ما آمل أن أنجزه بهذا هو [كمثال] دور openssh يدعم جميع خيارات ssh_config و sshd_config ، ويدعم العديد من أنظمة التشغيل والإصدارات [أي. Debian 8/9 ، EL6 / 7 ، إلخ] ولكن إذا تم استدعاؤها بدون متغيرات تم تعيينها من قبل المستخدم ، فإنها ستنشئ التكوين بأمان إلى الإعدادات الافتراضية OS_majorversion ، ولكن يمكن أن يكون لديها أي خيار متاح تجاوزه المستخدم.

كما هو الحال الآن ، إذا وضعت هذه الإعدادات الافتراضية لنظام التشغيل في include_vars ، فإن الأسبقية عالية جدًا ، ولا يمكن للمستخدم تجاوز تلك الإعدادات في المخزون ، أو في group_vars / all أو في group_vars / groupname أو في host_vars إلخ.

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

ستسمح إضافة هذه الميزة بهذا وقد تساعد في توفير أدوار ذات جودة أعلى في جيثب / جالاكسي.

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

إصدارات مماثلة / feature_idea: https://github.com/ansible/ansible/issues/11639

هذا حقا بيتا.
إذا كان بإمكاني اقتراح حل ، فسيكون إضافة خيار مشابه لـ include_vars ، ولكن في meta/main.yml ، لتحديد أمر التحميل.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

سيسمح هذا للخيار بالتعيين الافتراضي إلى ["main.yml"] وعدم كسر الكود الحالي ، مع منح المطورين القدرة على تحديد المتغيرات الدقيقة بناءً على السياقات التي يختارونها.

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

تماشياً مع abedwardsw (التعليق من قبل):
سيكون الاقتراح القديم الذي يزيد عن cornfeedhobo (15: +1 @ doubletwist13 ) مفيدًا حقًا للعديد من الأدوار التي أعرفها ، ولا سيما المعقدة بما يكفي:
https://github.com/hortonworks/ansible-hortonworks

المراجع المباشرة لتعليقاتهم:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

راجع أيضًا اقتراح geerlingguy (من 2016!) ، وتعليقي هناك (الذي يحاول جمع المشكلات ذات الصلة): https://github.com/ansible/proposals/pull/21#issuecomment -470048538