أتفق، يمكن تعديل التعليمات. يبدو غريباً أن جزء البيانات لن يعمل بعد الآن.
فترة توقف أطول مرة كل عام أو نحو ذلك ليست سيئة جداً…
كلا، لم تكن هناك مشاكل باستثناء تلك التي سببتها في تحرير ملف web_only.yml عن طريق الخطأ باستخدام إعدادات تطبيق app.yml الحالية. 
يسرني أن أبلغ أن هذا يبدو أنه يعمل الآن لهذا الإعداد المكون من حاويتين!
المشكلة الوحيدة المتبقية هي النص الخاص بالموقع المستخدم لإخبارك بكيفية إعادة البناء من واجهة سطر الأوامر (“app”) ولكن هذا شيء صغير جدًا.
تحياتي: @pfaffman
نعم. هذا مُشفّر بشكل ثابت. إذا لم تتمكن من التذكر، فستحتاج إلى تخصيص النص. 
تم تقسيم 5 مشاركات إلى موضوع جديد: فشل البناء بسبب عدم تطابق إصدار روبي
هذا لا يمكن أن ينجح أبدًا. آسف لأنني أغفلت ذلك من قبل. لقد قمت بتحديث المنشور الأصلي. إذا كنت بحاجة إلى إعادة بناء البيانات، فأنت بحاجة إلى
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
لا. هذا بالضبط ما هو متوقع. لا يمكنك إعادة بناء postgres بينما يقوم postgres آخر بالوصول إلى الملفات. إذا تم إنشاء حاوية بيانات جديدة، فأنت بحاجة إلى تدمير وبدء حاوية web_only جديدة لأن docker يربط بطريقة ما بالحاوية الدقيقة بدلاً من مرجع إلى تلك المسماة data.
شكرًا على تعديلات OP 
والمساعدة في Build fails due to ruby version mismatch
هل أنا أُصاب بالجنون أم أن سكربت discourse-install لم يعد يحتوي على الوسيطة –two-container؟ لقد قمت بتشغيله مباشرة من الموقع الموصى به (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) على خادم افتراضي جديد يعمل بنظام Ubuntu 24.04 على Hetzner، وقام للتو بتثبيت إعداد حاوية واحدة عادي مع ملف app.yml. اعتقدت ربما أحتاج إلى تشغيل discourse-setup الذي يخرج منه، لكن ذلك فعل الشيء نفسه مرة أخرى.
استخدم طريقة التثبيت اليدوي و ./discourse-setup --two-container لقد نجحت معي في المرة الأخيرة التي استخدمتها.
أو قم بالتثبيت باستخدام البرنامج النصي للتثبيت الرائع ثم التحويل إلى حاويتين كما هو مشار إليه في المنشور الأصلي.
@Falco و @pmusaraj هل تعتقدان أنه سيكون من المفيد الاحتفاظ بأجزاء من ملف INSTALL-cloud.md القديم في مكان ما والإشارة إليه في ملف INSTALL-cloud.md الحالي؟
لقد تمت إزالته بالفعل، لقد أزلت الإشارة من الويكي أعلاه.
شكراً على المعلومات. لماذا تمت إزالته؟ لقد كانت طريقة مفيدة جداً.
إن تثبيتات الحاويات التي أجراها أشخاص ليسوا على دراية عميقة بـ Docker ولّدت عبئًا دعميًا كبيرًا جدًا. إنه إعداد تثبيت متقدم، يجب أن يُحجز للأشخاص الذين يعرفون طريقهم جيدًا.
لذا، أنت تجعل الأمر صعبًا على أولئك منا الذين يستخدمون هذه الميزة. هل سألت أي شخص عن التغيير مسبقًا؟ يبدو أنه كان بإمكانك تركه كما هو نظرًا لأنه يمكن للمرء استخدام طريقة OP بشكل غير صحيح ولا يزال يتسبب في بعض المشاكل لنفسه.
عبء على من؟ في هذا الموضوع؟ تم تقديم الدعم من قبل متطوعين/مستخدمين، وليس كثيرًا من قبل الفريق.
إذًا، ستتركون web_only و data في العينات، وسيتعين على الأشخاص الذين يرغبون في استخدام حاويتين نسخهما وتكوينهما يدويًا؟ الدعم الإضافي الوحيد الذي تطلبه الأمر قبل ذلك كان مساعدة الأشخاص الذين لم يكلفوا أنفسهم عناء تحديث حاوية البيانات.
الآن سنحتاج إلى إخبار مجموعة من الأشخاص بكيفية استخدام cp و nano. من المحتمل أنه إذا كنت لا تعرف cp و nano، فلا يجب عليك تشغيل إعداد حاويتين. جادل جيف بأنه إذا كنت لا تعرف cp و nano فلا يجب عليك تثبيت Discourse، لكنني تمكنت من تغيير رأيه عندما كتبت discourse-setup.
في الوقت الحالي، سأعيد كتابة dashboard.literatecomputing.com الخاص بي لإيقاف التثبيتات القياسية (لأنه لم يعد بإمكانه تمرير الإجابات إلى discourse-setup) وسأستمر في جعل تثبيت الحاويتين خيارًا هناك.
أنا لست من المعجبين. هذا يبدو وكأنه خطوة أخرى نحو التخلي عن دعم الحاويات المزدوجة بشكل عام، وهذا سيكون من المؤسف للغاية.
وهذا هو الشيء العظيم في المصادر المفتوحة؛ فالناس لديهم الخيار لاختيار مغامرتهم الخاصة!
إن وجود العشرات من الأشخاص الذين يشغلون حاويات قديمة منسية تمامًا ليس أمرًا رائعًا وتسبب في الكثير من الارتباك في كل مرة احتاج فيها PostgreSQL إلى تحديث رئيسي، مما جعل PostgreSQL الخاص بنا يحدث بشكل أقل تكرارًا، مما أدى إلى تدهور المنتج العام.
أنا أتفق 
ليس من الممكن حقًا التخلي عن دعم تثبيتات الحاوية المزدوجة (أو N)؛ يتصل Discourse أصليًا بقواعد بيانات خارجية، كما هو موثق في تكوين Discourse لاستخدام خادم PostgreSQL منفصل.
لم تتم إزالة أي مرونة، ولكن بشكل مماثل لـ https://blog.codinghorror.com/the-power-of-defaults/، يصبح كل خيار في الأدوات التي ننشئها شيئًا يحتاج إلى أخذه في الاعتبار.
إن إزالة آلاف أسطر النصوص البرمجية وتبسيط المثبت لتغطية حالة الاستخدام الأكثر شيوعًا كان خيارًا واعيًا، لكن Discourse لا يزال يدعم جميع حالات الاستخدام نفسها، والناس أحرار في الانطلاق في مسارهم الخاص إذا اختاروا ذلك.
شكرًا على الطمأنة بأن طريقة الإنتاج هذه ستستمر في العمل دون الحاجة إلى تخصيصات كبيرة 
لقد تم التضحية بالراحة لأولئك الذين يستخدمون الطريقة التي تمت إزالتها لصالح فرض مسار على الجميع. هل كان هذا قرارًا من شخص واحد أم شارك فيه آخرون؟
من codinghorror
"تعتبر الإعدادات الافتراضية من أهم قرارات التصميم التي ستتخذها على الإطلاق كمطور برامج. اختر الإعدادات الافتراضية الجيدة، وسيمدح المستخدمون برنامجك وكم هو سهل الاستخدام. اختر الإعدادات الافتراضية السيئة، وستواجه استياء المستخدمين بشأن التكوين، وربما عددًا من مكالمات الدعم الفني أيضًا."
في رأيي، تم اختيار إعدادات افتراضية سيئة وتم اتخاذ الاختيار/التغيير دون مشاركة أو نقاش أو اعتبار من فئة المستخدمين الذين يندبون التغيير.
أسأل مرة أخرى، اختيار واعٍ من قبل من؟
يشعر هذا المستخدم بأن هذا التعليق متعجرف وغير محترم. إنه شعور قد يشعر به المرء إذا كان يُنظر إليه بازدراء ويتم تجاهله. أشك في أن القصد كان إحداث مثل هذا رد الفعل ولكن ها نحن ذا.
بشكل عام، تتسق هذه الحلقة مع ما كنت أشتكي منه في رسالة خاصة مع @nat قبل بضعة أسابيع. لدى CDCK/Meta فئتان غير متكافئتين من العملاء، أولئك الذين يدفعون مقابل الاستضافة وأولئك الذين يستضيفون أنفسهم. النهج في هذه الحلقة هو الأحدث وربما المثال الأكثر فظاعة لهذا النظام ذي الفئتين.
مع كل ما سبق…
أنا أثني على أداة التثبيت الجديدة. إنها تقوم بعمل جيد في التعامل مع مشكلات التثبيت ومطالب الدعم الناتجة منذ اليوم الأول.
أما بالنسبة للتغيير، فلدى CDCK الحق في البناء/التغيير كما تراه مناسبًا. لا جدال في ذلك. آمل أن يتمكنوا من القيام بذلك بطريقة لا تنفر الناس.
أخيرًا، أدى إعادة قراءة المنشور بواسطة codinghorror إلى جعلي أفكر في كيف كانت الأمور غالبًا عندما يتدخل جيف في منشور. غالبًا ما كانت منشوراته تنم عن تجاهل وعدم احترام وغطرسة طفيفة. لحسن الحظ، لم أكن الهدف المباشر لذلك، لكن بعض تلك المنشورات كانت مؤلمة للقراءة. تفاعلي الأخير مع الموظفين حول كيفية التعامل مع منشور وهذه الحلقة يبدوان متشابهين جدًا. ربما أنا فقط.
هذا يبدو قاسياً بعض الشيء. الفريق يساعد المستضيفين الذاتيين كل يوم في هذا المنتدى، حتى أولئك الذين يندرجون تحت unsupported-install 