Согласен, инструкции можно было бы немного доработать. Странно, что часть, отвечающая за данные, перестала работать.
Ежегодные или раз в несколько лет более длительные простои — это не так уж плохо…
Нет, проблем не было, кроме тех, которые я создал сам, неправильно отредактировав файл web_only.yml при наличии существующей конфигурации app.yml. 
Рады сообщить, что теперь это, похоже, работает для этой конфигурации с двумя контейнерами!
Остаётся лишь одна проблема: текст на сайте, объясняющий, как выполнить пересборку через CLI («app»), но это очень мелочь.
cc: @pfaffman
Да, это прописано в коде. Если не помните, придётся настроить текст вручную. 
5 сообщений были перенесены в новую тему: Сборка не выполняется из-за несоответствия версии Ruby
Это никогда не сработает. Извините, что я упустил это ранее. Я обновил первое сообщение. Если вам нужно пересобрать данные, то вам нужно выполнить:
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
Нет. Это именно то, что ожидается. Вы не можете пересобрать PostgreSQL, пока другой экземпляр PostgreSQL обращается к файлам. Если создан новый контейнер с данными, вам нужно уничтожить и запустить новый контейнер web_only, потому что Docker каким-то образом привязывается к конкретному контейнеру, а не к ссылке на контейнер с именем data.
Спасибо за правки в исходном посте 
и помощь в Build fails due to ruby version mismatch
У меня что, крыша едет, или в скрипте установки Discourse больше нет аргумента --two-container? Я запустил его напрямую из рекомендованного места (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) на чистом VPS с Ubuntu 24.04 от Hetzner, и он просто установил обычную одноконтейнерную конфигурацию с файлом app.yml. Думал, возможно, нужно запустить скрипт discourse-setup, который идёт в комплекте, но он сделал то же самое.
Используйте метод ручной установки и команду ./discourse-setup --two-container. В последний раз, когда я её применял, всё прошло успешно.
Или установите с помощью удобного скрипта установки, а затем преобразуйте в двухконтейнерную конфигурацию, как указано в исходном сообщении (OP).
@Falco и @pmusaraj, как вы думаете, было бы полезно сохранить где-нибудь отдельные части старого файла INSTALL-cloud.md и ссылаться на них в текущем файле INSTALL-cloud.md?
Действительно, этот аргумент был удалён, я убрал ссылку на него из вики выше.
Спасибо за информацию. Почему это было удалено? Это был очень удобный метод.
Два контейнерных инсталла, выполненных людьми, которые не глубоко знакомы с Docker, создали слишком большую нагрузку на службу поддержки. Это продвинутая настройка установки, которая должна быть зарезервирована для тех, кто разбирается в этом.
Так что вы усложняете жизнь тем из нас, кто использует эту функцию. Вы заранее спросили кого-нибудь об этом изменении? Похоже, можно было бы оставить всё как было, ведь даже если использовать метод OP неправильно, это может создать проблемы только самому пользователю.
Нагрузка для кого? В этой теме? Поддержку оказывали волонтёры и пользователи, а не столько команда.
Значит, вы оставите web_only и data в samples, и тем, кто хочет использовать два контейнера, придётся копировать и настраивать их вручную? Единственная дополнительная поддержка, которая требовалась ранее, заключалась в помощи людям, которые не удосужились обновить контейнер с данными.
Теперь нам придётся объяснять целой группе людей, как пользоваться командами cp и nano. Можно утверждать, что если вы не знаете cp и nano, то вам не следует запускать двухконтейнерную настройку. Джефф утверждал, что если вы не знаете cp и nano, то вам не следует устанавливать Discourse, но мне удалось переубедить его, когда я написал discourse-setup.
В ближайшее время я переделаю свой дашборд на dashboard.literatecomputing.com, чтобы он больше не выполнял стандартную установку (поскольку он больше не может передавать ответы в discourse-setup), и продолжу предлагать вариант установки с двумя контейнерами там.
Мне это не нравится. Это похоже на ещё один шаг к полному отказу от поддержки двух контейнеров, что было бы очень жаль.
И вот в чём прелесть открытого исходного кода: у людей есть выбор, как им развиваться!
Десятки людей, работающих на устаревших контейнерах, которые полностью забыты, — это плохо. Это вызывало много путаницы каждый раз, когда PostgreSQL требовал крупного обновления, что, в свою очередь, приводило к тому, что обновления PostgreSQL происходили реже, ухудшая общий продукт.
Я согласен 
На самом деле полностью отказаться от поддержки установок в два (или N) контейнера невозможно; Discourse нативно подключается к внешним базам данных, как описано в статье Настройка Discourse для использования отдельного сервера PostgreSQL.
Гибкость не была ограничена, но, аналогично статье The Power of Defaults, каждый вариант в создаваемых нами инструментах требует учёта.
Удаление тысяч строк скриптов и упрощение установщика для покрытия наиболее распространённого сценария использования было осознанным решением, но Discourse по-прежнему поддерживает все те же сценарии, и люди, если захотят, могут выбрать свой собственный путь.
Спасибо за заверение, что этот способ производства продолжит работать без значительной степени кастомизации 
Удобство для тех, кто использовал удалённый метод, было принесено в жертву ради навязывания единого пути всем. Это было решение одного человека или в нём участвовали другие?
Из блога codinghorror:
«Значения по умолчанию, пожалуй, самые важные проектные решения, которые вы когда-либо примете как разработчик программного обеспечения. Выберите хорошие значения по умолчанию, и пользователи будут восхвалять ваше программное обеспечение и его простоту использования. Выберите плохие значения по умолчанию, и вам придётся столкнуться с недовольством пользователей из-за настроек, а также, вероятно, с множеством обращений в техническую поддержку.»
На мой взгляд, были выбраны плохие значения по умолчанию, и это решение/изменение было принято без участия, обсуждения или учёта мнения той категории пользователей, которые выражают сожаление по поводу этих изменений.
Спрашиваю ещё раз: чьим именно осознанным выбором это было?
Этот пользователь воспринимает такой комментарий как высокомерие и неуважение. Это вызывает чувство, будто тебя смотрят свысока и игнорируют. Я сомневаюсь, что целью было вызвать такую реакцию, но вот мы и здесь.
В целом, этот эпизод согласуется с тем, на что я жаловался в личном сообщении @несколько недель назад. У CDCK/Meta есть два неравных класса клиентов: те, кто платит за хостинг, и те, кто размещает сервис самостоятельно. Подход в этом эпизоде — новейший и, возможно, самый вопиющий пример такой двухклассовой системы.
При всём при этом…
Я приветствую новый установщик. Он отлично справляется с проблемами установки и, как следствие, со снижением спроса на поддержку ещё с первого дня.
Что касается изменений, CDCK имеет право строить и изменять систему так, как считает нужным. Спорить с этим не приходится. Моя надежда состоит в том, что они смогут делать это так, чтобы не отталкивать людей.
Наконец, повторное чтение поста от codinghorror заставило меня задуматься о том, как часто бывало, когда Джефф участвовал в обсуждении поста. Его сообщения часто отдавали пренебрежением, неуважением и лёгким высокомерием. К счастью, я никогда не был прямым объектом этого, но некоторые из тех постов было больно читать. Моё недавнее взаимодействие с сотрудниками по поводу того, как был обработан один пост, и этот эпизод кажутся очень похожими. Возможно, это только мне так кажется.
Это кажется немного суровым. Команда ежедневно помогает пользователям с самостоятельной установкой на этом форуме, даже тем, кто попадает в категорию unsupported-install 