إشعار Handler عند حدوث تغيير

إعادة تشغيل خدمة في كل مرة تهدر الموارد وتنطوي على مخاطر. يتيح لكم handler إعادة تشغيلها فقط عندما يتغير شيء فعليًا.

إن handler ليس سوى مهمة تظل خاملة حتى تطلب منها مهمة عادية التشغيل. فكّروا فيه كإجراء ينتظر إشارة.

تصلون المهمة بـ handler باستخدام الكلمة المفتاحية notify. وتكون القيمة هي الاسم المطابق تمامًا لـ handler الذي تريدون تنبيهه.

يجب أن تطابق السلسلة النصية في notify اسم handler حرفيًا. ويعني أي خطأ إملائي أن handler لن يُشغَّل مطلقًا دون تنبيه واضح.

لا يُرسَل التنبيه إلى handler إلا عندما تُبلغ مهمته عن الحالة changed. فإذا كانت المهمة في الحالة المطلوبة أصلًا، فلن يُشغَّل شيء.

عندما تُرجع المهمة الحالة ok، يتجاوز Ansible notify بالكامل. ولهذا لا تؤدي عملية التشغيل الثانية عادةً إلى إعادة تشغيل أي شيء. ✅

يمكن لمهمة واحدة تنبيه عدة handlers من خلال إعطاء notify قائمة. ويُضاف كل handler مسمّى إلى قائمة الانتظار عندما تتغير المهمة.

لا يؤدي التنبيه إلى تشغيل handler فورًا. إذ يضعه Ansible في قائمة انتظار ثم يشغّله لاحقًا، بعد انتهاء مهام play.

إذا أرسلت خمس مهام إشعارًا إلى handler نفسه، فسيُشغَّل مرة واحدة فقط. إذ يزيل Ansible تلقائيًا إشعارات handler المكررة من قائمة الانتظار.

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

تغيّر مهمة ملفًا، ثم يضع notify إعادة التشغيل في قائمة الانتظار. تنتهي المهام، ثم يعيد handler تشغيل الخدمة. أسلوب نظيف ومختصر.

متى يُشغَّل handler الذي أُرسل إليه إشعار فعليًا؟

تعلّمتم أن notify يربط مهمةً بـ handler لا يعمل إلا عند حدوث تغيير. ويجب أن تتطابق الأسماء، كما يضع Ansible كل handler في قائمة الانتظار ليُشغَّل مرة واحدة فقط. 🚀