متى تنشئ Module مخصّصة

توفّر Ansible آلاف الوحدات، لكن لا تناسب احتياجك أحيانًا أيٌّ منها. وهنا تحديدًا تثبت فائدة الوحدة المخصصة.

تحقق دائمًا من Galaxy والوثائق أولًا. فقد تكون هناك مجموعة مجتمعية تغلّف واجهة البرمجة الغامضة تلك، فلا تكتب أي شيفرة.

إذا كان playbook لديك مليئًا باستدعاءات command وshell التي تحلل المخرجات، فهذه إشارة. يمكن لوحدة أن تخفي تلك الفوضى خلف معاملات واضحة.

تُبلغ مهام shell الخام عن حدوث تغيير في كل تشغيل. أما الوحدة الحقيقية فتتحقق من الحالة الحالية أولًا، فتمنحك idempotency التي لا يمكن لـ shell توفيرها.

ربما تشغّل أداة داخلية أو واجهة REST API لا توجد لها وحدة بعد. وتحول الوحدة المخصصة ذلك التكامل إلى مهمة واحدة مرتبة وقابلة لإعادة الاستخدام.

تذكّر أن الوحدة تُنفّذ على العقدة المُدارة، لا على جهاز التحكم. لذلك يجب أن تكون Python وأي مكتبات لازمة موجودة على المضيف البعيد.

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

ضع ملفًا واحدًا في مجلد library بجوار playbook، وستعثر عليه Ansible تلقائيًا. لا حاجة إلى إنشاء حزمة للبدء.

تُكتب معظم الوحدات باستخدام Python لأن Ansible توفر لك مكتبة مساعدة لها. تعمل اللغات الأخرى، لكنها تفتقر إلى هذا الدعم.

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

تتبع كل وحدة عقدًا: تستقبل المعاملات بصيغة JSON، وتنفذ العمل، ثم تُرجع النتائج بصيغة JSON. أتقن ذلك، وستتمكن من بناء أي شيء.

فكّر في ما يبرر حقًا كتابة وحدتك الخاصة.

أنشئ وحدة مخصصة فقط بعد البحث، عندما تحتاج إلى عمل idempotent قابل لإعادة الاستخدام لا يمكن لـ shell والوحدات المدمجة توفيره. وحافظ على تركيزها. 🛠️