- استخدام سياسات إعادة التشغيل الأصلية لـ Docker للتعامل مع أعطال النظام.
- تنفيذ البرامج النصية المخصصة و cron للحاويات ذات الحالات غير الصحية.
- تكامل متقدم مع نظام systemd للتحكم في تسلسل بدء التشغيل والإيقاف.
- بدائل وأدوات المراقبة الخارجية مثل Podman Quadlet.
أنا متأكد من أن هذا قد حدث لك: لديك خدمة تعمل في عامل ميناء والتي، لأسباب غامضة، تتعطل كل بضعة أيام. كيفية إعادة تشغيل حاوية Docker تلقائيًا عندما تتوقف عن الاستجابة؟ من المحبط محاولة تحسين الكود أو الإعدادات دون جدوى، ثم اكتشاف أن إعادة تشغيل الجهاز يدويًا تحل المشكلة وتُبقي كل شيء يعمل لأسبوع آخر. بدلًا من التحقق من الوقت باستمرار، الحل الأمثل هو إعداد نظام يقوم بهذه المهمة نيابةً عنك.
إدارة توافر الحاويات لا تقتصر فقط على ضمان بدء تشغيلها تلقائيًا عند تشغيل الخادم. تأكد من استجابتهم بشكل صحيح استجابةً للطلبات. في بعض الأحيان، يبدو أن الحاوية "نشطة" بالنسبة لـ Docker، لكن التطبيق الموجود بداخلها لا يستجيب، مما يجبرنا على البحث عن حلول تتراوح من معلمات البرنامج الأساسية إلى إنشاء خدمات معقدة في نظام التشغيل.
سياسات إعادة التشغيل الأصلية لـ Docker
أبسط طريقة لإعادة تشغيل حاوية Docker تلقائيًا هي استخدام العلامة --restart عند تشغيل حاوية أو استخدام الأمر docker update إذا كانت الحاوية قد تم إنشاؤها بالفعل، فإن Docker يوفر عدة خيارات حسب احتياجاتك. على سبيل المثال، السياسة دائماً سيؤدي هذا إلى إعادة تشغيل الحاوية دائمًا، بغض النظر عما إذا كانت العملية قد انتهت بخطأ أو ما إذا كان برنامج Docker daemon نفسه هو الذي أعيد تشغيله.
إذا كنت تفضل إجراءً جراحياً أكثر، ما لم يتم إيقافها هذا هو الخيار الأمثل للكثيرين. هذا التكوين مطابق للتكوين السابق، باستثناء أنه في حال إيقاف الحاوية يدويًا للصيانة، لن يحاول Docker تشغيله. يتم ذلك تلقائيًا بعد إعادة تشغيل الخادم، مع مراعاة قرارك اليدوي.
أما بالنسبة لأولئك الذين يرغبون فقط في التصرف استجابةً للإخفاقات الجسيمة، فهناك عند الفشللا تُفعّل هذه السياسة إعادة التشغيل إلا إذا انتهى الحاوية برمز خروج غير صفري. يمكنك حتى تقييد ذلك بإضافة حد أقصى لعدد محاولات إعادة التشغيل، مما يمنع النظام من الدخول في حلقة إعادة تشغيل لا نهائية إذا كان الخطأ مستمرًا وحرجًا.

