كيفية تشغيل وكيل Hermes على خادم منزلي دون فقدان البيانات

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

الإجابة السريعة

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

أسلم طريقة عمل للمبتدئين هي:

  1. حدد بيانات Hermes Agent التي يجب أن تبقى محفوظة.
  2. اختر مجلد مضيف مخصص أو وحدة تخزين تُدار بواسطة Docker.
  3. قم بتعيين هذا التخزين إلى مسار الحاوية الصحيح.
  4. تأكد من أن مستخدم التطبيق يمكنه الكتابة إليه.
  5. قم بعمل نسخة احتياطية من التكوين المهم قبل التحديثات أو إعادة البناء.
  6. أعد التشغيل وتحقق من أن التكوين والسجلات والملفات المُولدة وإعدادات البوابة لا تزال موجودة.

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

لماذا يمكن أن تختفي بيانات Hermes Agent في إعداد الحاوية

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

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

إعادة تشغيل الحاويات مقابل بيانات التطبيق الدائمة

إعادة تشغيل الحاوية العادية لا تزيل البيانات دائمًا. إذا تم تخزين البيانات في وحدة تخزين دائمة أو مجلد مضيف معين بشكل صحيح، يجب أن تظل متاحة بعد إعادة التشغيل.

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

لماذا يمكن أن يؤدي حذف أو إعادة إنشاء الحاوية إلى فقدان الحالة غير المحفوظة

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

إذا لم تُكتب إعدادات Hermes Agent أو المهارات أو السجلات أو المخرجات المُولدة في مجلد مضيف دائم أو وحدة تخزين، فقد لا تنتقل مع الحاوية الجديدة. لهذا السبب يمكن أن يكون كلا القولين صحيحين: "التطبيق كان يعمل بالأمس" و"التطبيق أعيد ضبطه بعد التحديث".

العادة الآمنة هي اعتبار استبدال الحاوية حدثًا محفوفًا بالمخاطر للبيانات ما لم تؤكد مكان تخزين بيانات التطبيق.

لماذا يجب التخطيط لمسارات المضيف ومسارات الحاوية أولاً

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

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

خطط للتخطيط قبل تشغيل التطبيق، وليس بعد فقدان البيانات.

ما البيانات التي يجب حمايتها قبل تشغيل وكيل Hermes؟

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

قاعدة مفيدة هي: احمِ أي شيء يخزن الهوية، الوصول، التكوين، سير العمل المتعلم، أو المخرجات التي لا يمكنك إعادة توليدها بسهولة.

تكوين الوكيل وإعدادات مزود النموذج

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

خزن تكوين النموذج في مسار بيانات تطبيق دائم، وليس في جلسة شل مؤقتة. إذا تم توفير التكوين عبر متغيرات البيئة، احتفظ بنسخة آمنة من ملف التركيب، ملف البيئة، أو ملاحظات النشر.

احمِ أيضًا أي اختيارات إعداد تحدد كيفية استخدام الوكيل لأدوات الطرفية أو بوابات الرسائل.

ذاكرة التطبيق، الجلسات، المهارات، وحالة وقت التشغيل

يمكن أن تتضمن بيانات وكيل Hermes أكثر من ملف تكوين واحد. يشرح هيكل بيانات مهارات Hermes أن المهارات تعيش في ~/.hermes/skills/، وهو المصدر الأساسي للحقيقة للمهارات المجمعة، المثبتة من المركز، والمُنشأة بواسطة الوكيل. كما يصف الحالة المرتبطة مثل بيانات الحزم المجمعة، حزم المهارات، تكوين مركز التوصيل، الكتابات المعلقة للمهارات، وإعدادات التكوين.

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

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

التنزيلات، الملفات المُنشأة، السجلات، ومخرجات الأدوات

الملفات المُنشأة سهلة التغاضي عنها. قد ينشئ الوكيل خططًا، أو نصوصًا، أو تقارير، أو لقطات شاشة، أو سجلات، أو ملفات تم تنزيلها أثناء الاستخدام العادي.

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

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

مفاتيح API، رموز البوت، ومتغيرات البيئة

الأسرار ليست بيانات تطبيق عادية. مفاتيح API، رموز البوت، كلمات مرور لوحة التحكم، ومتغيرات البيئة تحتاج إلى كل من الاستمرارية والحماية.

لا تحفظ الأسرار في مجلدات ناتجة عشوائية أو مجلدات مشتركة واسعة. احتفظ بها في مسار تكوين مُتحكم فيه مع وصول محدود.

