هذه الصورة من المحتمل أن تعمل. يمكنك بدء هذه الصورة باستخدام الأمر docker start b5f2a8a39709 على سبيل المثال.
(قد ترغب أيضًا في تقليم بعض هذه الصور القديمة - هناك مساحة كبيرة محتملة على القرص يمكن استعادتها!)
إعجابَين (2)
الحصول على: استجابة خطأ من الخادم: لا يوجد حاوية: b5f2a8a39709
شكراً. أيضاً، تقوم إجراءات النسخ الاحتياطي الخاصة بي بنسخ جميع الملفات من النظام. من المحتمل أن تكون هناك صور أحدث هناك إذا كنت أعرف أين أبحث وأين أنسخها.
أعتذر عن مقاطعة الحل البديل، لكننا سننتقل إلى خادم آخر، وهو ما كان يمثل تحديًا بحد ذاته لأنه كان خادمًا مخصصًا وقد جددنا العقد للتو لمدة عام كامل في يونيو الماضي.
ربما سيكون من الجيد أن يصدر فريق Discourse تحذيرًا للأشخاص الذين يشغلونه على خوادم لم تعد مدعومة. اكتشاف الأمر بالطريقة التي اكتشفناها بها أمر غير سار للغاية. (ثلاثة مستخدمين لديهم نفس المشكلة، نحن نتحدث عن الخوادم، ولا يتم تجديدها بنفس سرعة أجهزة الكمبيوتر المحمولة.)
إعجاب واحد (1)
أريد أن يكون واضحًا أن هذا لم يكن تغييرًا متعمدًا.
ليس لدينا أيضًا وصول مباشر إلى الأجهزة القديمة هذه و نحتاج إلى الاعتماد على بعض المساعدة المجتمعية هنا للمساعدة في تحديد ما يحدث بالضبط.
بمجرد أن نعرف على وجه اليقين أن هذه مشكلة تجميع مع الجوهرة نفسها، يمكننا اتخاذ إجراء.
3 إعجابات
@here
إضافة مفتاح مستوى أعلى في ملف app.yml مع
base_image: discourse/base:2.0.20220621-0049-slim
يجب أن يحل المشكلة، على الرغم من أنه سيؤدي إلى إبطاء عمليات إعادة البناء قليلاً.
3 إعجابات
هذا عادل، ولكن لا يزال مقدمو الخدمة حول العالم يقدمون مثل هذه الخوادم كخوادم منخفضة الدخول.
بالنسبة للعديد من المشاريع الصغيرة مفتوحة المصدر، تعد هذه الخوادم مثالية، من حيث السعر وغالبًا لا يمكنهم تحمل تكلفة معالج Intel Xeon أو AMD Ryzen بذاكرة وصول عشوائي (RAM) بسعة 32 جيجابايت.
أتفهم تمامًا أنه ليس لديك الأجهزة اللازمة لاختبار البرنامج عليها، ولكن من خلال التواصل في هذا الموضوع، تم تأسيس ذلك من قبلنا ولم يكن هناك أي رد على الإطلاق.
اعتذار بسيط، سننظر في هذا سيكون كافيًا في هذه الحالة، بدلاً من ذلك، تركتنا معلقين.
إعجاب واحد (1)
الاختبار الآن مع هذا التغيير.
يبدو أن البناء يفشل بنفس الطريقة.
كان هذا مع التغيير إلى containers/app.yml، بإضافة:
base_image: discourse/base:2.0.20220621-0049-slim
بالقرب من الأعلى.
إعجاب واحد (1)
هذا يعني أن المشكلة ليست في أننا نشحن إصدارًا مجمعًا مسبقًا من الجيم، ولكن في أن الجيم الأصلي لا يمكن تجميعه على وحدات المعالجة المركزية القديمة هذه.
لقد قمنا بفتح issue #789 ضد الجيم oj.
إعجابَين (2)
مفهوم. أود استعادة إحدى صور Docker الحديثة الخاصة بي – من النسخ الاحتياطية لـ rsync. هل هناك إجراء يمكنك توجيهي إليه للعثور عليها واستعادة/بدء واحدة؟ شكرًا!
هل جربت ./launcher start app؟
إعجاب واحد (1)
إذا لم ينجح هذا، فجرّب الطريقة الأخرى التي فصّلتها لإعادة البناء من آخر تثبيت ناجح.
3 إعجابات
نعم. هذا يشغل خادم الويب، ولكن لا يمكنك الوصول فعليًا إلى أي سلاسل، فهي تدور فقط.
هذا لن يساعد.
المشكلة هي أن الجيم المحدث لا يتحقق مما إذا كانت التعليمات مدعومة من قبل وحدة المعالجة المركزية قبل استخدامها.
[اقتباس=“Michael Brown, post:56, topic:231862, username:supermathie”]
هذا لن يساعد.
[/اقتباس]
سيساعد في إعادة تشغيل مثيل Discourse لأنه يقوم بتثبيت إصدار gem السابق/العامل (ثبت من خلال ما فعلته لإعادة مثيل Bryan)، ولكن نعم - أي تحديث إضافي (عبر admin/upgrade) سيؤدي إلى نفس المشكلة مرة أخرى.
إعجاب واحد (1)
ليس لدي أي حظ مع بناء جديد أو تشغيل المثيل السابق بعد، لذا بما أن عطلة نهاية الأسبوع قادمة قد أتوقف عن هذا حتى الأسبوع المقبل على أمل أن يتم إصلاح الوضع من جانب الـ gem …
ما هي الإجراء الذي تم اتباعه؟ أنا مرتبك بعض الشيء الآن في محاولة متابعة الأفكار المختلفة في هذا الموضوع. شكراً!
الجزء الثاني من هذا المنشور:
إعجاب واحد (1)
سأجرب هذا. شكرًا.
هناك طريقة أخرى ممكنة وهي إضافة ما يلي إلى app.yml
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
3 إعجابات
أفترض أن التحديثات ستظل غير آمنة بعد ذلك، أليس كذلك؟ أقوم بالبناء على الالتزام الأقدم حاليًا.