لا تنسَ تشغيل الأمر docker remove app عند إعادة تثبيت discourse

الدعم
1

لقد كنت أستخدم Discourse لعدة سنوات الآن. أقوم بإعداد نسخة جديدة كل 6 أشهر. يتضمن الإعداد الخاص بي Docker ووكيلًا يعتمد على Nginx، لذلك ربما يكون غير قياسي قليلاً. أنا لا أستخدم discourse-setup لهذا السبب.

كل 6 أشهر، عندما أكرر هذه العملية، بعد أن أقوم باستنساخ نسخة جديدة من Discourse من git الخاص بها وتشغيل ./launcher bootstrap app، يفشل الحاوية في البدء. يظهر السجل:

anacron: Can't chdir to /var/spool/anacron: No such file or directory
run-parts: /etc/runit/1.d/anacron exited with return code 1
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
anacron: Can't chdir to /var/spool/anacron: No such file or directory

إلى ما لا نهاية.

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

هذه المرة، أعتقد أنني وجدت المشكلة أخيرًا، وهي هذه: يبدو أن ./launcher start app يعيد تشغيل مثيلات الحاويات القديمة المسماة app، حتى عندما تم استنساخ Discourse وإعادة بنائه.

الخطوة المفقودة هي docker remove app. باختصار:

./launcher stop app
docker remove app
... الآن استنساخ، إعادة بناء، وتشغيل ./launcher start app يعمل

كان خطئي هو توقع أنه بعد تشغيل ./launcher bootstrap app، فإن ./launcher start app التالي سيبدأ صورة الحاوية الجديدة، ولكن هذا لا يبدو أنه الحال. بطبيعة الحال، تسوء الأمور مع الحاوية القديمة نظرًا لإعادة تهيئة المسار /var/discourse/shared.

أترك هذا هنا في حال بحث الآخرين عن نفس رسائل خطأ السجل.

كتحسين محتمل، سيكون من الجيد لو اكتشفت الحاوية أن دليل /var/discourse/shared الخاص بها قد تغير.

إعجابَين (2)
2

إذا كنت تريد تشغيل bootstrap، فإن “طريقة discourse” هي

./launcher bootstrap app
./launcher destroy app
./launcher start app

ولكن إذا كان لديك حاوية واحدة فقط، فلا يوجد سبب لعدم القيام بذلك

./launcher rebuild app

مثلما تقول معظم الأمثلة. هذا يوقف الحاوية قيد التشغيل، ويقوم بإنشاء حاوية جديدة، ويبدأها. إذا فشل bootstrap لسبب ما، يمكنك (عادةً) إعادة تشغيل الحاوية القديمة باستخدام ./launcher start app (كما وصفت).

3

أعتقد أنني أرى المشكلة، وهي تتعلق بالخلط المعتاد بين “مثيل الحاوية” و"صورة الحاوية".

إذا نظرت إلى 10. الصيانة بعد التثبيت، على سبيل المثال، فإنه يقول:

الاستخدام: launcher COMMAND CONFIG [--skip-prereqs] [--docker-args STRING]
الأوامر:
    start:      بدء/تهيئة حاوية
    stop:       إيقاف حاوية قيد التشغيل
    restart:    إعادة تشغيل حاوية
    destroy:    إيقاف وإزالة حاوية
    enter:      استخدام nsenter للحصول على shell في حاوية
    logs:       عرض سجلات Docker لحاوية
    bootstrap:  تهيئة حاوية للتكوين بناءً على قالب
    rebuild:    إعادة بناء حاوية (تدمير القديمة، تهيئة، بدء جديدة)
    cleanup:    إزالة جميع الحاويات التي توقفت لمدة > 24 ساعة

في معظم استخدامات كلمة “حاوية” في مخرجات المساعدة هذه، فإنها تشير إلى مثيل لحاوية. باستثناء bootstrap، حيث تشير إلى صورة. (يستخدم ./launcher bootstrap docker commit لإنشاء صورة جديدة يمكن من خلالها تشغيل مثيلات حاويات لاحقة.) أعتقد أن هذا كان غير متوقع (وافترضت بسذاجة أنه سيؤثر أيضًا على مثيل app الحالي.)

في rebuild، تشير كلمة حاوية إلى كل من صور الحاويات والمثيلات لأنها تتضمن مجموعة من العمليات التي تؤثر على كل من مثيلات الحاويات وصور الحاويات.

وليس من الواضح ما تشير إليه في cleanup - هل ستتم إزالة المثيلات فقط، أم الصورة التي تم تهيئتها أيضًا؟

إعجاب واحد (1)