من فضلك دعنا لا نسميها how . هذا أسوأ من قراءته من become: true . لكن الوظيفة الموجودة تحتها تبدو رائعة.

يتضمن الإصلاح لـ # 10695

ممتاز. لمصلحة زواج الدرّاجات ، يمكن تسميتها looping: .

: +1:

+1

+1 خاصة في موازاة المضيف!

: +1:

: +1:
لكن دعونا لا نسميها "كيف"

لذلك هنا حل بديل لكسر مهمة حلقة بعد الفشل الأول

- hosts: localhost
  vars:
    myvar:
        - 1
        - 2
        - 3
        - 4
        - 5
  tasks:
    - name: break loop after 3
      debug: msg={{item}}
      failed_when: item == 3
      register: myresults
      when: not (myresults|default({}))|failed
      with_items: "{{myvar}}"

bcoca لا يعمل من النهاية (ansible 1.9.3 ubuntu)

المهمة: [فاصل الحلقة بعد 3] * * * * * * * * * * * * * * ** *
حسنًا: [localhost] => (item = 1) => {
"فشل": خطأ ،
"fail_when_result": خطأ ،
"البند 1،
"msg": "1"
}
حسنًا: [localhost] => (item = 2) => {
"فشل": خطأ ،
"fail_when_result": خطأ ،
"العنصر": 2 ،
"msg": "2"
}
فشل: [localhost] => (item = 3) => {"failure": true، "failure_when_result": true، "item": 3، "verbose_always": true}
الرسالة: 3
حسنًا: [localhost] => (item = 4) => {
"فشل": خطأ ،
"failure_when_result": خطأ ،
"العنصر": 4 ،
"msg": "4"
}
حسنًا: [localhost] => (item = 5) => {
"فشل": خطأ ،
"failure_when_result": خطأ ،
"العنصر": 5 ،
"msg": "5"
}

آه ، نعم ، ستعمل كما هي في 2.0 كما في 1.9 لا يحدث التسجيل إلا بعد انتهاء الحلقة.

+1 على مفترق الطرق

+1
ربما بدلاً من "كيف" ، تفاصيل الحلقات أو الخيارات؟

+1

+1 ، استخدام wait_for من localhost لانتظار 100 مضيف EC2 حتى يظهر يقتلني ...

+1 لسبب مشابه لـ Senderista

+1

: +1:

سيكون كل من squash و forks من الميزات الرائعة التي من شأنها تسريع تنفيذ Ansible بشكل كبير.

أود أيضًا استبدال how بشيء مثل loop_details أو loop_settings أو loop_options أو أي شيء مشابه.

loop_control ، موجود بالفعل في 2.1 مع تنفيذ الجزء label .

قد يختفي الاسكواش لأنه من السهل تمرير قائمة للوحدات التي تدعمه:

apt: name={{listofpackages}}

وتجنب الحلقة تمامًا

http://docs.ansible.com/ansible/playbooks_loops.html#loop -control

+1 شوكة

+1 شوكة

كان لدي حالة استخدام لتكوين جديد لكسر مشروط break_when

+1 مفترقات وأتمنى أن تعمل أيضًا لموازنة تسلسل المهام للتشغيل كما في:
- include: service.yml
with_items: "{{services|default([])}}"

خلاف ذلك ، هناك async/async_status بالفعل.

+1 شوكة

أنا أنتظر وحدات Openstack للتكرار من خلال حلقات with_ على أكثر من 100 عنصر ...

+1 على مفترق الطرق. يمكن استخدام هذا لنسخ AMIs إلى جميع مناطق AWS.

+1 على مفترق الطرق. لو سمحت! اجعله جزءًا من loop_control

+1 على مفترق الطرق

+1 على مفترق الطرق

+1 ، أحتاج إلى شوك أيضًا :-)

+1 على مفترق الطرق

+1 على مفترق الطرق

سيكون الشوك رائعًا ، +1

أجلس دائمًا في صمت ولا أرغب في المساهمة في البريد العشوائي ، لأنه من الصعب قياس بين المشاريع سواء تم الترحيب بها أم لا ، ولكن يبدو أن قطار fork +1 قد غادر المحطة!

+1 على مفترق الطرق

+1 على مفترق الطرق

+1 على مفترق الطرق

: +1: على الشوك

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

فيما يلي العناصر التي لم نتمكن من العثور عليها في وصفك:

• نوع القضية
• نسخة غير قابلة للتصديق
• اسم المكون

الرجاء تعيين وصف هذه المشكلة مع هذا النموذج:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

انقر هنا للحصول على مساعدة الروبوت

+1 على مفترق الطرق

+1 على مفترق الطرق!

+1 على فوركس!

+1 على مفترق الطرق!

+1 على مفترق الطرق!

