Docker / أسس الصور والحاويات / الدرس 4

عمر العملية والمعاملات والإغلاق

فسر بدء الحاوية وبقاءها وإيقافها وخروجها قبل تغيير سياسة الإعادة.

وقت القراءة التقريبي: 3 دقيقةتاريخ مراجعة المحتوى 2026-10-25

في هذه الصفحة

أهداف الدرس

تتبّع معاملات التنفيذ وعمر العملية الرئيسية.
فسر أدلة الخروج والإشارات وحدود الإغلاق المتدرج.

تحدد العملية الرئيسية عمر الحاوية

تبقى الحاوية عاملة عادة ما دامت عمليتها الرئيسية حية. قد ينتهي أمر قصير بنجاح ويترك حاوية خارجة؛ وليس ذلك انهياراً بالضرورة. يبقى parcel-api في المقدمة عبر serve_forever. تشغيل daemon خلفي ثم خروج الصدفة يقطع العلاقة. وضح العملية المطلوبة بدلاً من إضافة sleep لا نهائية لا صلة لها بالخدمة.

تشكل ENTRYPOINT و CMD عقد معاملات

تستخدم التعليمات التنفيذية مصفوفات JSON. قد تثبت ENTRYPOINT الملف التنفيذي ومعاملاته الأولى، وتقدم CMD افتراضيات قابلة للاستبدال. دون ENTRYPOINT يستبدل أمر التشغيل الصريح CMD. تضيف الصيغة الصدفية تحليلاً وتوسيعاً يؤثران في الاقتباس والإشارات. اقرأ قائمة المعاملات النهائية ولا تفترض أن النصوص المتشابهة تنفذ بالطريقة نفسها.

dockerfile حقلا أمر بديلان للمثال القائم

ENTRYPOINT ["python", "-u"]
CMD ["app.py"]

الناتج المتوقع

Default argv: ["python", "-u", "app.py"]

يستبدل الحقلان اختيار CMD وحده في Dockerfile السابقة الكاملة، وتظل بقية الوصفة لازمة. دون معاملات تشغيل يصبح الأمر python -u app.py. تقديم -m http.server 8080 يستبدل معاملات CMD مع إبقاء Python فيشغل برنامجاً آخر.

اقرأ الحالة قبل تخمين السبب

افحص هل الكائن منشأ أو يعمل أو يعيد التشغيل أو خرج، ثم اربط الأوقات والرمز والسجلات. يعني الصفر عادة نجاح العملية لا استمرار خدمة HTTP. يدل غير الصفر على فشل لا سبب موحد. قد يتصل 137 بـ SIGKILL؛ فافحص OOMKilled والأحداث ولا تعتبره دائماً نفاد ذاكرة.

bash ربط الحالة والمعاملات والسجلات

docker container inspect parcel-api --format '{{json .State}}'
docker container inspect parcel-api --format '{{json .Path}} {{json .Args}}'
docker logs --tail 50 parcel-api

يفحص حاوية موجودة مصرحاً بها ولا يعيد تشغيلها. تعتمد الرموز والسجلات على الحادثة فلا نختلقها. يكشف Path و Args تجاوز الأمر حتى لو بدا إعداد الصورة صحيحاً. سجل الوقت واحجب المخرجات الحساسة.

الإغلاق المتدرج سلوك تطبيق

يرسل الإيقاف المعتاد الإشارة المحددة، وغالباًSIGTERM في Linux، ثم ينتظر مهلة قبل الإنهاء القسري. تزيل الصيغة التنفيذية صدفة زائدة لكنها لا تكتب معالجات إشارات أو تفريغ طلبات. ينبغي وقف العمل الجديد وإنهاء الجاري أو إلغاؤه ضمن حد وحفظ الحالة والخروج. يجب أن تلائم المهلة ذلك ومهلة المشرف الخارجي.

سياسة الإعادة ليست آلية إصلاح

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

الأخطاء الشائعة وإصلاحها

تخرج الحاوية فوراً بالرمز 0.

لماذا يحدث؟: انتهى الأمر الرئيسي أو وضع الخادم في الخلفية ثم خرج.
كيف تصلحه؟: شغل العملية المقصودة في المقدمة وتحقق من المعاملات.
كيف تتجنب تكراره؟: حدد هل الصورة خدمة أم مهمة محدودة.

exec: executable file not found in $PATH.

لماذا يحدث؟: الملف غائب أو خطأ اسمه أو خارج PATH.
كيف تصلحه؟: افحص محتوى الصورة والمجلد والمسار قبل البناء.
كيف تتجنب تكراره؟: طابق أمر البدء مع الصورة النهائية لا مرحلة البناء.

يصل الإغلاق دائماً إلى الإنهاء القسري.

لماذا يحدث؟: قد لا تصل الإشارة أو يتجاوز التفريغ المهلة.
كيف تصلحه؟: صحح معالجة الإشارة وحدد مهلة مبررة.
كيف تتجنب تكراره؟: تدرب على الإغلاق أثناء العمل وافحص أدلته.

اختبر فهمك

1. هل تجعل restart: always إعداداً خاطئاً موثوقاً؟

اعرض الحل المشروح

لا؛ تكرر العملية الفاشلة وقد تنشئ حلقة. احفظ الخطأ الأول وصحح الإعداد بإجراء النشر واستبدل الحاوية إن لزم. تأتي الموثوقية من بدء صحيح وتعاف محدود لا كثرة المحاولات.

2. لماذا لا يكفي 137 لتشخيص نفاد الذاكرة؟