كيفية نقل Home Assistant من حاوية واحدة إلى مجموعة خدمات مرنة

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

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

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

قبل تغيير البنية، سجّل صورة Home Assistant وإصدارها بدقة، ومسار الإعدادات، ومتغيرات البيئة، ووضع الشبكة، وتعيينات أجهزة USB، والمسارات المركّبة، ومنافذ المضيف. ثم أدرج كل ما يعتمد عليه Home Assistant خارج الحاوية: وسيط MQTT، وقاعدة البيانات، وZigbee2MQTT، والوكيل العكسي، وشبكة VPN، ونظام DNS، والشهادات، والنسخ الاحتياطية، وأي مشاركات شبكية. ستصبح هذه القائمة خريطة النقل.

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

افصل البيانات الدائمة عن الحاويات القابلة للاستبدال

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

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

أضف فحوصات الصحة وسياسة إعادة التشغيل وتبعيات بدء التشغيل بعناية

تجيب سياسة إعادة التشغيل عن سؤال: «ماذا ينبغي لبيئة التشغيل أن تفعل عند خروج هذه العملية؟» أما فحص الصحة فيجيب عن سؤال: «هل الخدمة جاهزة فعلًا للاستخدام؟» هذان سؤالان مختلفان. قد تكون حاوية قاعدة البيانات قيد التشغيل بينما لا تزال تعيد تشغيل السجلات، وقد يحتوي وسيط MQTT على عملية عاملة لكنه لا يقبل بعد مسار الاتصال الذي يتوقعه Home Assistant.

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

حدّد نطاقات الأعطال باستخدام الشبكات والموارد وترتيب الصيانة

لا تسمح لفحص الوسائط أو ترحيل قاعدة البيانات أو الحاوية التجريبية باستهلاك كل دورات وحدة المعالجة المركزية، أو كامل الذاكرة المتاحة، أو قرص التطبيقات بأكمله، بينما يُتوقع من Home Assistant أن يظل سريع الاستجابة. حدّد بوضوح متطلبات الموارد للخدمات المجاورة الثقيلة، وضع ذاكرات التخزين المؤقت القابلة للتخلص منها بعيدًا عن الحالة المهمة حيثما أمكن، وأبقِ مسار التحكم في Home Assistant على شبكة محلية مستقرة.

افصل ترتيب التحديثات أيضًا. غيّر طبقة واحدة في كل مرة: المضيف، ثم بيئة تشغيل الحاويات، ثم Home Assistant، ثم قاعدة البيانات، ثم الخدمات المرافقة الاختيارية. إذا جرى تحديث كل شيء في نافذة صيانة واحدة وفشلت الحزمة، فستفقد القدرة على تحديد الطبقة التي تسببت في التراجع. يوفر تصميم ZimaSpace لبنية Home Assistant التي تفصل أدوار الحوسبة والتخزين والنسخ الاحتياطي خريطة أوسع لأدوار الحوسبة والتخزين والشبكات والاستعادة.

لا تنتقل إلى التشغيل الفعلي إلا بعد نجاح اختبارات إعادة التشغيل والاستعادة

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

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

1. أنشئ لقطة أو نسخة احتياطية لحالة الحاوية الواحدة العاملة.
2. ارسم خريطة التبعيات وصنّف المكونات ذات الحالة والمكونات القابلة لإعادة البناء.
3. أنشئ مسارات دائمة وتعريفات خدمات صريحة.
4. أضف سياسات الصحة وإعادة التشغيل والموارد فقط عندما تعالج وضع فشل حقيقيًا.
5. اختبر التحكم المحلي، وأجهزة الاتصال اللاسلكي، وقاعدة البيانات، والمسار البعيد، وإعادة التشغيل الكاملة، والاستعادة.
6. أوقف الحاوية القديمة فقط بعد اجتياز الحزمة الجديدة جميع الاختبارات.

ليست النتيجة المرنة هي «المزيد من الخدمات»، بل حزمة يمكن فيها إعادة بناء Home Assistant دون فقدان الحالة، وتتعافى التبعيات بترتيب معروف، ولا تستطيع الخدمات المجاورة الثقيلة إنهاك طبقة التحكم، ويمكن عزل التحديث الفاشل بدل تحوله إلى لغز يؤثر في المنزل بأكمله.