تسريع أنسبل

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

نناقش هنا وأدناه Ansible 2.9.x ، والذي تم تثبيته في Virtualenv تم إنشاؤه حديثًا بالطريقة المفضلة لديك.

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

خطوط الأنابيب

حقيقة أنك بحاجة إلى استخدام خط الأنابيب ، أي ليس نسخ الوحدات النمطية إلى FS للنظام الهدف ، ولكن نقل أرشيف مضغوط ملفوف في Base64 مباشرة إلى stdin لمترجم Python ، يمكن لشخص ما أن يسمع بالفعل ، لكن شخصًا ما لم يستطع ، لكن الحقيقة تبقى: هذا الإعداد لا يزال الاستخفاف. لسوء الحظ ، أحد توزيعات Linux الشائعة المستخدمة في إعداد sudo ليس جيدًا بشكل افتراضي - لذلك كان هذا الأمر يتطلب tty (Terminal) ، لذلك ترك Ansible هذا الإعداد المفيد جدًا مغلقًا افتراضيًا.

pipelining = True

جمع الحقائق

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

gathering = smart|explicit

إعادة استخدام اتصالات ssh

إذا سبق لك تشغيل Ansible في وضع إخراج التصحيح (يتكرر الخيار "v" مرة إلى تسع مرات) ، فربما تكون قد لاحظت أن اتصالات ssh يتم إنشاؤها وإسقاطها باستمرار. لذا ، هنا أيضًا ، هناك بعض التفاصيل الدقيقة.

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

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

لإعادة استخدام اتصال ssh مفتوح بالفعل عند نقل الملفات إلى مضيف مُدار ، يكفي تحديد إعداد ssh_tranfer_method آخر غير معروف. التوثيق على هذا للغاية بخيل ومضللة ، لأن هذا الخيار يعمل تمامًا! لكن القراءة مصدر الرمز يسمح لك بفهم ما سيحدث بالضبط: سيتم تشغيل الأمر dd على المضيف المُدار ، والعمل مباشرةً مع الملف المطلوب.

transfer_method = piped

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

لا تخافوا من السكين ، تخافوا من الشوكة

إعداد مفيد آخر هو الشوك. يحدد عدد العمليات العاملة التي ستتصل في نفس الوقت بالمضيفين وتؤدي المهام. نظرًا لخصائص Python ، فإن العمليات ، وليس الخيوط ، هي التي تُستخدم كـ PL ، لأن Ansible لا يزال يدعم Python 2.7 - لا يوجد اتصال غير متزامن بالنسبة لك ، لا يوجد شيء يولد غير متزامن هنا! بشكل افتراضي ، يعمل Ansible خمسة العمال ، ولكن إذا طُلب منهم ذلك بشكل صحيح ، فسيتم إطلاق المزيد:

forks = 20

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

ضع كل شيء معا

نتيجة لذلك ، بالنسبة لـ ansible.cfg (ini-format) ، قد تبدو الإعدادات الضرورية كما يلي:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

وإذا كنت تريد إخفاء كل شيء في قائمة YaML العادية لشخص سليم ، فقد يبدو الأمر كالتالي:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

لسوء الحظ ، مع الإعدادات "التجمع = ذكي / صريح" و "forks = 20" لن يعمل هذا: لا توجد مكافئات YaML لها. إما أن نضعها في ansible.cfg ، أو نمررها عبر متغيرات البيئة ANSIBLE_GATHERING و ANSIBLE_FORKS.

حول ميتوجين
- وأين هو ميتوجين؟ أنت محق في السؤال ، عزيزي القارئ. لا مكان في هذا المقال. ولكن إذا كنت مستعدًا حقًا لقراءة الكود الخاص به ومعرفة سبب تعطل دفتر اللعب الخاص بك مع Mitogen ، ولكنه يعمل بشكل جيد مع Vanilla Ansible ، أو لماذا كان نفس الدليل يعمل بشكل صحيح حتى الآن ، ولكن بعد التحديث بدأ في القيام بأشياء غريبة - حسنًا ، من المحتمل أن يكون Mitogen هو أداتك. تطبيق وفهم وكتابة مقالات - سأقرأ باهتمام.

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

تم اكتشاف بعض هذه الإعدادات في عملية القراءة مصدر الرمز plugin'a اتصال تحت اسم المتحدث "ssh.py". أشارك نتائج القراءة على أمل أن تلهم شخصًا آخر للنظر في أكواد المصدر ، وقراءتها ، والتحقق من التنفيذ ، والمقارنة مع الوثائق - بعد كل شيء ، عاجلاً أم آجلاً ، كل هذا سيجلب لك نتائج إيجابية. حظ سعيد!

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

أي من إعدادات Ansible التالية تستخدمها لتسريع مشاريعك؟

  • 69,6%خطوط الأنابيب = true32

  • 34,8%التجمع = ذكي / صريح16

  • 52,2%ssh_args = "-o ControlMaster = auto -o ControlPersist = ..." 24

  • 17,4%طريقة النقل = الأنابيب 8

  • 63,0%الشوك = XXX29

  • 6,5%لا شيء من هذا ، فقط Mitogen3

  • 8,7%Mitogen + لاحظ أي من هذه الإعدادات 4

صوّت 46 مستخدمًا. امتنع مستخدم واحد عن التصويت.

هل تريد المزيد عن أنسبل؟

  • 78,3%نعم بالطبع 54

  • 21,7%نعم ، فقط أريد المزيد من الأشياء المتشددة!

  • 0,0%لا ، ولا تحتاجه مجانًا 0

  • 0,0%لا ، الأمر معقد aaaaaaa !!! 0

صوت 69 مستخدمين. امتنع 7 مستخدما عن التصويت.

المصدر: www.habr.com

إضافة تعليق