هل يمكنك التراجع إلى إصدار سابق من صورة الحاوية دون فقدان بيانات التطبيق؟
نعم، يمكنك التراجع عن إصدار صورة حاوية دون فقدان بيانات التطبيق عندما تكون الحالة الدائمة خارج الحاوية وتظل متوافقة مع الإصدار الأقدم.
على أجهزة NAS المنزلية، تؤدي استبدال الصورة عادةً إلى إعادة إنشاء بيئة تشغيل التطبيق فقط، بينما تحتفظ وحدات التخزين المسماة أو عمليات الربط بالمسارات بقواعد البيانات والإعدادات وملفات المستخدمين. تكمن نقطة الخطر في تغيّر المخطط: فقد تنقل صورة أحدث قاعدة البيانات أو تعيد كتابة الإعدادات بطريقة لا يستطيع الإصدار الأقدم قراءتها. قبل التراجع، احفظ عمليات الربط الحالية، وهوية الصورة، والإعدادات، والأسرار، ونسخة احتياطية متسقة من البيانات.
جمّد الحالة الحالية قبل تغيير الصورة
أوقف تحديثات الصور التلقائية، وسجّل وسم الصورة الحالي، والبصمة غير القابلة للتغيير، وإعدادات الحاوية، ومتغيرات البيئة، والشبكات، والمنافذ، وعمليات الربط، وسياسة إعادة التشغيل، وفحص الحالة. احفظ ملف Compose أو الإعدادات المُصدَّرة بشكل منفصل عن الحاوية.
يوصي سير عمل التراجع عن حاويات NAS بالاحتفاظ بصورة سابقة معروفة بدلًا من الاعتماد على وسم متغير مثل latest. وتتمثل نقطة الاسترداد القابلة للاستخدام في إصدار الصورة السابق المحدد مع الإعدادات التي شغّلته.
أنشئ نسخة احتياطية أو لقطة متسقة للتطبيق من قاعدة البيانات قبل إيقاف الإصدار الأحدث. لا تفترض أن وحدة التخزين الحالية تمثل نسخة للتراجع، لأنها قد تحتوي بالفعل على تغييرات في المخطط أو البيانات أجراها التحديث.
تأكد من أن بيانات التطبيق موجودة خارج طبقة الكتابة
اربط كل وحدة تخزين مسماة وكل مسار مرتبط، ثم حدّد أي قاعدة بيانات أو ملفات مرفوعة أو إضافات أو شهادات أو ذاكرة تخزين مؤقت أو إعدادات لا تزال مخزنة داخل طبقة الكتابة في الحاوية فقط.
لا تبقى وحدة التخزين الدائمة بعد استبدال الحاوية إلا عندما تعيد الحاوية الجديدة الاتصال بالموقع الخارجي نفسه للبيانات. ويتحقق سير عمل تغيير إصدار الصورة في SynoForum صراحةً من أن بيانات وحدة التخزين تبقى على مساحة تخزين NAS قبل إعادة إنشاء حاوية من صورة أخرى.
إذا كانت بيانات مهمة موجودة في طبقة الكتابة فقط، فانْسخها أو صدّرها قبل إزالة الحاوية الحالية. تعامل مع هذا الاستخراج كخطوة استرداد، لا كسبب للاحتفاظ بحاوية غير مُرقّمة إلى أجل غير مسمى.
ثبّت إصدار الصورة الأقدم بدقة بدلًا من إعادة استخدام latest
نزّل أو حدّد الوسم أو البصمة لآخر إصدار معروف بأنه يعمل جيدًا، وحدّث مرجع الصورة فقط. تحقق من البنية، وإصدار التطبيق، ومتغيرات البيئة المطلوبة قبل إعادة إنشاء الخدمة.
عادةً ما يعود المستخدمون الذين يتراجعون عن خدمات مُدارة بواسطة Compose إلى إصدار صورة صريح سابق، بدلًا من مطالبة Docker بعكس حاوية قيد التشغيل في مكانها. ويركز نقاش عملي حول التراجع على تغيير وسم صورة Compose المثبّت وإعادة إنشاء الخدمة.
لا تستخدم صورة قديمة مخزنة مؤقتًا إذا كانت هويتها غير معروفة. سجّل البصمة بعد التنزيل حتى لا يختار إعادة إنشاء أخرى ملفًا ثنائيًا مختلفًا بصمت تحت الوسم المتغير نفسه.
تحقق مما إذا كان الإصدار الأحدث قد غيّر قاعدة البيانات
اقرأ ملاحظات إصدار التطبيق وسجلات الترحيل للإصدارات الواقعة بين الإصدار المستهدف للتراجع والصورة الحالية. ابحث عن تغييرات لا يمكن عكسها في المخطط، أو إعدادات أُعيدت كتابتها، أو تغييرات في مفاتيح التشفير، أو ترقيات للإضافات.
يُعد التراجع عن قاعدة البيانات أصعب من التراجع عن الصورة، لأن شفرة التطبيق والمخطط يجب أن يظلا متوافقين. وتوضح Octopus أن عمليات الترحيل المتوافقة مع الإصدارات السابقة تمثل متطلبًا عندما قد تتعايش إصدارات التطبيق القديمة والجديدة أو يجري عكسها، ما يجعل توافق المخطط بين الإصدارات هو الحد الفاصل الحاسم للتراجع.
إذا تعذّر على الصورة الأقدم قراءة قاعدة البيانات التي جرى ترحيلها، فاستعد نسخة قاعدة البيانات الاحتياطية السابقة للترقية بدلًا من توجيه الشفرة القديمة إلى الحالة الجديدة. واحتفظ بقاعدة البيانات الحالية بشكل منفصل تحسبًا للحاجة إلى عكس عملية التراجع نفسها.
أعد إنشاء الخدمة باستخدام المسارات الدائمة نفسها
أوقف حاوية التطبيق وأعد إنشاءها باستخدام الصورة الأقدم، مع الإبقاء على وحدات التخزين المسماة أو المسارات المرتبطة التي تم التحقق منها. لا تستخدم أوامر أو خيارات في الواجهة تؤدي إلى إزالة وحدات التخزين.
حافظ على أسماء الشبكات، والأسماء المستعارة للخدمات، والمنافذ المنشورة، وتعيينات UID/GID، والأسرار، وأهداف الوكيل العكسي متطابقة، ما لم يتطلب الإصدار الأقدم اختلافًا موثقًا. فقد يؤدي تشغيل حاوية بنجاح مع عمليات ربط خاطئة إلى إنشاء تطبيق جديد فارغ، بما يوحي بفقدان البيانات.
افحص قائمة عمليات الربط وسجلات التطبيق قبل تسجيل الدخول أو السماح بتشغيل المهام في الخلفية. إذا بدأ التطبيق بتهيئة قاعدة بيانات جديدة، فأوقفه فورًا وصحّح مسار البيانات بدلًا من الاستيراد إلى الموقع الخطأ.
تحقق من التراجع واحتفظ بمسار استرداد للتقدم
اختبر تسجيل الدخول، وقراءة قاعدة البيانات والكتابة إليها، وعمليات رفع الملفات، والمهام المجدولة، والتكاملات، وإعادة تشغيل مضبوطة واحدة. قارن عينة من السجلات والملفات بالمخزون السابق للتراجع.
يوفر سير عمل ZimaSpace الخاص بـ لقطات بيانات التطبيق قبل التحديث خطوة تحضير أكثر أمانًا للترقيات المستقبلية.
لا يكتمل التراجع إلا عندما تستخدم الصورة القديمة بيانات التخزين الدائمة المقصودة، ويكون المخطط متوافقًا أو مستعادًا، وتتمكن الخدمة من الصمود أمام إعادة إنشاء أخرى. احتفظ بالصورة الأحدث، ونسخة بياناتها الاحتياطية، وملاحظات التراجع حتى يظل الإصدار القديم مستقرًا خلال فترة التشغيل المعتادة.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكن لـ Plex مشاركة وحدة معالجة الرسومات (GPU) مع حاوية Docker أخرى؟
يمكن لـ Plex وحاوية أخرى غالبًا الوصول إلى وحدة معالجة الرسومات نفسها، لكن يجب اختبار دعم برنامج التشغيل، وتعيين الجهاز، وحِمل محرّك الفيديو، والذاكرة،...
كيفية معرفة ما إذا كان خطأ Plex ناتجًا عن العميل أم الخادم
أعِد إنتاج العنصر نفسه على عميل آخر، وقارن مسار الجلسة، ثم اجمع أدلة من الخادم فقط بعد أن يحدد النطاق موضع الفشل الفعلي.
كيفية إعداد ذاكرة التخزين المؤقت وموقع التخزين المؤقت لتحويل الترميز في Plex
احمِ حالة Plex الدائمة مع وضع الملفات المؤقتة للتحويل على مساحة تخزين محلية مناسبة، ثم تحقّق من التنظيف والمساحة الحرة وسلوك إعادة التشغيل.
