هل يمكنك استعادة حاوية واحدة دون استبدال حزمة التطبيق بأكملها؟

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

نعم، يمكن استعادة حاوية واحدة بشكل مستقل عندما يكون تكوينها وبياناتها الدائمة وحدود تبعياتها منفصلة بوضوح عن بقية المكدس.

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

حدّد وحدة الاستعادة قبل إيقاف أي شيء

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

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

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

التقط حالة المكدس السليم وحالة الخدمة المتعطّلة

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

يمكن لعملية على مستوى الخدمة في Compose استهداف خدمة مُسمّاة واحدة بدلًا من إعادة تشغيل كل شيء. يميّز سير عمل Linux Handbook لخدمة واحدة خدمة Compose واحدة عن الإجراءات التي تشمل المكدس بأكمله، لكنه يشير أيضًا إلى أن تغييرات التكوين تتطلب إعادة الإنشاء، لا مجرد إعادة التشغيل.

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

استعد البيانات في موقع معزول أولًا

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

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

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

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

أعد إنشاء الخدمة المتعطّلة فقط مع الحفاظ على هويتها الأصلية

أعد إنشاء الخدمة المُسمّاة من تعريف Compose المحفوظ، مع الحفاظ على اسم المشروع نفسه، والشبكات الخارجية، والأسماء المستعارة للخدمة، والمنافذ، والأسرار، وتعيين UID/GID، والمسارات الدائمة التي تم التحقق منها.

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

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

أعد توصيل التبعيات دون استعادتها

اختبر تحليل DNS والوصول عبر TCP من الحاوية المستعادة إلى قاعدة بياناتها وذاكرة التخزين المؤقت وموفّر الهوية ومخزن الكائنات وشبكة الوكيل. استخدم أسماء الخدمات وبيانات الاعتماد نفسها المحددة في التكوين المستعاد.

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

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

تحقّق من حدود الخدمة الواحدة قبل إعادة توجيه حركة المرور

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

يقدّم دليل ZimaSpace حول ربط حالة الحاوية الدائمة المبدأ نفسه للاستعادة: استعد مالك الحالة، لا غلاف حاوية مفترضًا.

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

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.