يجب أن يجيب إعداد التعامل مع الأسرار الجيد على:

  • أين يُخزن السر؛
  • أي مستخدم يمكنه قراءته؛
  • ما إذا كان مشمولًا في النسخ الاحتياطية؛
  • ما إذا كان النسخ الاحتياطي مشفرًا أو محكومًا بالوصول؛
  • كيف يمكن تدوير السر إذا تم كشفه.

مسار المضيف مقابل مسار الحاوية مقابل تركيب الأحجام

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

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

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

ما يخزنه خادم المضيف

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

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

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

ما يمكن أن تراه الحاوية

يرى الحاوية نظام الملفات الداخلي الخاص بها وأي مسارات تم تركيبها. لا يرى تلقائيًا كل مجلد على خادمك المنزلي.

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

هذه هي الفكرة الأساسية: لا يهتم التطبيق بمكان وجود الملف على المضيف ما لم يتم تركيبه في المسار الذي يستخدمه التطبيق.

كيف تحافظ تركيبات الحجم على استمرارية بيانات التطبيق

يوفر التركيب المستمر للتطبيق مكانًا ثابتًا لكتابة البيانات يتجاوز عمر الحاوية الواحدة. بالنسبة لبيانات التطبيق، غالبًا ما يكون هذا الفرق بين "آمن لإعادة التشغيل" و"لمدة عمر الحاوية فقط".

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

يجب أن يحدد الإعداد المستمر الجيد:

  • مجلد المضيف أو الحجم المسمي؛
  • مسار الهدف داخل الحاوية؛
  • ما إذا كان التركيب للقراءة والكتابة أو للقراءة فقط؛
  • أي بيانات التطبيق تنتمي هناك؛
  • كيفية نسخ المسار احتياطيًا.

لماذا يسبب تعيين المسار الخاطئ أخطاء في المجلد المفقود

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

الأعراض الشائعة تشمل:

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

عندما يحدث هذا، تحقق من مسار المضيف ومسار الحاوية معًا. لا تفحص جانبًا واحدًا فقط.

كيفية تشغيل Hermes Agent دون فقدان البيانات

الهدف ليس فقط تشغيل Hermes Agent. الهدف هو التأكد من بقاء البيانات التي تهتم بها بعد إعادة التشغيل أو التحديث أو إعادة البناء أو إعادة التكوين.

الخطوة 1: اختر مجلد بيانات مضيف مخصص

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

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

يجب أن يكون مجلد بيانات المضيف العملي:

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

الخطوة 2: تركيب مجلد البيانات داخل الحاوية

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

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

لا تفترض أن التطبيق سيستخدم المجلد المركب تلقائيًا. تأكد من أن الهدف المركب يطابق مسار بيانات التطبيق الفعلي.

الخطوة 3: تأكد من أن الحاوية تستخدم مسار بيانات التطبيق المتوقع

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

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

هذه الخطوة مهمة بشكل خاص قبل التحديثات أو الترحيل.

الخطوة 4: تحقق من ملكية الملف وأذونات الكتابة

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

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

إذا رأيت رفض الأذونات، حدد:

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

الخطوة 5: احتفظ بالأسرار وملفات التكوين خارج المسارات القابلة للإزالة

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

تجنب خلط الأسرار مع السجلات أو الملفات المُنشأة. قد تُشارك السجلات لأغراض استكشاف الأخطاء، بينما يجب ألا تُشارك الأسرار بشكل عشوائي.

إذا قمت بعمل نسخة احتياطية من الأسرار، فاحمِ النسخة الاحتياطية. النسخة الاحتياطية التي تكشف عن مفاتيح API أو رموز الروبوت تخلق نوعًا مختلفًا من المخاطر.

الخطوة 6: أعد تشغيل الحاوية وتحقق من استمرار وجود البيانات

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

لا تتوقف عند "بدء الحاوية". تأكد من:

  • تظل إعدادات النموذج موجودة؛
  • تظل المهارات أو حالة التطبيق مرئية؛
  • تستمر السجلات في المكان المتوقع؛
  • تظهر الملفات المُنشأة على المضيف؛
  • تظل إعدادات البوابة أو الروبوت تعمل؛
  • يمكن تحديد موقع ملفات النسخ الاحتياطي.

الإعداد الذي يجتاز التحقق من إعادة التشغيل أكثر أمانًا بكثير من الذي اجتاز التثبيت الأول فقط.

الأذونات والنسخ الاحتياطية وحدود السلامة

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

لماذا تهم أذونات مستخدم الحاوية

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

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

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

