الحالة المطلوبة، لا البرامج النصية خطوة بخطوة

Ansible تصريحي: تصف الحالة النهائية التي تريدها، ويحدد Ansible الخطوات اللازمة للوصول إليها بدءًا من حالة المضيف الحالية.

يسرد البرنامج النصي الإجرائي أوامر محددة بالترتيب. وهو يفترض حالة بداية معينة، لذلك يفشل إذا كان المضيف قد أُعد جزئيًا بالفعل.

تحدد المهمة التصريحية الهدف فقط: يجب أن يكون nginx مثبتًا ويعمل. يفحص Ansible الواقع ولا يتصرف إلا عند الحاجة.

يُعد المفتاح state المكان الذي تعلن فيه نيتك. يحدد كل من present وstarted وabsent حالة نهائية مرغوبة، وليس إجراءً مطلوبًا تنفيذه.

قبل تغيير أي شيء، يقارن أحد الوحدات الحالة الحالية بالحالة التي أعلنتها. وإذا كانتا متطابقتين بالفعل، فلن يفعل شيئًا على الإطلاق.

يدفع كل تشغيل المضيف نحو الحالة التي أعلنتم عنها. هذا هو التقارب: فبغضّ النظر عن نقطة البداية، ينتهي المضيف في المكان نفسه.

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

المهام التصريحية آمنة عند إعادة تشغيلها. وتبقى المضيفات المطابقة مسبقًا دون تغيير، وهذا هو الأساس الكامل لـ idempotency.

لن تعودوا إلى كتابة فحوصات «إذا كان مثبتًا فتخطّه» يدويًا. يتولى module هذا المنطق، ولذلك يبقى playbook الخاص بكم قصيرًا وسهل القراءة.

يبدو playbook التصريحي كأنه توثيق لـالحالة المطلوبة للخادم: ما الحزم والخدمات والملفات التي ينبغي أن تكون موجودة عليه.

تُعدّ مهام command وshell الخام إجرائية؛ فهي تعمل في كل مرة. فضّلوا modules المعتمدة على الحالة حتى يحافظ Ansible على نهجه التصريحي.

تكتبون مهمة تنص على أن nginx يجب أن يكون موجودًا، ثم تشغّلون playbook على مضيف يحتوي nginx مسبقًا.

تعلنون عن الحالة المطلوبة ويقرّب Ansible المضيف منها، ولا يتدخل إلا عندما يختلف الواقع عنها. هذه السلامة هي idempotency. 🎯