Возможно, мы просто добавили страницу офлайн-режима, потому что начали использовать процедуру обновления «остановить контейнер, git pull, пересборка через launcher» после того, как несколько раз столкнулись с проблемами, описанными в [1, 2, 3].
Возможно, что-то изменилось в надёжности принудительного завершения работы PostgreSQL, если она не завершается вовремя, чтобы процесс обновления прошёл гладко.
В любом случае, онлайн-обновление (снова) сработало у нас отлично, когда мы попробовали его прямо сейчас. Так что забудьте и извините за шум.
Это немного запутанно, поскольку далее следует руководство по установке и настройке nginx вне контейнера.
В любом случае, сегодня я обнаружил дополнительное преимущество такой внешней конфигурации nginx: если вы привыкли видеть IP-адреса 127.0.0.1 или адрес вашего Docker-контейнера (вероятно, начинающийся с 172.) в качестве IP-адреса регистрации или входа, это могло быть связано с тем, что трафик IPv6, пересылаемый в контейнер, не сохранял свой IPv6-адрес, в отличие от IPv4. С данной конфигурацией вы теперь будете видеть корректные IPv6-адреса вместо локальных.
Иными словами, такая конфигурация по сути необходима для корректной работы полезного административного инструмента в условиях всё более распространённого использования IPv6 в интернете. (В США это включает значительную часть мобильного трафика.)
Спасибо за этот очень полезный гайд! Несколько замечаний:
Я думаю, что sudo apt-get install letsencrypt был заменён на sudo apt-get install certbot. При запуске первой команды я получаю уведомление: Note, selecting 'certbot' instead of 'letsencrypt'.
Друг заметил, что при публикации ссылки на сайт в Facebook отображался превью-текст «301 moved permanently».
Редакция: изначально я заменил секцию location / блока сервера порта 80 на секцию location / блока сервера порта 443. Но, думаю, это избыточно. Вместо этого я просто удалил блок сервера порта 80, который служил для перенаправления, и добавил:
listen [::]:80;
listen 80;
в соответствующую секцию основного блока сервера.
Также я включил перенаправление на HTTPS (не уверен, что это необходимо) в настройках Discourse.
Это устранило проблему с публикацией в Facebook, и, похоже, обычные HTTP-запросы теперь перенаправляются на HTTPS. Если есть другой или более эффективный способ, пожалуйста, сообщите.
Спасибо за урок, он отличный. Теперь моя страница 502 выглядит гораздо лучше.
В моём практическом случае мне нужно добавить конфигурацию nginx в файл /etc/nginx/sites-enabled/discourse.conf.
Я успешно установил Discourse после того, как nginx запустил WordPress.
Я столкнулся с проблемой, когда nginx не знал о продлённом сертификате, потому что не был перезапущен после установки, как рекомендовано в этом руководстве. Для меня решение заключалось в следующем:
У меня возник вопрос: если, например, Googlebot увидит эту страницу ошибки, поймёт ли он, что это временная страница? Или нам нужно отправить какой-то код ошибки, чтобы сообщить о временном характере изменений?
Мне бы не хотелось, чтобы Google удалил все индексированные данные моего форума из-за более красивой страницы ошибки…
Google должен воспринимать ошибки 500/502 как сигнал «вернуться позже». Если ваш сайт не перестраивается слишком часто, у вас не должно возникнуть проблем.
Я уже давно запускаю свой форум за nginx, и это никак не повлияло на ранжирование.
Это означает: «При возникновении (или получении) кода ответа 502 Bad Gateway отправлять содержимое файла /errorpages/discourse_offline.html с кодом ответа 502 Bad Gateway». Символ = указывает, какой код HTTP-ответа нужно отправить.
Всё в порядке!
И я согласен с @ashs: одна-две минуты с ошибкой 502 в месяц не навредили поисковой выдаче. Я часто вижу, что в результатах поиска Google отображаются недавние публикации.
Ошибка 502, скорее всего, указывает на то, что Nginx не запускается, вероятно, из-за ошибки в конфигурации. Команда nginx -t покажет, корректен ли файл конфигурации. Если ошибок нет, выполните systemctl status nginx.service, чтобы проверить статус службы Nginx.
Мой вопрос напрямую связан с темой заголовка, но не с методом, используемым в этой теме, поэтому надеюсь, что можно оставить его в этом обсуждении.
Я настроил очень простое решение для этой проблемы и имею конкретный вопрос.
Я создал отдельный дроплет в DigitalOcean и установил LAMP-сервер через маркетплейс. Затем я загрузил базовую HTML-страницу с несколькими изображениями, чтобы указать, что сервер находится на техническом обслуживании. После этого я мог перемещать IP-адрес между моим обычным сервером Discourse и этим сервером для обслуживания по мере необходимости.
Вот вопрос: чтобы сервер «обслуживания» загружался корректно, мне в конечном итоге потребовалось получить сертификат через certbot для этого сервера (в дополнение к тому, который у меня уже был для основного экземпляра Discourse). Иными словами, два сертификата для одного и того же домена на разных серверах. Это сработало, но я всегда беспокоился, не создаст ли это проблем в будущем. Прочитанные мной материалы в интернете предполагают, что это допустимо, но я хотел бы узнать, был ли у кого-то прямой опыт работы с такой конфигурацией.
Это абсолютно допустимая операция. Однако, в зависимости от того, как вы выполняете проверку, обновление сертификатов может не работать — например, если ваш сервер «технического обслуживания» использует проверку на основе HTTP, это завершится неудачей, пока домен не будет перенаправлен на него, что, вероятно, лишает смысла всю затею. Возможно, имеет смысл настроить сервер технического обслуживания на периодическое копирование последнего сертификата с основного сервера вместо запроса нового в Let’s Encrypt.
Я должен признаться, что не имею ни малейшего представления, использует ли мой сервер HTTP-валидацию (я всё настраивал через этот замечательный Certbot), но ваша озабоченность абсолютно логична. Я немного поискал, но не смог найти никаких материалов о том, как копировать сертификаты, как вы предлагаете. Также я предполагаю, что мне потребуется настроить какой-то cron-задачу. Если у вас есть дополнительные предложения, буду очень признателен. В противном случае, ещё раз спасибо за вашу помощь.
Для прямого копирования файлов с одного сервера на другой хорошо подходят утилиты scp или rsync — этот ресурс может стать хорошей отправной точкой.
Моя рекомендация действительно состоит в том, чтобы настроить задачу cron для регулярного копирования сертификата с основного сервера на сервер обслуживания
Кстати, чтобы объяснить суть проверки через HTTP: чтобы убедиться, что домен действительно принадлежит вам, Let’s Encrypt запрашивает с вашего сервера определённый файл и ожидает конкретный ответ. Certbot может автоматически обработать этот процесс (временно настроив ваш сервер для возврата этого файла при запросе на проверку), но, разумеется, это работает только в том случае, если запрос действительно доходит до вашего сервера. Если ваш DNS не указывает на ваш сервер или вы перенесли IP-адрес в другое место, запрос попадёт не туда, Let’s Encrypt не получит ожидаемый ответ и откажется подписывать сертификат.
Если вы хотите иметь страницу «В разработке» во время перестройки сайта, вам придется выполнить описанные выше трудоемкие шаги. Я рекомендую перейти на установку с двумя контейнерами. Это требует немного больше усилий в обслуживании (нужно знать, когда пересоздавать контейнер с данными), но время простоя при запуске нового контейнера составляет всего около 30 секунд. Однако сейчас это требует значительного объема оперативной памяти (2 ГБ может быть недостаточно, но я не уверен на 100 %).
