Справочная информация: сайт — lot.almost-dead.net, версия 2.8.0.beta4, размещён на Google Cloud/Compute; настройка выполнена по официальному руководству на основе Docker. (Я хорошо разбираюсь во фронтенд-технологиях браузера и понимаю общие принципы облачного хостинга, но знаком с AWS, а не с Google.)
Предварительная причина: я остановил экземпляр виртуальной машины (VM), а затем перезапустил его (пытаясь изменить переменные окружения, передаваемые в Discourse).
После возвращения VM и восстановления работы сайта я заметил, что JS-активы и некоторые аватары пользователей не загружаются (тайм-аут). В панели администратора раздел «Здоровье сообщества» не загружается: спиннер продолжает вращаться, а в инструментах разработчика Chrome во вкладке «Сеть» видно, что все запросы /message-bus/.../poll завершаются неудачей. Страница обновления (/admin/upgrade) падает почти мгновенно, и Chrome показывает код ошибки ERR_FAILED. При просмотре тем запросы POST завершаются ошибкой ERR_CONNECTION_REFUSED, а инициализируемые JS запросы GET — ошибкой ERR_FAILED. (Это наблюдается из браузера, где для моей учётной записи администратора установлены куки входа.)
Открытие сайта в новом экземпляре браузера приводит к ошибке Chrome ERR_CONNECTION_REFUSED.
Что я пробовал:
пересборка на стороне сервера — команда sudo ./launcher rebuild app выполняется успешно, но поведение сайта не изменилось
также пробовал закомментировать плагины и выполнить пересборку, но изменений нет
безопасный режим — запрос /safe-mode сразу приводит к странице ошибки ERR_FAILED в Chrome
Нет, ваш сайт не восстановлен, он полностью недоступен. Вы частично видите кэш. Для того, кто никогда не посещал ваш сайт, он вообще не отвечает. Скорее всего, проблема на уровне сети/фаервола, либо nginx не запускается или падает.
После выполнения команды sudo ./launcher enter app кажется, что nginx запущен…
root@adn-prod-app:/var/www/discourse# ps aux | grep nginx
root 548 0.0 0.0 2156 64 ? Ss 07:04 0:00 runsv nginx
root 558 0.0 0.1 55236 2524 ? S 07:04 0:00 nginx: master process /usr/sbin/nginx
www-data 567 0.0 0.2 55996 5068 ? S 07:04 0:00 nginx: worker process
www-data 568 0.0 0.0 55996 1628 ? S 07:04 0:00 nginx: worker process
www-data 569 0.0 0.0 55792 1680 ? S 07:04 0:00 nginx: cache manager process
root 23179 0.0 0.0 6140 884 pts/1 S+ 21:23 0:00 grep nginx
Я недостаточно знаком с Google Cloud, чтобы знать, на что обращать внимание в настройках сети/брандмауэра… Я отмечаю, что у экземпляра VM есть теги “http-server” и “https-server”, и что их система брандмауэра, по-видимому, использует эти теги для применения встроенных правил “default-allow-http” и “default-allow-https” к экземплярам с этими тегами. Это кажется мне правильным, и nslookup показывает, что используемое поддоменное имя разрешается во внешний IP-адрес, указанный в интерфейсе Google, однако внешний мир по-прежнему не может получить доступ к экземпляру.
Привет,
это может быть маловероятно, но в прошлый раз, когда я видел ошибку Redis, она каким-то образом была связана (ну, скажем, в той же теме) с SSL-сертификатами (отсутствуют?).
Возможно, команда ./launcher logs app могла бы помочь?