Отображение статической страницы ошибки, когда сайт недоступен

Поддержка
1

Моя цель — показывать страницу «Сайт находится на техническом обслуживании», когда он становится недоступным, например, во время процесса пересборки.

Эта тема в целом описывает то, что я хочу сделать, но, похоже, требует нестандартной настройки. Есть ли более простой способ реализовать это для стандартной установки? Спасибо!

2

Нет, на данный момент ничего подобного нет.

3

На самом деле эта процедура использует то, что считается «стандартной установкой» (то есть официальное руководство Discourse по Docker), к которой Nginx разворачивается за пределами контейнера.

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

4

Не тот ответ, который я хотел услышать, но я всё же ценю вашу однозначность.

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

5

С тех пор как я добавил NGINX для этой цели в 2020 году, мне пришлось дважды редактировать конфигурацию. Оба раза это было связано с настройкой параметров загрузки больших файлов после обновления лимита в Discourse.

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

6

Обратите внимание, что внешний nginx приносит ещё одну ценную вещь помимо статической страницы ошибки: правильное определение исходных IP-адресов для пользователей IPv6. Если ваш форум доступен через IPv6 и вы не используете конфигурацию внешнего nginx, все, кто обращается к вашему сайту через IPv6, будут отображаться как пришедшие с локального адреса 172.x.y.z. Это не помогает, когда вы пытаетесь справиться с вредоносными пользователями, такими как спамеры!

Это абсолютно то же самое при добавлении новых плагинов.

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

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

Обратите внимание, что документация, о которой вы спрашивали, гласит:

:alarm_clock: Если вы установили certbot из репозитория пакетов, обновление обычно происходит автоматически. В противном случае установите напоминание о запуске letsencrypt renew && systemctl reload nginx.service до истечения срока действия вашего сертификата!

Однако установка напоминания — не лучший способ сделать это. Вы неизбежно забудете, и если вы пропустите письмо от letsencrypt с предупреждением о истекающем сертификате, ваш сайт перестанет работать. К счастью, это легко исправить.

Если автоматическое обновление не настроено, вот как это сделать.

Создайте файл /etc/systemd/system/certbot.service со следующим содержимым:

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Создайте файл /etc/systemd/system/certbot.timer со следующим содержимым:

[Unit]
Description=Запуск certbot дважды в день

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

Затем сообщите systemd о новых файлах.

# systemctl daemon-reload
# systemctl enable --now certbot.timer
7

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

8

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

9

А, понятно. С моей точки зрения это почти то же самое, за исключением того, что нужно следить за тем, когда контейнер с датами требует обновления. Это происходит нечасто, но всё же требует внимания. И когда это случается, сайт на какое-то время становится недоступным.

10

Это тоже верно. Всегда есть компромисс — время простоя форума из-за обновлений/апгрейдов против времени, которое требует обслуживание отдельных контейнеров (особенно когда ты (читай: я) всё ломаешь и начинаешь искать исправления, а форум в это время тоже недоступен :rofl: )