Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
2 лайка
Привет!
Введение
Спасибо за это решение, @fefrei! Мы внедрили его на https://community.hiveeyes.org/, и всё работает как по маслу.
Дальнейшие размышления
Однако мы хотели бы сослаться на связанный вопрос от @mlinksva по адресу Site maintenance mode during rebuilds?, так как он также актуален для нас и не решается пока решением /errorpages. Речь идёт об улучшении стандартного текста: «Извините, нам не удалось загрузить эту тему, возможно, из-за проблемы с подключением». Мы постараемся изложить это подробнее.
Отображение discourse_offline.html
Это идеально подходит, когда пользователи впервые заходят на сайт.
Отображение другого текста «Извините за неудобства»
Однако при навигации внутри Discourse система будет сообщать вам следующее:
не раскрывая при этом причину.
Как мы уже знаем вас, вероятно, существует функция настройки, позволяющая изменить этот текст, верно? Возможно, мы просто упустили это. Мы также ещё не исследовали, решит ли функция Администрирование » Резервное копирование » Включить режим только для чтения эту проблему, как описано в Maintenance Mode?.
Тем не менее, нам показалось разумным ещё раз поднять эту тему здесь, и надеемся, что вы не будете возражать, если это окажется излишним.
С уважением,
Андреас.
P.S.: @staff: Поскольку это обсуждение каким-то образом вышло из-под контроля в отношении подходящих деталей конфигурации Nginx или веб-сервера, я предлагаю провести тщательную рефакторинг, разделив эти сообщения на тему с соответствующим названием, например, «Настройка веб-сервера для офлайн-страницы». Я уверен, что вы подберёте хорошее название. Заранее спасибо, если вам понравится это предложение и вы сочтёте его достойным реализации.
Теперь мы действительно чувствуем себя глупо, обнаружив это сразу как настраиваемый текстовый блок сайта:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
Мы изменили стандартный текст js.topic.server_error.description на:
Спасибо за внимание ;].
3 лайка
Хм. Мы не уверены, что изменение этого текста действительно сработает для нас. Нужно ли нам что-то особенное учитывать при правке этого элемента?
Также хотим отметить, что в определённый период, когда сайт был недоступен, он выдавал сообщение иначе:
Не подскажете, как мы могли бы изменить и это сообщение?
1 лайк
Я использую это, но хочу создать собственную офлайн-страницу и не могу этого сделать.
Превосходное руководство.
Но было бы здорово, если бы вы добавили команды для автоматического продления этого сертификата. Тогда это было бы полное руководство.
Я видел упомянутую здесь ссылку, но она содержит инструкции только по установке сертификата с нуля или его ручному продлению.
Однако я не смог найти рекомендаций по автоматическому продлению.
Спасибо.
1 лайк
Отличная мысль! Я обновил этот раздел выше в оригинальном посте 
1 лайк
Заметил ли кто-то ещё, что при обновлении появляется более общий код ошибки 500? Возможно, мне просто не повезло с моментом?
1 лайк
Когда контейнер остановлен во время пересборки, ничего не работает, чтобы вернуть ошибку 500.
4 лайка
Кто-нибудь пробовал использовать для этого другой Docker-контейнер, чтобы избежать всех этих ручных шагов, как предлагалось в начале?
Да, многие уже это сделали. См. Move from standalone container to separate web and data containers. Обратите внимание, что установка с отдельными контейнерами более сложна, и многие руководства здесь, на Meta, предполагают установку в одном контейнере (standalone). Прежде чем переходить к отдельным контейнерам, убедитесь, что вы понимаете, что делают эти два контейнера и как вы будете взаимодействовать с ними в дальнейшем. Самое важное: app больше не будет допустимой целью для команды ./launcher.
5 лайков
Хм, по какой-то причине в двух постах всё ещё упоминается «nginx впереди»…
Кстати, что я на самом деле хочу:
- иметь офлайн-страницу, обсуждаемую здесь
- перенаправлять http → https и корневой домен → www на моём веб-сервере. Я не хочу использовать Cloudflare для этого, так как некоторые его IP-адреса заблокированы в России.
Так что, как я понимаю, мне нужно просто разобраться, как это сделать в контейнере только для веба 
Теперь я запутался.
Ни одна из этих целей не требует отдельной настройки контейнера. Вы хотите настроить оба вышеуказанных шага и при этом независимо ищете отдельные контейнеры? Или вы рассматривали отдельные контейнеры, полагая, что они необходимы для выполнения вышеуказанных действий?
Насколько я понимаю, обработка страницы в автономном режиме (пересборка) не может находиться в том же контейнере, поскольку он не будет запущен. Таким образом, предлагаемое решение в текущей теме — добавить nginx перед ним. Однако, как обсуждалось в этой теме, это требует множества ручных шагов и зависит от операционной системы, поэтому я подумал, что использование отдельного Docker-контейнера для этого фронтенд-nginx было бы более надежным и простым в обслуживании.
Ах, теперь я понял. В таком случае проигнорируйте тему, на которую я ссылался ранее. В ней обсуждалось разделение веб-сервера Discourse и базы данных. Здесь это не требуется.
Установка Nginx в контейнере Docker, а не непосредственно в операционной системе, безусловно возможна, но мне не известны какие-либо специфичные для Discourse руководства по этому вопросу. Если вы выберете этот путь, пожалуйста, убедитесь, что вы понимаете исходное сообщение (OP) в этой теме (необходимые изменения для создания офлайн-страницы и установки прокси-сервера Nginx перед ним), а также хорошо разбираетесь в работе Docker, особенно в настройке сети между двумя контейнерами Docker. Также учтите, что мы, скорее всего, сможем предоставить ограниченную помощь, так как у нас нет опыта в этом.
Я также понял, что это больше не работает.
Я реализовал подход @fefrei ещё в начале ноября, и тогда он точно работал. Возможно, это связано с тем, что я останавливал контейнер вручную и выполнял git pull вместо использования /admin/upgrade.
1 лайк
4 сообщения были перенесены в новую тему: Добавить поддержку нативной офлайн-страницы при пересборке
Недавно мы поступили точно так же, и офлайн-страница успешно активировалась.
Сейчас мы просто выполнили онлайн-обновление через /admin/upgrade и обнаружили, что Discourse вообще не переходил в офлайн-режим! Независимо от того, было ли это улучшено недавно или нам просто повезло в этот раз, приятно видеть, что онлайн-обновление проходит без каких-либо значительных простоев.
При обновлении через Docker Manager (/admin/upgrade) Discourse никогда не должен переходить в офлайн-режим. Обычно у вас он уходит в офлайн? Если да, то стоит создать тему в Support по этому поводу.