أي تحديث على مفترق الطرق؟ متى من المفترض أن تكون جاهزة؟
حالة الاستخدام الخاصة بي هي إنشاء مثيل لحوالي 20 حاوية على خادم مع التسلسل . الآن يستغرق الأمر الكثير من الأعمار :(
يسعدني تقديم المساعدة ، لكني سأحتاج إلى بعض النصائح حول مكان وضع اليدين

bitliner لم يقم أحد بإنشاء علاقات عامة لها ، إذا كان هذا هو ما تطلبه ، فمن الصعب جدًا القيام به بشكل صحيح.

بالنسبة إلى مشكلتك ، ما عليك سوى الإعلان عن مضيفات X في المخزون وتكرار ما يزيد عن hosts: بدلاً من with_ لإنشائها بشكل متوازي.

المخزون:

[containers]
container[000:020]

hosts: containers
gather_facts: false
tasks:
   - container: state=present name={{inventory_hostname}}

على سبيل المثال ، الحاوية عبارة عن وحدة نمطية "مركبة".

bcoca الحل الخاص بك ليس واضحا بالنسبة لي. للتأكد ، هل هذا ما تعنيه؟

ملف المضيفين

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100
... and so on based on the degree of parallelism I want to get ...

ملف main.yml

hosts: containers
gather_facts: false
tasks:
   - container: state=present name={{inventory_hostname}}

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

علاوة على ذلك ، ما هي التحديات للقيام بتنفيذ حلقة بالتوازي بشكل صحيح؟

تحتاج حالة الاستخدام الخاصة بي إلى تسريع هذه المهمة:

- name: "Start clients"
  docker_container:
    name: "mycontainer-{{ item }}"
    image: myimage
    links: 
      - server-{{item}}:server-{{item}}
  with_sequence: count={{ scale }}

لا يمكنني استخدام مقياس إنشاء عامل الإرساء لأنني بحاجة إلى توجيه حركة المرور بين الحاويات بطريقة معينة (وهذا هو سبب استخدامي مع التسلسل لإنشاء أسماء مختلفة لحاويات عامل الإرساء).

يمكنني إنشاء وحدة تأخذ إعلان الحاوية وتستند إلى معلمة مقياس ، فإنها تنشئ حاويات متعددة عن بُعد بالتوازي. هل له معنى؟ هل لديك أي مساعدة لفهم كيفية استدعاء / إعادة استخدام وحدة docker_container في myModule وما هي واجهة برمجة التطبيقات التي يقدمها Ansible لتشغيل شيء ما بالتوازي؟

bitliner ، أنت لم تتبع تعليماتي ، لدي أسماء فريدة في المخزون (باستخدام النطاق للعمل تمامًا مثل التسلسل). نظرًا لأن الأسماء فريدة في المخزون ، فقد أعلنت للتو نفس الاسم N مرة ، ولكن لا يزال لديك مضيف واحد ، وهو ما لا يتسبب في مشكلتك الثانية على الأسماء المخادعة للحاويات لأنك تقوم بالتكرار أكثر من مضيف واحد فقط.

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

bcoca كيف يمكنني الحصول على مضيف واحد إذا أعلنت 20 مضيفًا؟

[containers]
container[000:020]

سيتم الاتصال بـ container001 ، container002 ، إلخ.

إنه يعمل من أجل الحصول على أسماء فريدة ، ولكن ما هو غير واضح بالنسبة لي هو سبب قولك إنه لا يزال لدي مضيف واحد (بدلاً من 20).
يعني hosts:containers بالنسبة لي 20 مضيفًا ، وليس مضيفًا واحدًا فقط. ما الذي أتجاهله في هذا الحل؟

bitliner تسبب هذا:

[containers]
192.168.1.100
192.168.1.100
192.168.1.100
192.168.1.100

ليس 4 مضيفين ، ولكن 1

في هذه المرحلة أيضًا ، هذا بعيدًا عن الموضوع إلى حد كبير ، إذا كنت ترغب في الاستمرار في الحصول على المساعدة في هذا الشأن ، فانتقل إلى IRC أو ML

لقد حللت باستخدام

[containers]
ip[000:020] ansible_host=192.168.1.100

و

- name: "Start containers"
  docker_container:
    name: "my-container-{{ inventory_hostname }}"

سؤال: التصوير لإضافة عبارة fork ، هل تتكون التغييرات من إعادة كتابة طريقة run_loop لجعلها تدير مستوى التوازي وعدم التزامن؟

وبعد ذلك يبدأ "المرح" ...:

• هل يتم احتساب شوكة الحلقة مقابل --forks العالمي ، اجعل ذلك لكل جهاز تحكم عن بعد؟
• ماذا تفعل مع الحلقات عندما تعتمد العناصر على العناصر السابقة (ليس فقط تنفيذ المهمة ، ولكن الشرطية ، إلخ)؟
• كيف تتعامل مع مشكلات التزامن عند تنفيذ عدة مفترقات على نفس المضيف؟ أي أنها تقوم بتحديث نفس الملف
• كيف نتعامل مع التنظيف؟ في الوقت الحالي يمكنهم إعادة استخدام tmp dirs .. ولكن كل عملية تنفيذ تنظف بعد نفسها ، والآن يمكن أن يتسبب هذا في حدوث مشكلات.

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

لا يجب تمكين تفرع bcoca Loop افتراضيًا. أفضل رؤية الإعداد الافتراضي على 1 وتقديمه كمعامل forks أو serial ، لكن مع تضمين تحذير. من المحتمل أن يكسر بعض التعليمات البرمجية الحالية. بعد قولي هذا ، إنني أتطلع بشدة إلى هذه الميزة (خاصة للمهام التي تتطلب delegate_to )

+1 للشوكات (خطأ افتراضيًا)

+1 شوكة

+1 شوكة

+1 شوكة

+1 شوكة

+1 شوكة

+1 للشوكات أيضًا ، ولكن في هذه الأثناء ، هناك أيضًا مكون إضافي لاستراتيجية Ansible جديد يوفر زيادة كبيرة في الأداء بشكل عام ، وكذلك لحلقات with_items . ربما بالنسبة لأولئك الذين يريدون الشوكات لأسباب تتعلق بالأداء ، فإن الأمر يستحق النظر فيه:

https://github.com/dw/mitogen
https://mitogen.readthedocs.io/en/latest/ansible.html

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

هذا لا يساعد في وظائف سحابة AWS أو Azure حيث التنفيذ
يحدث على وحدة التحكم غير الصالحة ويتم تنفيذه فقط على مجموعة من العناصر في
هذا النظام السحابي ولا يتصل بالمضيفين على الإطلاق ، وهو
المشكلة الأساسية مع بطء with_items. لا علاقة له بمجموعة كبيرة
من الآلات أو الكمون أو أي شيء متعلق بـ ssh. إنها ببساطة الحقيقة
أنه ينفذ وظائف السحابة في حلقة with_items في المسلسل ولا شيء
يمكن تسريع ذلك باستثناء قيام مزود السحابة بتحسين سرعته أو ملف
التنفيذ المتوازي لتلك الوظائف السحابية بواسطة ansible.

كما أنه لا يذكر with_items في المقالة على الإطلاق ، لذا لا يمكنني معرفة كيفية القيام بذلك
هذا سوف يساعد حتى في أصغر قليلا. هل يمكنك ان تشرح اكثر قليلا
كيف يمكن أن يساعد هذا؟ أود أن أعرف ما الذي أفتقده إذا كنت في عداد المفقودين
شيء هنا.

في يوم السبت ، 10 مارس 2018 الساعة 21:58 ، كتب NielsH [email protected] :

+1 للشوكات أيضًا ، ولكن في هذه الأثناء هناك أيضًا Ansible جديد
المكوِّن الإضافي الإستراتيجي الذي يعطي زيادة كبيرة في الأداء بشكل عام وأيضًا
لحلقات with_items. ربما لأولئك الذين يريدون شوكات للأداء
الأسباب التي تستحق البحث عنها:

https://github.com/dw/mitogen
https://mitogen.readthedocs.io/en/latest/ansible.html

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372070418 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AJd59qWI9n_DNmUqpmZYiIOMZAyjJy3uks5tdEyQgaJpZM4Fx8zF
.

في الواقع ، لن يساعد في جميع الحالات. ومع ذلك ، فإن السبب الذي يجعلني أبحث عن مفترقات في with_items هو البطء في معالجة كل عنصر على حدة (حتى مع خطوط الأنابيب). في بعض الأحيان ، يتعين علي إنشاء عدد كبير (عدة مئات) من الدلائل بناءً على host_vars ، أو قالب بضع مئات من الملفات. لذلك أقوم بالتكرار على الوحدة النمطية file و template في الغالب.

لقد اختبرت ذات مرة قالب 100 ملف في 100 ملف منفصل من خلال with_items vs looping فوق العناصر الموجودة في قالب jinja نفسه ودمج القالب في ملف كبير واحد. يستغرق كل شيء في ملف واحد 5 ثوانٍ ، لكن إنشاء 100 ملف تكوين منفصل يستغرق 30 دقيقة.

قدم المكوِّن الإضافي الذي ذكرته تحسنًا كبيرًا بالنسبة لي ، واعتقدت أنه من الجدير ذكره هنا.

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

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

gjcarneiro ثم لا تحددها على أنها بيانات ، حددها كمضيف واستهدفها ، ثم delegate_to: localhost لتنفيذ الإجراءات بالتوازي

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

ثم مرة أخرى ، ربما أستخدم ansible لغرض مختلف تمامًا عما كان مقصودًا ، لذا فهو خطأي بطريقة ما :(

ليس معقدًا حقًا ، فهذه هي الطريقة التي يُقصد بها Ansible في استخدام paralellisation ، من خلال المضيف ، وليس بواسطة المتغير.

نعم ، أفهم ، هذا ليس خطأ أنسيبل ، فمن المنطقي. لكني أستخدم Ansible كنظام بناء (بدلاً من إنشاء مثلاً) ، لأن Ansible رائع كنظام بناء في معظم النواحي. ولكن ، من وجهة نظري ، التفكير كنظام بناء ، "المضيفين" لا معنى له. نظام بناء مثل "make" لا يهتم بـ "hosts" ، إنه يهتم فقط بالملفات والمهام. أنا أجبر Ansible على استخدامه كنظام بناء ، وهذا يسبب القليل من التنافر المعرفي ، هذا كل شيء.

Ansible يهتم فقط بالمضيفين والمهام ، ضع في اعتبارك الصور التي تبنيها "مضيفين" وفجأة تناسب كلا النموذجين.

Ansible هي أداة لإدارة التكوين للعديد من الأشياء الأخرى ، والشبكات
الأجهزة ، الحقيقية والظاهرية ، مقابل قدر كبير من الخدمات السحابية مثل
قواعد البيانات وخدمات الويب مثل eleastic beanstalk و lambda وجميع
المكونات التي تنطبق عليه مثل مكونات أمان IAM ، بينما Ansible هو
جيد في المضيفين إذا كنت لا تزال تعمل في الغالب على أجهزة VM / تستضيفك بشكل أساسي في
أوائل 2000s تكنولوجيا المعلومات. لا تسيء إلى أي شخص هنا هناك مهمة في بعض الأحيان
أسباب تشغيل VMs أو حتى حاويات docker لكنها تعود جميعها إلى
أسباب موروثة. في الواقع ، سيصبح المزيد والمزيد من المضيفين أقل من
ما هو آلي. IMO إذا لم نقم بالتوازي مع العناصر ، فقد نقوم بذلك
حسنا الخردة ansible جميعا.

بعد قولي هذا ، سأفكر بشكل إيجابي هنا وأحاول استخدام
مندوب_تو لبعض الخدمات السحابية أعني أنني لم أحاول مطلقًا التنفيذ على 200+
مكونات السحابة التي أحتاجها بهذه الطريقة أعتقد فقط الاستعلام عن القائمة
وتفريغها في ملف hosts بتنسيق hosts مع ansible ، ثم حاول
مندوب_تو: localhost سأعلق نتائجي هنا. إذا كان يعمل في
على الأقل يمكننا تقديم طلب سحب وثائق حول كيفية حل المشكلة
with_item حلقة المسلسل القضايا بهذه الطريقة. يمكننا التأكد من أن يكون لديك رابط إلى
عليها في أقسام الوحدات السحابية وأقسام عامل الإرساء.

في يوم الاثنين ، 12 مارس 2018 الساعة 18:49 ، كتب Brian Coca [email protected] :

Ansible يهتم فقط بالمضيفين والمهام ، ضع في اعتبارك الصور التي أنت عليها
بناء "مضيفين" وفجأة تناسب كلا النموذجين.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

gjcarneiro ثم لا تعرفهم على أنهم بيانات ، وحددهم كمضيفين واستهدفهم ، ثم تفويض_to: localhost لتنفيذ الإجراءات بالتوازي

هذا أسلوب لطيف للغاية ولكن لا يبدو أنه يعمل داخل الحل البديل لإعادة التشغيل باستخدام محاكاة serial=1 (# 12170). لذا فإن خيار التعطيل سيضيف الكثير من المرونة.

لا شك أنه يضيف أيضًا طبقة ضخمة من التعقيد والحاجة للتعامل مع الإجراءات المتزامنة على مضيف واحد فقط hosts:all + lineinfile + delegate_to: localhost

لقد أنشأت حتى الآن اختبارًا صغيرًا لـ "مندوب_تو: 127.0.0.1 لـ
مهام الحذف لأن هذا يمثل أيضًا ألمًا على نطاق واسع.

يبدو كتيب التشغيل الخاص بي كما يلي:

• المضيفين: "{{DeploymentGroup}}"

  مهام:

  • الاسم: إزالة vm وجميع الموارد المرتبطة به
    آلة azure_rm_virtualmachine:
    Resource_group: "{{host_vars [العنصر] ['Resource_group']}}"
    الاسم: "{{stock_hostname}}"
    الدولة: غائب

  مندوب_إلى: 127.0.0.1

لسوء الحظ ، لا يزال يحاول الاتصال بالأجهزة المدرجة في المضيفين بـ
تنفيذ المهمة اللازوردية azure_rm_virtualmachine.
هل أفعل هذا بشكل صحيح؟ يبدو أنني أفتقد شيئًا ما ، لكنني حاولت ذلك
سابقًا بعدة طرق مختلفة ، لذا أريد فقط أن تعرف أنك قادر على القيام بذلك
هذه.

هل هذا في الواقع يعمل حتى؟ نأمل أن تكون هذه مجرد مشكلة في بناء الجملة.

يوم الإثنين ١٢ مارس ٢٠١٨ الساعة ٧:٥٥ مساءً ، إسحاق إيجلستون < [email protected]

كتب:

Ansible هي أداة لإدارة التكوين للعديد من الأشياء الأخرى ،
أجهزة الشبكات ، الحقيقية والظاهرية ، بكمية هائلة من السحابة
خدمات مثل قواعد البيانات وخدمات الويب مثل eleastic beanstalk و lambda
وجميع المكونات التي تنطبق عليه مثل مكونات أمان IAM ، بينما
يعد Ansible جيدًا في المضيفين إذا كنت لا تزال قيد التشغيل في الغالب على أجهزة VM / تستضيف ملف
بشكل أساسي في أوائل العقد الأول من القرن الحادي والعشرين في مجال تكنولوجيا المعلومات. لا يسيء إلى أي شخص هنا هناك في بعض الأحيان
أسباب مهمة لتشغيل VMs أو حتى حاويات docker لكنها كلها
العودة إلى الأسباب الموروثة. في الواقع المزيد والمزيد من المضيفين سيذهبون إلى
أصبح أقل مما يتم تشغيله تلقائيًا. IMO إذا لم نحصل على التوازي
with_items قد نلغى جميعًا معًا.

بعد قولي هذا ، سأفكر بشكل إيجابي هنا وأحاول استخدام
مندوب_تو لبعض الخدمات السحابية أعني أنني لم أحاول مطلقًا التنفيذ على 200+
مكونات السحابة التي أحتاجها بهذه الطريقة أعتقد فقط الاستعلام عن القائمة
وتفريغها في ملف hosts بتنسيق hosts مع ansible ، ثم حاول
مندوب_تو: localhost سأعلق نتائجي هنا. إذا كان يعمل في
على الأقل يمكننا تقديم طلب سحب وثائق حول كيفية حل المشكلة
with_item حلقة المسلسل القضايا بهذه الطريقة. يمكننا التأكد من أن يكون لديك رابط إلى
عليها في أقسام الوحدات السحابية وأقسام عامل الإرساء.

في يوم الاثنين ، 12 مارس 2018 الساعة 18:49 ، كتب Brian Coca [email protected] :

Ansible يهتم فقط بالمضيفين والمهام ، ضع في اعتبارك الصور التي أنت عليها
بناء "مضيفين" وفجأة تناسب كلا النموذجين.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

حسنًا ، يؤدي تعطيل جمع الحقائق إلى إصلاح هذه المشكلة ، مهما كانت أسبابها
واحد آخر ، لم يعد host_vars يحتوي على المخزون الديناميكي الأزرق من
قياسي في.

لذا Resource_group: "{{host_vars [item] ['Resource_group']}}" ليست كذلك
ما ورد أعلاه ويحتاج إلى ترميز ثابت لاسم مجموعة الموارد.

في الأحد ، 18 آذار (مارس) 2018 الساعة 11:14 صباحًا ، إسحاق إيجلستون <
[email protected]> كتب:

لقد أنشأت حتى الآن اختبارًا صغيرًا لـ "مندوب_تو: 127.0.0.1 لـ
مهام الحذف لأن هذا يمثل أيضًا ألمًا على نطاق واسع.

يبدو كتيب التشغيل الخاص بي كما يلي:

• المضيفين: "{{DeploymentGroup}}"

  مهام:

  • الاسم: إزالة vm وجميع الموارد المرتبطة به
    آلة azure_rm_virtualmachine:
    Resource_group: "{{host_vars [العنصر] ['Resource_group']}}"
    الاسم: "{{stock_hostname}}"
    الدولة: غائب

  مندوب_إلى: 127.0.0.1

لسوء الحظ ، لا يزال يحاول الاتصال بالأجهزة المدرجة في المضيفين بـ
تنفيذ المهمة اللازوردية azure_rm_virtualmachine.
هل أفعل هذا بشكل صحيح؟ يبدو أنني أفتقد شيئًا ما ، لكنني حاولت ذلك
سابقًا بعدة طرق مختلفة ، لذا أريد فقط أن تعرف أنك قادر على القيام بذلك
هذه.

هل هذا في الواقع يعمل حتى؟ نأمل أن تكون هذه مجرد مشكلة في بناء الجملة.

يوم الإثنين 12 آذار (مارس) 2018 الساعة 7:55 مساءً ، Isaac Egglestone <
[email protected]> كتب:

Ansible هي أداة لإدارة التكوين للعديد من الأشياء الأخرى ،
أجهزة الشبكات ، الحقيقية والظاهرية ، بكمية هائلة من السحابة
خدمات مثل قواعد البيانات وخدمات الويب مثل eleastic beanstalk و lambda
وجميع المكونات التي تنطبق عليه مثل مكونات أمان IAM ، بينما
يعد Ansible جيدًا في المضيفين إذا كنت لا تزال قيد التشغيل في الغالب على أجهزة VM / تستضيف ملف
بشكل أساسي في أوائل العقد الأول من القرن الحادي والعشرين في مجال تكنولوجيا المعلومات. لا يسيء إلى أي شخص هنا هناك في بعض الأحيان
أسباب مهمة لتشغيل VMs أو حتى حاويات docker لكنها كلها
العودة إلى الأسباب الموروثة. في الواقع المزيد والمزيد من المضيفين سيذهبون إلى
أصبح أقل مما يتم تشغيله تلقائيًا. IMO إذا لم نحصل على التوازي
with_items قد نلغى جميعًا معًا.

بعد قولي هذا ، سأفكر بشكل إيجابي هنا وأحاول استخدام
مندوب_تو لبعض الخدمات السحابية أعني أنني لم أحاول مطلقًا التنفيذ على 200+
مكونات السحابة التي أحتاجها بهذه الطريقة أعتقد فقط الاستعلام عن القائمة
وتفريغها في ملف hosts بتنسيق hosts مع ansible ، ثم حاول
مندوب_تو: localhost سأعلق نتائجي هنا. إذا كان يعمل في
على الأقل يمكننا تقديم طلب سحب وثائق حول كيفية حل المشكلة
with_item حلقة المسلسل القضايا بهذه الطريقة. يمكننا التأكد من أن يكون لديك رابط إلى
عليها في أقسام الوحدات السحابية وأقسام عامل الإرساء.

يوم الاثنين ، 12 مارس 2018 الساعة 18:49 ، Brian Coca [email protected]
كتب:

Ansible يهتم فقط بالمضيفين والمهام ، ضع في اعتبارك الصور التي أنت عليها
بناء "مضيفين" وفجأة تناسب كلا النموذجين.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

حسنًا ، لقد قمت بتعديل Playbook أدناه لتجربة عدد من الأشياء.

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

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

حتى الآن أرى استخدام هذا كحل بدلاً من موازٍ مع العناصر
حل يتضمن إمكانات ولكن الآلات المعنية لا تزال بحاجة إلى ذلك
يصل ويمكن الوصول إليه إذا كنت بحاجة إلى أي نوع من الحقائق من azure_rm.py أثناء قيامك
افعل هذا حتى يكون هناك تحذير واحد على الأقل هناك. هذا ما لم يعلم أحد
كيفية الوصول إلى host_vars من azure التي يتم تمريرها عبر Standard in
عندما تجمع الحقائق: لا

في الواقع لدي نفس المشكلة بالطبع عندما أقوم بتشغيل كل هذا باستخدام ملف
with_items list ، ومع ذلك كنت آمل في تجنب هذا الحل إذا كنت
ذاهب لاستخدام المضيفين مرة أخرى. العمل حول هو تفريغ azure_rm.py في ملف
json في سطر الأوامر ثم تحميله في متغير للحصول عليه
الوصول إليهم مرة أخرى.

إذا كنت أتطلع إلى هدفي النهائي هنا لتعديل المئات أو حتى الآلاف
من المكونات بدون خادم بالتوازي ، ربما يكون هذا على ما يرام قدر المستطاع
استخدم أشياء مثل azure_rm_functionapp_facts
http://docs.ansible.com/ansible/latest/azure_rm_functionapp_facts_module.html
ل
جمع الحقائق عنها واستخدامها في المسرحية نظريًا بالرغم من ذلك
لم يتم اختباره بعد.

ما زلت لا أملك أي منطق جيد حول كيفية القيام بذلك بشكل صحيح لإنشاء ملف
طلب سحب الوثائق حول هذا الموضوع لأن الطريقة تبدو حتى الآن إلى حد كبير
بناءً على ما تفعله ولست متأكدًا من أنني أريد أن أقترح استخدام
json تفريغ الإختراق في الوثائق.

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

• المضيفين: "{{DeploymentGroup}}"
  التجمع: لا
  مهام:
  
  
  
  • اقامة:
    
    collect_subset =! الكل ،! دقيقة
  
  
  • الاسم: إزالة vm وجميع الموارد المرتبطة به
    
    آلة azure_rm_virtualmachine:
    
    Resource_group: "{{host_vars [stock_hostname] ['Resource_group']
    
    }} "
    
    الاسم: "{{stock_hostname}}"
    
    الدولة: غائب
    
    مندوب_تو: مضيف محلي
    
    

    مندوب_حقائق: صحيح

  
  

يوم الأحد 18 مارس 2018 الساعة 12:04 مساءً ، إسحاق إيجلستون <
[email protected]> كتب:

حسنًا ، يؤدي تعطيل جمع الحقائق إلى إصلاح هذه المشكلة ، مهما كانت أسبابها
واحد آخر ، لم يعد host_vars يحتوي على المخزون الديناميكي الأزرق من
قياسي في.

لذا Resource_group: "{{host_vars [item] ['Resource_group']}}"
لا يعمل في ما ورد أعلاه ويحتاج إلى ترميز ثابت لمجموعة الموارد
اسم.

في الأحد ، 18 آذار (مارس) 2018 الساعة 11:14 صباحًا ، إسحاق إيجلستون <
[email protected]> كتب:

لقد أنشأت حتى الآن اختبارًا صغيرًا لـ "مندوب_تو: 127.0.0.1 لـ
مهام الحذف لأن هذا يمثل أيضًا ألمًا على نطاق واسع.

يبدو كتيب التشغيل الخاص بي كما يلي:

• المضيفين: "{{DeploymentGroup}}"

  مهام:

  • الاسم: إزالة vm وجميع الموارد المرتبطة به
    آلة azure_rm_virtualmachine:
    Resource_group: "{{host_vars [العنصر] ['Resource_group']}}"
    الاسم: "{{stock_hostname}}"
    الدولة: غائب

  مندوب_إلى: 127.0.0.1

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

هل هذا في الواقع يعمل حتى؟ نأمل أن تكون هذه مجرد مشكلة في بناء الجملة.

يوم الإثنين 12 آذار (مارس) 2018 الساعة 7:55 مساءً ، Isaac Egglestone <
[email protected]> كتب:

Ansible هي أداة لإدارة التكوين للعديد من الأشياء الأخرى ،
أجهزة الشبكات ، الحقيقية والظاهرية ، بكمية هائلة من السحابة
خدمات مثل قواعد البيانات وخدمات الويب مثل eleastic beanstalk و lambda
وجميع المكونات التي تنطبق عليه مثل مكونات أمان IAM ، بينما
يعد Ansible جيدًا في المضيفين إذا كنت لا تزال قيد التشغيل في الغالب على أجهزة VM / تستضيف ملف
بشكل أساسي في أوائل العقد الأول من القرن الحادي والعشرين في مجال تكنولوجيا المعلومات. لا يسيء إلى أي شخص هنا هناك في بعض الأحيان
أسباب مهمة لتشغيل VMs أو حتى حاويات docker لكنها كلها
العودة إلى الأسباب الموروثة. في الواقع المزيد والمزيد من المضيفين سيذهبون إلى
أصبح أقل مما يتم تشغيله تلقائيًا. IMO إذا لم نحصل على التوازي
with_items قد نلغى جميعًا معًا.

بعد قولي هذا ، سأفكر بشكل إيجابي هنا وأحاول استخدام
مندوب_تو لبعض الخدمات السحابية أعني أنني لم أحاول مطلقًا التنفيذ على 200+
مكونات السحابة التي أحتاجها بهذه الطريقة أعتقد فقط الاستعلام عن القائمة
وتفريغها في ملف hosts بتنسيق hosts مع ansible ، ثم حاول
مندوب_تو: localhost سأعلق نتائجي هنا. إذا كان يعمل في
على الأقل يمكننا تقديم طلب سحب وثائق حول كيفية حل المشكلة
with_item حلقة المسلسل القضايا بهذه الطريقة. يمكننا التأكد من أن يكون لديك رابط إلى
عليها في أقسام الوحدات السحابية وأقسام عامل الإرساء.

يوم الاثنين ، 12 مارس 2018 الساعة 18:49 ، Brian Coca [email protected]
كتب:

Ansible يهتم فقط بالمضيفين والمهام ، ضع في اعتبارك الصور التي أنت عليها
بناء "مضيفين" وفجأة تناسب كلا النموذجين.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ansible/ansible/issues/12086#issuecomment-372422169 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AJd59nhLIM3s3BL_xM_WwbJS6-uROzjSks5tdsNCgaJpZM4Fx8zF
.

لدي حالة استخدام للشوكات أيضًا ، مما يجعل ذلك أسهل كثيرًا. ينشر كتاب التشغيل مجموعة من مثيلات Openstack عبر terraform مع ips عائمة منتقاة عشوائيًا. ثم أكرر عبر ips للتحقق من أن المنفذ 22 مفتوح على كل مضيف تم إنشاؤه. الطريقة الحالية للقيام بذلك هي باستخدام كتاب اللعب المتعدد:

- hosts: localhost
  connection: local
  gather_facts: no
  tasks:
...
  - name: Run terraform
    terraform:
      plan_file: '{{tf_plan | default(omit)}}'
      project_path: '{{terraform_path}}/{{infra}}'
      state: '{{state}}'
      state_file: '{{stat_tfstate.stat.exists | ternary(stat_tfstate.stat.path, omit)}}'
      variables: '{{terraform_vars | default(omit)}}'
    register: tf_output

  - name: Add new hosts
    with_items: '{{tf_output.outputs.ip.value}}' # configued this in terraform to output a list of assigned ips.
    add_host:
      name: '{{item}}'
      groups: new_hosts

- hosts: new_hosts
  gather_facts: no
  connection: local
  tasks:
   - name: Wait for port 22 to become available
     wait_for:
       host: '{{ansible_host}}'
       port: 22
       state: started
       timeout: 60

يتم تشغيل هذا بـ: ansible-playbook -i localhost, deploy-test-clients.yml --extra-vars="infra=terraform_os_instances state=present"
يعد هذا بالطبع حلًا محدودًا نظرًا لأنه ليس لديك دائمًا قائمة ips قابلة للتحليل الدقيق للمخزون للعمل معها.

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

أكثر من 30 دقيقة لقالب 100 ملف يمكن إجراؤه في 5 ثوانٍ باستخدام jinja أمر مثير للسخرية.

يحدث قالب saplla دائمًا محليًا ، والشيء الوحيد الذي يحدث عن بُعد هو نسخ القالب وتعيين الأذونات.

فقط للتوضيح ، أنا أتحدث عن هؤلاء المستخدمين الذين يريدون إنشاء ملفات كمهام محلية ، على سبيل المثال لتغذية أنظمة بناء أخرى ، أو في حالتي ، لنشر موارد k8s باستخدام kubectl.

ما أعنيه هو تفريغ الحلقات والقوالب إلى jinja عبر وحدة عبارة عن غلاف بسيط. يمكن أن تأخذ الوحدة بعض السياق وتعريف الحلقة (ما يتم وضعه عادةً في with_nested والأصدقاء) وقطع فقط ansible بالكامل لهذه المهمة (ربما يمكن للغلاف تشغيل jinja بالتوازي إذا كان يسرع الأمور) .

يمكن استدعاءه على النحو التالي:

    template_parallel:
      src: "{{ item[0] }}"
      dest: "{{ tempdir }}/{{ item[1] }}-{{ item[0] | basename }}"
      context: "{{ hostvars[inventory_hostname] }}"
      nested:
      - "{{ templates.stdout_lines }}"
      - "{{ namespaces.stdout_lines }}"

يأخذ المثال أعلاه جميع المتغيرات المحددة بواسطة ansible على أنها سياق ، ولكن يمكن تمرير أي إملاء.

كما قلت ، ليس لدي الوقت للعمل على هذا الآن ، لكن هل يبدو النهج ممكنًا bcoca ؟

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

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

أيضًا ، القوالب متوازية بالفعل ، حسب المضيف ، وليس حسب العنصر.

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

سأحاول النظر إلى هذا عندما يصبح مشكلة بالنسبة لنا ، ما لم يضربني أحد.

لقد قدمت في الأصل # 10695 ، لكنني أدركت أن هذا سيستغرق بعض الوقت للالتقاء ، انتهى بي الأمر بمعالجة حالات الاستخدام هذه بنصوص شل (على سبيل المثال ، قل فقط أنه يتعين علي القيام بشيء ما على 50 Git repos على مضيف واحد ، فأنا أستخدم Ansible لتشغيل نص برمجي واحد مرة واحدة يفعل الشيء 50 مرة). لسوء الحظ ، هذا يعني التخلي عن بعض الأشياء التي تحصل عليها مجانًا مع Ansible ، مثل إعداد تقارير دقيقة للغاية عن التغيير ، وعليك أيضًا تنفيذ كل منطق "التشغيل فقط إذا" بنفسك وتوخي الحذر الشديد بشأن معالجة الأخطاء ، ولكن ذلك من المحتمل أن تكون أسرع بمقدار ضعفين. على هذا النحو ، حتى إذا انتهينا من الحصول على خيار "موازٍ" في المستقبل ، فقد لا يكون بنفس سرعة نصوصي المخصصة وربما لن أزعج نفسي بالتبديل إليه.

wincent من المحتمل أن تظل الحلقة المتوازية أبطأ دائمًا من برنامج نصي / برنامج مخصص ، لأن Ansible تفعل أكثر بكثير من مجرد "تطبيق الإجراء".

bcoca : نعم ، هذا يؤكد فهمي.

saplla k8s_raw أفضل من استخدام القالب لهذا ، يمكنك تضمين yaml في مخزونك إذا لزم الأمر :) (إنه ليس موضوع هذا العلاقات العامة)
ما هو الوضع الحالي حول هذا؟ هل يمكننا توقع شيء في 2.6bcoca ؟
أنا أدير الآلاف من امتيازات postgresql على مجموعات DB الخاصة بي و 25 دقيقة بطيئة بشكل مؤلم

nerzhul شكرا ولكن ليس أفضل بالنسبة لنا. الكثير من السحر. نحن بحاجة إلى قوالب.

sapila ، يمكنك دائمًا إنشاء هدف مضيف لكل قالب لموازنة القوالب قدر الإمكان ثم استخدام عمليات التشغيل أو التفويض التالي للتسليم إلى المضيفين الفعليين المناسبين.

bcoca قليلا مبتذل :)

ليس على الإطلاق ، إنه اختراق كبير ، ولكنه يعمل اليوم

إغلاق لصالح https://github.com/ansible/proposals/issues/140