هل يمكنك تغيير المنفذ المنشور لحاوية دون إعادة بناء قاعدة بياناتها؟

نعم، يمكنك تغيير المنفذ المنشور للحاوية من دون إعادة إنشاء قاعدة بياناتها، ما دامت قاعدة البيانات موجودة على وحدة تخزين مستمرة موثّقة نفسها.

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

افصل بين منفذ المضيف المنشور والمنفذ الذي تستمع إليه الحاوية

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

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

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

احمِ مسار قاعدة البيانات الحالي قبل إعادة إنشاء الخدمة

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

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

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

غيّر تعيين المضيف فقط وأعد إنشاء خدمة التطبيق

عدّل خدمة التطبيق من تعيين مثل 8080:80 إلى 8081:80. أبقِ الصورة والمنفذ الداخلي ووحدات التخزين وعنوان قاعدة البيانات واسم الخدمة والشبكات وتعيين المستخدم دون تغيير، ما لم يوجد متطلب آخر تم التحقق منه.

يُفسَّر بناء جملة منافذ Compose من المضيف إلى الحاوية، لذلك يؤدي تغيير جانب المضيف إلى إبقاء العملية مستمعة على منفذها الداخلي الحالي. يوضح مثال في منتدى Docker سبب كون الجانب الأيسر هو منفذ المضيف، وضرورة استمرار تطابق الجانب الأيمن مع مستمع التطبيق.

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

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

حدّث كل مسار عميل يعتمد على المنفذ القديم

الإشارة المرجعية في المتصفح مجرد مستهلك واحد للمنفذ المنشور. فقد تظل الوكلاء العكسية، وإعادات توجيه الموجّه، وجدران الحماية المحلية، وفحوصات المراقبة، وتطبيقات الهاتف، ووجهات الويب هوك، وعمليات استدعاء OAuth، وقوائم السماح في CORS، وعناوين URL العامة المُنشأة تشير إلى نقطة النهاية السابقة.

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

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

أبقِ قاعدة البيانات على مسار الحاوية الخاص بها

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

قد يؤدي الخلط بين نقطة النهاية العامة للتطبيق واتصال قاعدة البيانات إلى انقطاع ثانٍ: فقد يُوجَّه التطبيق إلى عنوان NAS ومنفذ مضيف، رغم أن قاعدة البيانات يفترض أن تبقى على شبكة Docker خاصة. يضيف هذا التغيير متغيرات تتعلق بجدار الحماية وNAT والمصادقة، من دون أن يساعد المتصفح على الوصول إلى خدمة الويب.

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

تحقّق من المنفذ الجديد من دون المساس بالبيانات المستمرة

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

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

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