لماذا يجب تجنب تشغيل كل شيء كجذر

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

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

النمط الأكثر أمانًا هو أقل امتياز: امنح التطبيق حق الكتابة فقط على المجلدات التي يحتاجها.

متى تستخدم التوصيلات للقراءة فقط أو المجلدات المحدودة

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

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

تصميم المجلد المحدود يقلل من تأثير الأخطاء. كما يجعل النسخ الاحتياطية أسهل لأنك تعرف أي مجلد يحتوي على حالة التطبيق وأي مجلد يحتوي على المخرجات المُنشأة.

كيفية نسخ بيانات الوكيل احتياطيًا قبل التحديثات أو إعادة التكوين

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

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

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

المشاكل الشائعة وكيفية إصلاحها

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

لا يمكن للحاوية العثور على مجلد موصول

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

تحقق بهذا الترتيب:

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

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

إعادة تعيين بيانات التطبيق بعد إعادة التشغيل

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

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

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

أخطاء رفض الإذن في دليل البيانات

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

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

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

الملفات المولدة محفوظة داخل الحاوية فقط

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

قرر أين يجب أن تهبط الملفات المولدة. ثم قم بتركيب مجلد الإخراج هذا أو قم بتكوين التطبيق للكتابة إلى موقع دائم موجود.

بعد تغيير المسار، أنشئ ملف اختبار غير ضار وتأكد من ظهوره على المضيف.

اختفاء إعدادات الروبوت أو البوابة بعد إعادة التكوين

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

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

إذا كان الروبوت يعمل قبل إعادة التشغيل لكنه لا يعمل بعدها، ركز على الاستمرارية وتكوين البيئة قبل تغيير الرمز المميز.

كيفية التحقق مما إذا كانت بيانات وكيل Hermes آمنة

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

الإعداد يستمر بعد إعادة التشغيل

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

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

تظهر السجلات والملفات المُنشأة في مجلد المضيف المتوقع

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

تحقق من كلا جانبي نقطة التوصيل. يجب أن يتفق المضيف والحاوية بشأن الملفات المهمة.

يمكن للوكيل الكتابة إلى بيانات التطبيق بدون أخطاء أذونات

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

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

يمكن تحديد موقع ملفات النسخة الاحتياطية واستعادتها

النسخة الاحتياطية غير مكتملة حتى تتمكن من تحديد موقعها واستعادتها إلى موقع اختبار. على الأقل، تأكد من أن النسخة الاحتياطية تحتوي على البيانات التي كنت تنوي حمايتها.

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

لوحة التحكم أو الوصول إلى الرسائل لا يزال يعمل بعد إعادة التشغيل

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

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

كيف يعمل هذا في بيئة خادم منزلي حقيقية

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

على سبيل المثال، يُظهر سير إعداد وكيل ZimaOS Hermes مسارًا محددًا للجهاز يتضمن تكوين مزود النموذج، وإعداد بوابة Telegram، والدخول إلى حاوية Hermes، وتفعيل بيئة التطبيق، والتحقق من لوحة التحكم على الويب، واستكشاف مشكلات الأذونات أو استجابة الروبوت.

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

الدرس العام قابل للنقل: قبل أن تثق في وكيل محاط بالحاوية للعمل المفيد، تأكد من أن بياناته المهمة تبقى بعد الحاوية التي تعمل اليوم.

الأسئلة الشائعة

لماذا اختفت بيانات Hermes Agent بعد إعادة تشغيل الحاوية؟

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

ما الفرق بين حجم Docker والتوصيل المرتبط (bind mount)؟

حجم Docker يُدار بواسطة Docker، بينما التوصيل المرتبط (bind mount) يربط مجلدًا من المضيف تختاره داخل الحاوية. الحجم غالبًا ما يكون نظيفًا لبيانات التطبيق المُدارة، بينما التوصيل المرتبط أسهل في التحديد مباشرة على المضيف. الخيار الأفضل يعتمد على ما إذا كنت تريد تخزينًا مدارًا بواسطة Docker أو مجلد مضيف مرئي للنسخ الاحتياطي والفحص.

أين يجب أن أخزن بيانات تطبيق Hermes Agent على خادم منزلي؟

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

لماذا تقول الحاوية أن المجلد غير موجود؟

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

هل يجب أن أشغل Hermes Agent كـ root لتجنب أخطاء الأذونات؟

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

كم مرة يجب أن أقوم بعمل نسخة احتياطية لبيانات Hermes Agent؟

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

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

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

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.