أتمتة الحاويات "غير الصحية"
هنا تبدأ الأمور تصبح مثيرة للاهتمام. في بعض الأحيان، لا يزال يظهر الحاوية على أنها "مفعلة" (مُشغّلة)، لكن حالتها الصحية غير واضحة. غير صحي لأنها تفشل في عمليات التحقق الداخلية. السياسات السابقة غير فعالة هنا، لأن العملية لم تتوقف تقنيًا. لحل هذه المشكلة، يمكننا تطبيق التوجيه التالي: الفحص الصحي في ملف Dockerfile أو في ملف Docker Compose، يتم تحديد أمر (مثل curl إلى منفذ محدد) للتحقق من استجابة التطبيق.
بمجرد الانتهاء من إعداد الفحص الصحي، يمكننا إنشاء نص باش يتم تشغيل ذلك كل بضع دقائق باستخدام crontab من نظام لينكس. يجب أن يقوم هذا البرنامج النصي بتصفية الحاويات التي تكون في حالة unhealthy أو أولئك الذين خرجوا برمز الخطأ 128 وقاموا بتشغيل docker restart عنهم.
لكي يعمل هذا بسلاسة ويعيد تشغيل حاوية Docker تلقائيًا، من الضروري أن يكون لدى المستخدم الذي يقوم بتشغيل مهمة cron الأذونات اللازمة. الأذونات المطلوبة في مجموعة Dockerوبهذه الطريقة، يراقب النظام البيئة كل 5 أو 10 دقائق ويعيد تشغيل أي خدمة أصبحت "معطلة"، مما يضمن توفرًا شبه كامل دون تدخل بشري.
تكامل متقدم مع نظام systemd
عند العمل في بيئات أكثر احترافية، قد ترغب في أن تتصرف حاوياتك مثل خدمات لينكس الأصليةدمج عامل ميناء يُتيح لك نظام Systemd إدارة التبعيات المعقدة، مثل ضمان بدء تشغيل قاعدة البيانات قبل تطبيق الويب. ويتم ذلك عن طريق إنشاء ملفات .service في الطريق /etc/systemd/system/.
يمكننا تصميم تسلسل إيقاف التشغيل وتشغيل الطاقة يتم التحكم بها. باستخدام نصوص برمجية مخصصة مرتبطة بنظام systemd، من الممكن إيقاف الحاويات بترتيب عكسي لتبعياتها لمنع تلف البيانات. باستخدام النوع oneshot وتكوين targets مناسب (مثل multi-user.target o shutdown.targetيتولى الخادم إدارة دورة حياة الحاوية بالكامل.
يُعد استخدام العلامة خيارًا قويًا آخر لإعادة تشغيل حاوية Docker تلقائيًا عند توقفها عن الاستجابة. --rm بالاشتراك مع نظام systemd. يسمح هذا بإزالة الحاوية عند الإيقاف وإنشاء حاوية جديدة من الصورة الأساسية عند بدء التشغيل، مما يضمن أن يجب أن تكون حالة الحاوية نظيفة وغير متغيرة دائماً.تفويض حفظ البيانات بشكل كامل إلى وحدات التخزين الخارجية.

الأدوات الخارجية والبدائل الحديثة
إذا كنت لا ترغب في عناء كتابة نصوص باش، فهناك أدوات خارجية متاحة. توجد تطبيقات مفتوحة المصدر مصممة خصيصًا لإعادة تشغيل الحاويات بناءً على الجدول الزمني المحدديُعدّ هذا مفيدًا جدًا للمهام المتكررة مثل تجديد شهادات SSL. وبالمثل، فإن أدوات مثل وقت التشغيل كوما تتيح لك هذه الأدوات مراقبة حالة الخدمات من خلال لوحة تحكم مرئية، وإرسال إشعارات إلى تيليجرام أو جوتيفاي في حال حدوث أي مشكلة. كما أنها مفيدة للغاية لإعادة تشغيل حاوية دوكر تلقائيًا عند توقفها عن الاستجابة.
لأولئك الذين يبحثون عن بديل أخف أو محلي، بودمان إنه خيار ممتاز. بفضل بنيته التي لا تتطلب برامج مساعدة ووظائفه الرباعييتيح لك ذلك إنشاء ملفات تعريفية بسيطة يقوم نظام systemd بتحويلها تلقائيًا إلى خدمات محسّنة، مما يوفر تكاملًا أكثر سلاسة من Docker التقليدي.
إن امتلاك السيطرة الكاملة على دورة حياة خدماتك يتطلب الجمع بين استخدام سياسات إعادة التشغيلالمراقبة المستمرة من خلال الفحوصات الطبية وفي الحالات الأكثر تعقيدًا، دعم نظام systemd أو أدوات المراقبة بحيث تكون بنيتك التحتية قوية ولا تعتمد على شخص ما يتذكر إعادة تشغيل الخادم يدويًا كل أسبوع.
محرر متخصص في قضايا التكنولوجيا والإنترنت بخبرة تزيد عن عشر سنوات في الوسائط الرقمية المختلفة. لقد عملت كمحرر ومنشئ محتوى لشركات التجارة الإلكترونية والاتصالات والتسويق عبر الإنترنت وشركات الإعلان. لقد كتبت أيضًا في مواقع الاقتصاد والمالية والقطاعات الأخرى. عملي هو أيضا شغفي. الآن من خلال مقالاتي في Tecnobits، أحاول استكشاف كل الأخبار والفرص الجديدة التي يقدمها لنا عالم التكنولوجيا كل يوم لتحسين حياتنا.