كيفية تحديد تبعية الحاوية التي تتسبب في حلقة إعادة التشغيل

إيفا وونغ

IceWhale author

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

How to Identify Which Container Dependency Is Causing a Restart Loop

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

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

اعثر على أول حاوية تتعطل، لا الحاوية الأعلى ضجيجًا

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

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

إذا تعطل أحد الاعتمادات أولًا، فابدأ بالتحقيق فيه قبل التطبيق. وإذا خرج التطبيق أولًا مع أخطاء رفض الاتصال أو انتهاء المهلة أو المصادقة أو فقدان ملف، فاربط الرسالة بالاعتماد المحدد الذي حاول استخدامه.

أوقف عاصفة إعادة التشغيل والتقط فشلًا واحدًا واضحًا

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

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

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

ارسم خريطة لكل اعتماد تحتاجه الحاوية لتصبح جاهزة

دوّن قاعدة البيانات وذاكرة التخزين المؤقت وقائمة انتظار الرسائل ومخزن الكائنات ومحلل DNS وموفر الهوية والملفات المحمّلة والأسرار وواجهات API الخارجية التي يتطلبها التطبيق. أدرج اسم الخدمة والمنفذ والبروتوكول واسم المستخدم وقاعدة البيانات والمسار المتوقعة.

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

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

اختبر كل اعتماد من شبكة الحاوية المتعطلة

استخدم حاوية تشخيص مؤقتة متصلة بالشبكة نفسها، أو شغّل صدفة مدعومة قبل خروج التطبيق. اختبر DNS الخاص باسم الخدمة، ومنفذ TCP، وTLS، والمصادقة، واستعلام قاعدة البيانات، والمسار المطلوب بهذا الترتيب.

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

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

تحقق من نقاط التحميل والأسرار وعمليات الترحيل باعتبارها اعتمادات

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

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

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

أعد تمكين الخدمات بترتيب الاعتمادات وتحقق من الاستقرار

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

يغطي دليل ZimaSpace حول أعطال DNS داخل الحاويات مسار اعتماد قد لا يظهر إلا داخل بيئة التطبيق.

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