لماذا يكسر command قابلية التكرار

تكتفي وحدة command بتشغيل ما تعطونها إياه على المضيف. فهي لا تعرف كيف تبدو حالة «الاكتمال»، ولذلك تعمل في كل مرة دون استثناء.

لأن command لا يستطيع فحص الحالة، يبلّغ Ansible عن changed في كل تشغيل، حتى عندما لا ينفّذ الأمر أي شيء جديد فعليًا.

والأسوأ أن بعض الأوامر تفشل أو تكرر العمل عند تشغيلها مرة أخرى، مثل useradd الذي يصدّر خطأً لأن المستخدم موجود مسبقًا.

بالنسبة إلى المستخدمين، استخدموا module user بدلًا من ذلك. فهي تتحقق من وجود الحساب ولا تنشئه إلا عند غيابه، وتحافظ بذلك على idempotency.

لدى معظم مهام shell الشائعة module مخصّصة: file وcopy وlineinfile وgit. استخدموها حتى يتمكن Ansible من المقارنة والتخطي عندما تكون الحالة صحيحة.

إذا اضطررتم إلى استخدام command، فأضيفوا creates. سيتخطى Ansible المهمة عندما يكون المسار موجودًا مسبقًا، وبذلك يستعيد idempotency.

نظير creates هو removes: لا يعمل الأمر إلا إذا كان المسار المحدد لا يزال موجودًا، وهذا مفيد لخطوات التنظيف.

يمكنكم أيضًا وضع command داخل شرط when يعتمد على فحص مسجّل، بحيث يعمل فقط عندما تكون هناك حاجة حقيقية إليه.

اضبطوا changed_when: false على command للقراءة فقط حتى يتوقف Ansible عن الإبلاغ عنه باعتباره changed في كل تشغيل.

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

يُعدّ command الخام وسيلة للخروج عن القاعدة، وليس خيارًا افتراضيًا. فكل استخدام له يمثل موضعًا قد تتعطل فيه idempotency بصمت، لذا لا تلجؤوا إليه إلا عندما لا تناسبكم أي module.

استخدمتم command لتشغيل script بناء، وهو يعرض changed في كل تشغيل دون استثناء.

تعمل وحدتا command وshell دائمًا وتبلّغان دائمًا عن changed. فضّلوا modules الحقيقية، أو احموها باستخدام creates أو removes أو changed_when. 🛡️