تعريف Handlers وأنماط إعادة التشغيل

توضع handlers في قسم handlers الخاص بها داخل play، منفصلًا عن المهام العادية. وهذا يحافظ على تجميع الإجراءات التفاعلية بوضوح.

يستخدم handler الصياغة نفسها تمامًا التي تستخدمها المهمة: name واستدعاء module. والاختلاف الوحيد أنه ينتظر أن يُرسَل إليه إشعار.

إن name الخاص بـ handler هو السلسلة النصية التي تشير إليها المهام الأخرى في notify. تعاملوا معه كوسم ثابت ودقيق ستعيدون استخدامه.

يستخدم handler التقليدي لإعادة التشغيل وحدة service مع ضبط state على restarted. ويوقف الوحدة ثم يشغّلها في خطوة واحدة.

فضّلوا reloaded عندما تدعمها الخدمة. إذ تعيد إعادة التحميل قراءة الإعدادات دون قطع الاتصالات، بخلاف إعادة التشغيل الكاملة.

تمنح وحدة systemd تحكمًا أدق في المضيفين الذين يستخدمون systemd، بما في ذلك daemon_reload بعد تغيير ملف unit.

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

عند وضع عدة handlers في قائمة الانتظار، تُشغَّل وفق ترتيب تعريفها، لا وفق ترتيب إرسال الإشعارات إليها. خططوا لهذا التسلسل مسبقًا.

إذا كان يجب إجراء إعادة التحميل قبل إعادة التشغيل، فعرّفوهما بهذا الترتيب في قائمة handlers حتى تُنفَّذ قائمة الانتظار بشكل صحيح.

في role، توجد handlers في handlers/main.yml. وتُرسل المهام داخل role الإشعارات إليها بالاسم، تمامًا كما في ملف Playbook عادي.

استخدموا أسماء بصيغة أفعال مثل إعادة تشغيل nginx أو إعادة تحميل sshd. تجعل الأسماء الواضحة المخرجات سهلة القراءة، وتوضح أسطر notify.

غيّرتم إعدادًا وتريدون أن تلتقطه الخدمة قيد التشغيل دون قطع الاتصالات. ما الحالة الأفضل؟

يمكنكم الآن تعريف handlers في قسم handlers، والاختيار بين إعادة التشغيل وإعادة التحميل، والاعتماد على التنفيذ حسب ترتيب التعريف. 🎯