تجميع SSH وإعادة استخدام الاتصال

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

ينسخ Ansible وحدة إلى المضيف افتراضيًا، ويشغّلها، ثم ينظف الملفات. وتكلف كل خطوة جولة SSH ذهابًا وإيابًا يمكنكم غالبًا تجنبها.

مع pipelining، يبث Ansible الوحدة عبر جلسة SSH الحالية بدلًا من كتابة ملف مؤقت أولًا، مما يقلل عدد الاتصالات لكل مهمة.

تحتاج Pipelining إلى sudo من دون TTY، ولذلك يجب ألا يفرض ملف sudoers البعيد requiretty. لا تواجه التوزيعات الحديثة مشكلة، لكن قد تحتاج بعض التوزيعات المحصّنة إلى تعديل.

يبقي OpenSSH الخيار ControlPersist اتصالًا رئيسيًا مفتوحًا، ويوجّه المهام اللاحقة عبره، متجاوزًا عملية المصافحة الجديدة في كل مرة.

يتيح Ansible إعادة استخدام الاتصال عبر ssh_args. وتحدد قيمة ControlPersist المدة التي يظل فيها المقبس المشترك حيًا بعد آخر مهمة.

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

يعالج كل منهما تكلفة مختلفة: إذ يقلل pipelining جولات الذهاب والإياب داخل المهمة الواحدة، بينما يعيد ControlPersist استخدام جلسة SSH عبر مهام عديدة.

تتضافر ميزة Pipelining والاتصالات المستمرة. ويُعد تفعيل كليهما من أكبر تحسينات السرعة وأقلها مخاطرة التي يمكنكم تقديمها إلى playbook كبير.

إذا لم تكونوا بحاجة إلى الحقائق، فحدّدوا gather_facts: false لتخطي وحدة الإعداد. وبذلك تزيلون خطوة مكلفة من بداية كل play.

فعّلوا رد النداء profile_tasks لقياس مدة كل مهمة. فهو يوضح بالضبط أين تذهب الثواني، لكي تتأكدوا من أن ضبط الإعدادات حقق فائدة فعلية.

تريدون أن تتجنب كل مهمة كتابة ملف مؤقت قبل تشغيلها عبر SSH.

فعّلوا pipelining لتقليل جولات الذهاب والإياب، وControlPersist لإعادة استخدام جلسات SSH. ويقلل الجمع بينهما كثيرًا حمل الاتصالات في عمليات play الكبيرة. ⚡