Создайте утилиту для создания единой страницы статуса офлайн/технических работ для Discourse

Внести вклад Функция
1

В настоящее время при проведении любых видов технического обслуживания (кроме простого обновления), когда мы хотим перевести сайт в автономный режим или установить режим только для чтения, нет возможности сообщить посетителям, что происходит, или указать примерное время, в течение которого система будет недоступна.

Я уже создал автономную страницу с помощью метода Nginx, описанного здесь (и улучшил его, используя инструкции из этой и этой статей), но…

Было бы здорово иметь комплексный автономный режим, который позволил бы администраторам предоставлять обновления статуса и сообщения входящим посетителям во время простоя, чтобы управлять ожиданиями и вызывать у посетителей позитивное отношение к ситуации, вместо того чтобы они гадали, что происходит.

Для истории вот оригинальное замечание, которое привело к этому разделению, согласно @jomaxro:

Здесь действительно необходимо внедрить интегрированный автономный/режим технического обслуживания, который объединял бы этот метод и возможность предоставлять пользователям персонализированные сообщения, пока система находится в автономном режиме и/или режиме технического обслуживания.

Это могло бы быть частью менеджера обновлений (переименовать менеджер обновлений в «Менеджер системы Discourse» и объединить в этом разделе обновления, логи, процессы и резервные копии).

Это сделало бы систему менее хрупкой, более дружелюбной и полезной как для администраторов, так и для пользователей.

6 лайков
Add an offline page to display when Discourse is rebuilding or starting up
Benefits of the who's online plugin?
2

Docker Manager — официальный плагин, который мы поддерживаем для обновлений, не вызывает простоя. Изменения в плагине не должны быть необходимы, так как он уже поддерживает обновления без простоя. Проблема, которую решает это руководство howto, касается обновлений (пересборки), выполняемых из командной строки. Они требуются редко, несколько раз в год, когда необходимо обновить базовую зависимость, например версию Ruby или Postgres.

Невозможно заставить Docker Manager обрабатывать такие обновления, поскольку Docker Manager, как и весь Discourse, недоступен во время пересборки. Любое решение должно находиться вне Discourse, например, решение с прокси Nginx, которое предлагается в этой теме.

7 лайков
3

Хм, мне кажется, здесь есть и другие варианты, которые лучше соответствуют природе Discourse… Вместо того чтобы отвергать эту идею, давайте обсудим способы улучшить общий опыт в этом отношении, особенно если администратору по той или иной причине нужно будет отключить сайт для технического обслуживания.

Одна мысль, которая приходит на ум: почему бы не интегрировать решение с прокси Nginx, предложенное автором оригинального поста (OP), в настройку Docker? Это сделает систему более предсказуемой, управляемой и согласованной как для пользователей и администраторов Discourse, так и для службы поддержки (таких как вы здесь, на форуме), вместо того чтобы иметь дело с разрозненными решениями, как предложенное здесь.

1 лайк
4

Я не планирую отвергать эту идею, а лишь констатирую, что использование плагина Discourse для решения этой проблемы не сработает. Позвольте мне перенести это обсуждение в отдельную тему #feature для надлежащего обсуждения.

@mreach, пожалуйста, отредактируйте первое сообщение (OP), чтобы подробно описать, что именно вы ищете и как вы хотите, чтобы это работало. Не стесняйтесь при необходимости также отредактировать заголовок.

1 лайк
5

Если вы хотите минимизировать простои во время выполнения команды ./launcher rebuild app, вам потребуется настройка с несколькими контейнерами.

Это уже задокументировано. Это более сложная настройка.

Чтобы реализовать режим “офлайн-страницы” при выполнении launcher rebuild в одном контейнере, нам пришлось бы заменить текущий контейнер на специальный выделенный контейнер с сообщением “сайт недоступен”. Это не невозможно, но потребовало бы примерно двух недель работы инженеров для идеальной реализации. Учитывая, как редко требуется пересборка контейнера и то, что у нас уже есть задокументированный способ выполнения пересборки без прерывания работы, я не думаю, что мы можем позволить себе финансировать эту задачу на данный момент.

9 лайков
6

Я согласен с Сэмом: если у вас есть возможности создать страницу «Сайт недоступен», лучше потратить время на то, чтобы сайт просто не падал. Но, возможно, вам подойдет Add an offline page to display when Discourse is rebuilding or starting up.

Установка с двумя контейнерами в большинстве случаев обеспечивает минимальное время простоя при обновлениях. Иногда создание нового контейнера включает миграцию, которая приводит к падению работающего сайта. Есть способ обойти это, но он довольно сложный, и такие обновления происходят довольно редко.

Также вы можете перенаправить свой DNS (или использовать эластичный IP или то, как это называется в Digital Ocean) и запустить дроплет (или то, как это называется в AWS) с веб-сервером, содержащим ваше сообщение о статусе.

2 лайка
7

Кстати, @jomaxro, как вы выделили мой пост в новую тему здесь? Какие шаги вы при этом выполнили? Было бы очень полезно это знать… Я не вижу никакого метода для этого в стандартном Discourse.

1 лайк
8
5 лайков
9

О, здорово, я, должно быть, пропустил это 5 раз, пока ковырялся после завершения этой темы.

1 лайк