كيفية مواءمة سياسات إعادة تشغيل Docker مع قواعد البيانات والعاملين وتطبيقات الويب

طابِق سياسات إعادة تشغيل Docker مع دورة حياة الخدمة ودلالات الخروج، بدلًا من تعيين unless-stopped لكل حاوية في ملف Compose.

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

افصل سلوك إعادة التشغيل عن الصحة والجاهزية

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

تشرح مقالة الصحة وإعادة التشغيل منفصلتان لعام 2026 هذا الفصل، وتوضح كيف يمكن لشروط صحة Compose تأخير بدء الخدمات التابعة حتى تصبح الخدمة جاهزة فعليًا.

لا تتوقع أن تصلح restart: always عملية ويب غير سليمة لا تخرج أبدًا، ولا تتوقع أن يعيد فحص الصحة وحده تشغيلها. اجعل التطبيق يخرج عندما يصبح الاستمرار غير آمن، أو أضف آلية معالجة خارجية، أو أطلق تنبيهًا عند الحالة غير السليمة وفقًا لتصميم الخدمة.

استخدم سياسات إعادة تشغيل مستمرة لقواعد البيانات طويلة التشغيل

عادةً ما يُتوقع من قاعدة بيانات الخادم المنزلي أن تعود إلى العمل بعد إعادة تشغيل المضيف أو عفريت Docker. وغالبًا ما تكون unless-stopped خيارًا افتراضيًا عمليًا عندما ينبغي احترام إيقاف المسؤول المتعمد؛ بينما تكون always مناسبة عندما يُفترض أن تتجاوز إعادة التشغيل حالة الإيقاف اليدوي تلك.

توضح مقالة سياسة إعادة التشغيل تتبع خروج العملية في يوليو 2026 الفرق بين no وon-failure وalways وunless-stopped، بما في ذلك أن السياسة تستجيب لخروج العملية لا لحالة الصحة.

تحتاج قاعدة البيانات أيضًا إلى فحص صحة فعلي وتخزين دائم. لا يمكن لإعادة تشغيل PostgreSQL مرارًا إصلاح قرص ممتلئ، أو إعداد غير صالح، أو حالة تالفة، أو عملية ترحيل غير متوافقة. أطلق تنبيهًا عند تكرار عمليات إعادة التشغيل بدلًا من اعتبارها قدرة ناجحة على الصمود.

اختر سياسة العامل بناءً على دلالات قائمة الانتظار والخروج

قد يستحق عامل قائمة الانتظار طويل التشغيل unless-stopped إذا كان ينبغي له الاستمرار دائمًا في استهلاك المهام. ويمكن لعملية العامل المحدودة أو العملية الدفعية استخدام on-failure:N كي تتلقى الأخطاء المؤقتة عددًا محدودًا من المحاولات، بينما يتوقف الفشل المستمر بوضوح.

تؤكد مقالة محاولات on-failure المحدودة الحالية أن سلوك إعادة المحاولة ينبغي أن يتوافق مع ما إذا كان من المفترض أن تبقى العملية حية دائمًا أو يُسمح لها بالانتهاء بصورة طبيعية.

اعرف معنى رمز الخروج 0 لصورة العامل. فإذا كان يعني «اكتملت المهمة»، فقد تحول always مهمة ناجحة تُنفذ مرة واحدة إلى حلقة لا نهائية. أما إذا كان العامل مصممًا ليكون عفريتًا، فقد يظل الخروج غير المتوقع بصورة سليمة مبررًا للعودة التلقائية عبر unless-stopped.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

أبقِ تطبيقات الويب طويلة التشغيل، لكن اربط بدءها بالتبعيات الفعلية

صُممت معظم تطبيقات الويب المستضافة ذاتيًا لتظل متاحة باستمرار، لذا يكون unless-stopped عادةً أسهل في الفهم من سياسة محدودة تقتصر على حالات الفشل. ولا يلغي إعداد إعادة التشغيل ضرورة جاهزية قاعدة البيانات، وذاكرة التخزين المؤقت، وDNS، والأسرار، والمسارات المركبة.

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

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

امنح عمليات الترحيل والمهام التي تُنفذ مرة واحدة دورة حياة محدودة

حاويات الترحيل، وأدوات الاستيراد، ومهام الصيانة، ومهام التهيئة لمرة واحدة ليست عفاريت عادية. وغالبًا ما تكون حالة نجاحها هي «الخروج بالرمز 0 والبقاء متوقفة». وقد تؤدي استخدامات always أو unless-stopped إلى إعادة تنفيذ العمل المكتمل دون قصد.

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

استخدم restart: "no" عندما ينبغي أن يتوقف الفشل للفحص، أو استخدم on-failure المحدودة فقط عندما يكون الأمر آمنًا لإعادة المحاولة. وبالنسبة إلى عمليات ترحيل المخطط، تحقّق من أن تكرار عملية ترحيل مطبقة جزئيًا مدعوم قبل أتمتة إعادة المحاولات.

اختبر السياسة باستخدام حالات فشل حقيقية

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

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

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