لماذا يكسر command قابلية التكرار
مشكلة Shell الخام وكيفية تجنبها
لماذا يكسر command قابلية التكرار درس مجاني في Ansible Academy على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Ansible Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Ansible Academy 4 دروس في المجموع.
تعمل command دائمًا
تكتفي وحدة command بتشغيل ما تعطونها إياه على المضيف. فهي لا تعرف كيف تبدو حالة «الاكتمال»، ولذلك تعمل في كل مرة دون استثناء.
ansible.builtin.command: useradd deployتكون النتيجة دائمًا changed
لأن command لا يستطيع فحص الحالة، يبلّغ Ansible عن changed في كل تشغيل، حتى عندما لا ينفّذ الأمر أي شيء جديد فعليًا.
changed: [web1]قد تسبّب إعادة التشغيل ضررًا
والأسوأ أن بعض الأوامر تفشل أو تكرر العمل عند تشغيلها مرة أخرى، مثل useradd الذي يصدّر خطأً لأن المستخدم موجود مسبقًا.
فضّلوا module المعتمدة على الحالة
بالنسبة إلى المستخدمين، استخدموا module user بدلًا من ذلك. فهي تتحقق من وجود الحساب ولا تنشئه إلا عند غيابه، وتحافظ بذلك على idempotency.
ansible.builtin.user:
name: deploy
state: presentتوجد عادةً module مخصّصة
لدى معظم مهام shell الشائعة module مخصّصة: file وcopy وlineinfile وgit. استخدموها حتى يتمكن Ansible من المقارنة والتخطي عندما تكون الحالة صحيحة.
احموا command باستخدام creates
إذا اضطررتم إلى استخدام command، فأضيفوا creates. سيتخطى Ansible المهمة عندما يكون المسار موجودًا مسبقًا، وبذلك يستعيد idempotency.
ansible.builtin.command: ./build.sh
args:
creates: /opt/app/builtأو احموها باستخدام removes
نظير creates هو removes: لا يعمل الأمر إلا إذا كان المسار المحدد لا يزال موجودًا، وهذا مفيد لخطوات التنظيف.
ansible.builtin.command: rm /tmp/lock
args:
removes: /tmp/lockقيّدوا command باستخدام when
يمكنكم أيضًا وضع command داخل شرط when يعتمد على فحص مسجّل، بحيث يعمل فقط عندما تكون هناك حاجة حقيقية إليه.
أخبروا Ansible أنه لم يفعل شيئًا
اضبطوا changed_when: false على command للقراءة فقط حتى يتوقف Ansible عن الإبلاغ عنه باعتباره changed في كل تشغيل.
ansible.builtin.command: cat /etc/hostname
changed_when: falseلدى shell المشكلة نفسها
تشترك module shell في هذا العيب. فهي تعمل عبر shell، ولذلك تفتقر هي أيضًا إلى idempotency ما لم تحموها بالطريقة نفسها.
اعتبروا الأوامر الخام خيارًا أخيرًا
يُعدّ command الخام وسيلة للخروج عن القاعدة، وليس خيارًا افتراضيًا. فكل استخدام له يمثل موضعًا قد تتعطل فيه idempotency بصمت، لذا لا تلجؤوا إليه إلا عندما لا تناسبكم أي module.
اختبار سريع
استخدمتم command لتشغيل script بناء، وهو يعرض changed في كل تشغيل دون استثناء.
خلاصة
تعمل وحدتا command وshell دائمًا وتبلّغان دائمًا عن changed. فضّلوا modules الحقيقية، أو احموها باستخدام creates أو removes أو changed_when. 🛡️
الأسئلة الشائعة
هل درس «لماذا يكسر command قابلية التكرار» مجاني؟
نعم — نص درس «لماذا يكسر command قابلية التكرار» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Ansible Academy، انتقل إلى CoddyKit PRO. تتضمن دورة Ansible Academy 4 دروس في المجموع.
ماذا ستتعلم في «لماذا يكسر command قابلية التكرار»؟
مشكلة Shell الخام وكيفية تجنبها تتمرن على Ansible Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Ansible Academy؟
لا تُشترط خبرة سابقة. Ansible Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.
كم من الوقت يستغرق درس «لماذا يكسر command قابلية التكرار»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Ansible Academy هذا؟
نعم. كل درس في Ansible Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- الحالة المطلوبة، لا البرامج النصية خطوة بخطوة
- قراءة changed مقابل ok في المخرجات
- لماذا يكسر command قابلية التكرار
- وضع الفحص: تشغيل تجريبي باستخدام --check