كيفية حل مشكلة تطبيق مستضاف ذاتيًا يستمر في استخدام سرّ قديم
يستمر التطبيق المستضاف ذاتيًا في استخدام سر قديم عندما لا تكون القيمة التي غيّرتها هي القيمة نفسها التي حمّلها فعليًا التطبيق قيد التشغيل.
على الخادم المنزلي، يمكن أن توجد كلمة المرور أو رمز API أو مفتاح التشفير نفسه في بيئة Compose أو ملف بيئي أو ملف سر مُحمّل أو واجهة إدارة الحاويات أو قاعدة البيانات الدائمة الخاصة بالتطبيق. لا تكفي إعادة تشغيل العملية عندما لا تكون الحاوية قد أُعيد إنشاؤها، أو عندما يخزّن التطبيق الإعدادات داخليًا، أو عندما تظل خدمة ثانية تُصادق باستخدام بيانات الاعتماد القديمة. تتبّع السر من مصدره إلى العملية قبل حذف وحدات التخزين أو تدويره مرة أخرى.
أثبت أن الحاوية قيد التشغيل لا تزال تحتوي على القيمة القديمة
ابدأ بتحديد بصمة آمنة واحدة للسر بدلًا من طباعة السر نفسه. قارن بين المصدر المُكوَّن، وبيئة الحاوية قيد التشغيل أو ملف السر المُحمّل، وسجل التطبيق أو فشل الاتصال الذي يثبت بيانات الاعتماد التي يحاول التطبيق استخدامها.
يوضح مقال عن استكشاف أخطاء Compose وإصلاحها أن إعادة التشغيل تُبقي الإعدادات القديمة لأن إعادة التشغيل تعيد استخدام إعدادات الحاوية الحالية بدلًا من مواءمة تعريف الخدمة المُغيَّر.
إذا كانت الحاوية قيد التشغيل تعرض البصمة الجديدة بالفعل، فتوقف عن إلقاء اللوم على إعدادات Docker وانتقل إلى مستوى التطبيق، حيث قد تكون الإعدادات محفوظة، أو إلى الخدمة البعيدة التي تتحقق من السر. أما إذا كانت لا تزال تعرض البصمة القديمة، فأبقِ الإصلاح في طبقة النشر.
تتبّع مصدر السر الذي يقرأه التطبيق فعليًا
حدّد كل مصدر محتمل لبيانات الاعتماد: متغير بيئة مضمن في Compose، و.env، وenv_file، وملف مُحمّل، وسر Docker أو Podman، وملف إعدادات التطبيق، وواجهة إدارة الحاويات، وأي معالج إعداد أولي حفظ القيمة في وحدة تخزين دائمة.
يفصل دليل عملي لإعداد Compose بين الإعدادات المُحمّلة والأسرار، وهو أمر مفيد عندما لا يكون ملف البيئة الذي عدّلته هو المصدر الذي يقرأ منه التطبيق حاليًا.
غيّر المصدر الموثوق لهذا النشر فقط. قد يؤدي تعديل ثلاث نسخ دفعة واحدة إلى تشغيل التطبيق بنجاح، مع عدم ترك أي دليل يوضح أي مصدر قديم تسبب في المشكلة.
أعِد إنشاء الخدمة عندما يكون السر جزءًا من إعدادات الحاوية
إذا حُقنت بيانات الاعتماد في متغير بيئة للحاوية أو في سر لا يتم تجسيده إلا عند إنشاء الحاوية، فأعِد إنشاء الخدمة المتأثرة مع الحفاظ على وحدات التخزين الدائمة. قد تترك عملية الإيقاف والتشغيل البسيطة تعريف الحاوية الأصلي دون تغيير.
يشير مثال لتدوير الأسرار في Podman إلى أن تدوير السر يُحدّث الخدمات بعد استبدال السر، ما يجعل دورة حياة الحاوية خطوة منفصلة عن تحديث مخزن الأسرار.
أعِد إنشاء الخدمة المستهلكة فقط أولًا. لا تزل وحدات التخزين المسماة أو أدلة قواعد البيانات إلا إذا كان التطبيق يخزن بيانات الاعتماد القديمة هناك صراحةً، وكان لديك نسخة احتياطية تم التحقق منها.
تحقق من وجود إعدادات دائمة للتطبيق تتجاوز البيئة
تتعامل بعض التطبيقات المستضافة ذاتيًا مع متغيرات البيئة باعتبارها إعدادات افتراضية للاستخدام الأول، ثم تحفظ إعدادات قابلة للتحرير في قاعدة بيانات أو دليل بيانات التطبيق. في هذا التصميم، قد تكون قيمة البيئة الجديدة صحيحة بينما يحتفظ التطبيق عمدًا بالقيمة المخزنة.
افحص إعدادات الإدارة المدعومة في التطبيق أو قاعدة بيانات الإعدادات قبل تعديل الملفات يدويًا. إذا أدى تغيير الإعداد المخزن إلى تفعيل السر الجديد، فوثّق هذا الإعداد باعتباره المصدر الموثوق لعمليات التدوير المستقبلية.
تحقق مما إذا كان التطبيق يحمّل ملف سر بدلًا من ذلك
قد ينتقل التطبيق من متغير البيئة إلى ملف سر مُنشأ أو مُحمّل. لذلك قد تبدو إعادة إنشاء الحاوية ناجحة، بينما تظل العملية تقرأ ملفًا أقدم من وحدة تخزين دائمة.
يوضح أحد أمثلة تثبيت Open WebUI أن التطبيق يحمّل ملف سر محفوظًا في عمليات التشغيل اللاحقة، ما يوضح سبب ضرورة التحقق من مسار الملف الفعلي بشكل مستقل عن ملف YAML الخاص بـ Compose.
تحقق من مسار الملف ووقت تعديله ومالكه وبصمته الآمنة. استبدله فقط عبر الطريقة التي يدعمها التطبيق، لأن مفاتيح التشفير والأسرار المستخدمة للتوقيع قد تبطل الجلسات أو تجعل البيانات المشفرة مسبقًا غير قابلة للقراءة.
دوّر المستهلك والمزوّد كمعاملة واحدة
لكلمة مرور قاعدة البيانات أو رمز API أو بيانات اعتماد الخدمة جانبان: التطبيق الذي يقدّمها والمزوّد الذي يتحقق منها. يؤدي تحديث جانب واحد فقط إلى فشل في المصادقة قد يُفهم خطأً على أنه احتفاظ التطبيق بقيمة قديمة في ذاكرته المؤقتة.
يوضح سير عمل لتحديث الأسرار أن على التطبيقات إعادة تحميل الأسرار المُدوَّرة عبر إعادة التشغيل أو الإشارة أو سلوك إعادة تحميل خاص بالتطبيق، بدلًا من افتراض أن العملية تلاحظ تلقائيًا كل تغيير في الملفات.
تحقق من إجراء مصادقة حقيقي واحد، ثم أعد تشغيل الخدمة أو أعد إنشاءها مرة أخرى، واختبرها مجددًا. يكتمل الإصلاح عندما يصمد الاعتماد الجديد بعد إعادة الإنشاء ويُرفض الاعتماد القديم. ويُعد دليل ZimaSpace ذي الصلة حول تطبيق مستضاف ذاتيًا يفشل مسار API فيه هو الخطوة التالية عندما يُحمَّل السر الجديد لكن تظل الطلبات تفشل.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكن لـ Plex مشاركة وحدة معالجة الرسومات (GPU) مع حاوية Docker أخرى؟
يمكن لـ Plex وحاوية أخرى غالبًا الوصول إلى وحدة معالجة الرسومات نفسها، لكن يجب اختبار دعم برنامج التشغيل، وتعيين الجهاز، وحِمل محرّك الفيديو، والذاكرة،...
كيفية معرفة ما إذا كان خطأ Plex ناتجًا عن العميل أم الخادم
أعِد إنتاج العنصر نفسه على عميل آخر، وقارن مسار الجلسة، ثم اجمع أدلة من الخادم فقط بعد أن يحدد النطاق موضع الفشل الفعلي.
كيفية إعداد ذاكرة التخزين المؤقت وموقع التخزين المؤقت لتحويل الترميز في Plex
احمِ حالة Plex الدائمة مع وضع الملفات المؤقتة للتحويل على مساحة تخزين محلية مناسبة، ثم تحقّق من التنظيف والمساحة الحرة وسلوك إعادة التشغيل.
