Здравствуйте, нормально ли, что сайт недоступен при установке или обновлении тем и плагинов?
Это нормально, что сайт становится недоступным во время пересборки.
Решения включают использование установки с двумя контейнерами, что позволяет создать новый контейнер, сокращая время простоя до менее чем одной минуты, или настроить отображение страницы «мы скоро вернёмся» во время простоя сайта. Это не уменьшает время простоя, но показывает посетителям, что вы в курсе проблемы.
Все считают, что хотя бы одно из этих решений слишком сложное и совершенно не стоит усилий.
Добавлю, что в отличие от плагинов, установка или обновление тем и компонентов тем не требует простоя в работе. 
Есть ли какая-либо документация по упомянутому вами методу? Кроме того, это кажется ироничным: с точки зрения дискурса метод отлично подходит для SEO, но во время загрузки происходит прерывание, и роботы Google не могут просканировать сайт.
Как часто вы ожидаете установку нового плагина? Это обычно очень редкое событие.
Вы можете обновлять плагины онлайн с минимальным прерыванием работы сервиса, так как контейнеры переключаются.
Спасибо за ответы. 
Когда почувствуете себя готовыми, загляните на Add an offline page to display when Discourse is rebuilding or starting up.
Привет 
Я не уверен, возможно, я ошибаюсь (я ещё не пробовал), но теперь это часть ядра? Несколько месяцев назад в discourse/templates появился новый шаблон offline-page.template.yml, который запускает GitHub - discourse/discourse-offline-page: offline page for discourse · GitHub. Это статический HTML-сайт, отображаемый во время загрузки Discourse. Также есть PR по этой теме в discourse_docker: FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
Похоже, это затронет только половину? Оно будет отображаться при запуске, но не при пересборке, если я правильно понимаю процесс пересборки:
Добавить шаблон для извлечения и обслуживания статических HTML-файлов из GitHub - discourse/discourse-offline-page: offline page for discourse · GitHub, когда nginx доступен, но rails нет.
^ Этот PR на GitHub
Но это шаг в правильном направлении, спасибо @Don (и @featheredtoast ! )
Да, @Firepup650, я wondered, почему я не видел этого, и, кажется, вы ответили на этот вопрос!
Здесь есть несколько хороших 
! 
Интересно, является ли это предварительным шагом к постоянному стандартному двухконтейнерному набору, где контейнер nginx собирается отдельно?!??! 
Вы меня раскрыли — действительно, ведутся работы по расширению возможностей предоставления офлайн-страниц. Упомянутые коммиты и репозитории закладывают основу для этого, но на данный момент такая функциональность ещё не реализована.
По какой-то причине ни один из моих пользователей не видит этого в процессе перестроения. Ну, по крайней мере, в чате, и именно поэтому происходили случаи, когда пользователь терял только что написанное сообщение.
Мое мнение таково: ситуация, когда мы вообще не информируем уже вошедших в систему пользователей о простое, является самой большой проблемой UX в Discourse. Конечно, я понимаю объяснения, что это проистекает из самой природы этого приложения, и разработчики как бы загнали себя в угол с самого начала (ситуации, подобные той, что с черновиками и несколькими другими вещами), но это не устраняет саму проблему.
У нас есть несколько обходных путей. Использование Nginx в качестве обратного прокси перед Discourse с отображением настроенной страницы ошибки — один из них. И когда у администратора возникают проблемы, ответ будет: «мы поддерживаем только стандартный вариант». Это была реальная причина, по которой я от этого отказался.
Два разных контейнера — одно из решений. Или, по крайней мере, это сводит время простоя к минимуму. Слишком много предупреждений по этому поводу, поэтому я немного боюсь идти этим путем.
Или мы можем обновляться только иногда, предупреждать пользователей заранее и отключать публичный доступ. Да, это одно из решений, но… сейчас 2024 год, и в моей среде такой подход используют только банковские системы 
.
Использование стейджинг-сервера — это то, что следует делать. Ну, это корпоративное решение, дорогое и довольно сложное при правильном выполнении, и требует собственной IT-команды.
Так что новые утечки планов 
действительно являются значительным улучшением. Ну, если для этого нужны отдельные контейнеры, то, полагаю, самое время нырнуть с головой.
Это абсолютно то же самое, за исключением того, что в редких случаях вам также может потребоваться пересобрать контейнер с данными.
Но время простоя намного короче, всего 20 минут, не так ли?
Чат может содержать элементы, отличные от обычного просмотра сайта, так как, по моему мнению, он обеспечивает более прямой доступ в реальном времени, в отличие от возможности кэширования страниц.
Согласен. Заранее объявляемое плановое обслуживание, на мой взгляд, лучше всего реализовано ещё в старые добрые времена до-основанных BBS с коммутируемым доступом. Там была возможность выводить системное сообщение, предупреждающее о предстоящем плановом отключении и о том, что пользователи будут разлогинены в назначенное время. В те времена это обычно делалось для передачи пакетов почты между сетевыми BBS.
Да. Простой обычно составляет менее минуты, но вам потребуется достаточно оперативной памяти или подкачки, чтобы пересобрать один контейнер, пока собирается другой.