Informações de contexto: o site é lot.almost-dead.net, versão 2.8.0.beta4, hospedado no Google Cloud/Compute; segui o guia oficial baseado em Docker para configurá-lo. (Tenho proficiência em tecnologias de front-end para navegadores e compreendo os princípios gerais de hospedagem em nuvem, mas estou familiarizado com AWS e não com o Google.)
Causa preliminar: parei a instância da VM e depois a reiniciei (tentando ajustar as variáveis de ambiente expostas ao Discourse).
Quando a VM voltou e o site ficou no ar, notei que os ativos de JS estavam com tempo esgotado, assim como alguns avatares de usuários. No painel de administração, a área de Saúde da Comunidade não carrega; o spinner continua girando e, nas Ferramentas de Desenvolvedor do Chrome, a aba Rede mostra que as solicitações /message-bus/.../poll estão todas falhando. A página de Atualização (/admin/upgrade) falha quase imediatamente e o Chrome exibe o código de erro ERR_FAILED. Ao navegar pelos tópicos, vejo solicitações POST falhando com ERR_CONNECTION_REFUSED e solicitações GET iniciadas por JS falhando com ERR_FAILED. (Isso é a partir de um navegador com cookies de login configurados para minha conta de administrador.)
Carregar o site a partir de uma nova instância do navegador mostra o erro ERR_CONNECTION_REFUSED do Chrome.
O que tentei:
reconstrução no lado do servidor — sudo ./launcher rebuild app parece ter sucesso, mas não há mudança no comportamento do site
também tentei comentar os plugins e reconstruir, ainda sem mudança
modo seguro — solicitar /safe-mode resulta imediatamente na página de erro ERR_FAILED do Chrome
Não, seu site não voltou a funcionar, está completamente fora do ar. Você está vendo parcialmente o cache. Para alguém que nunca visitou seu site, ele não responde de forma alguma. Isso provavelmente é algo no nível de rede/firewall, ou o nginx não está iniciando/crashing.
Assim que executo sudo ./launcher enter app, parece que o nginx está rodando…
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
Não estou familiarizado o suficiente com o Google Cloud para saber o que procurar nas configurações de rede/firewall deles… Notei que a Instância da VM tem as tags “http-server” e “https-server” e que o sistema de firewall deles parece usar essas tags para aplicar as regras integradas “default-allow-http” e “default-allow-https” às instâncias com essas tags. Isso parece correto para mim, e o nslookup mostra que o subdomínio que estou usando está resolvendo para o endereço IP externo listado na interface do Google, no entanto, o mundo exterior ainda não consegue acessar a instância.
Olá,
é um palpite, mas da última vez que vi um erro do Redis, ele estava de alguma forma relacionado (bem, digamos que no mesmo tópico) aos certificados SSL (ausentes?).
Talvez ./launcher logs app possa ajudar?
Parece que meu problema era que a VM voltou com um endereço IP diferente, e eu precisava modificar meu registro A para apontar para o novo endereço.