Maybe we just implemented the offline page because we started using the upgrade procedure »stop container, git pull, launcher rebuild« after being hit by things like [1,2,3] for a few times actually.
Maybe something changed on the robustness of killing PostgreSQL if it wouldn’t shutdown in time to run through the upgrade process smoothly.
Either way, the online upgrade (again) worked well for us when giving it another shot right now. So, nevermind and sorry for the noise.
Isso é um pouco confuso, já que o que se segue é um guia para instalar e configurar o nginx fora do contêiner.
De qualquer forma, hoje percebi um benefício adicional dessa configuração externa do nginx: Se você está acostumado a ver endereços IP 127.0.0.1 ou seu endereço Docker (provavelmente começando com 172.) como endereço de IP de registro ou login, pode ter sido porque o tráfego IPv6 encaminhado para o contêiner não levava seu endereço IPv6 junto, ao contrário do IPv4. Com essa configuração, agora você verá endereços IPv6 corretos em vez de endereços locais.
Em outras palavras, essa configuração é essencialmente necessária para o funcionamento correto de uma ferramenta administrativa útil na internet cada vez mais IPv6. (Nos EUA, isso inclui muito tráfego móvel.)
Obrigado por este guia muito útil! Alguns comentários:
Acho que sudo apt-get install letsencrypt foi substituído por sudo apt-get install certbot. Ao executar o primeiro, recebo a mensagem Nota: selecionando 'certbot' em vez de 'letsencrypt'.
Um amigo notou que o compartilhamento do site no Facebook mostrava uma prévia de “301 moved permanently”.
Edição: Inicialmente, eu substituí a seção location / do bloco de servidor da porta 80 pela seção location / do bloco de servidor da porta 443. Mas acho que isso é redundante. Em vez disso, apenas excluí o bloco de servidor da porta 80, que servia como bloco de redirecionamento, e adicionei:
listen [::]:80;
listen 80;
na seção apropriada do bloco de servidor principal.
Também ativei o redirecionamento para HTTPS (não tenho certeza se isso é necessário) nas configurações do Discourse.
Isso resolveu o problema com o compartilhamento no Facebook, e parece que as solicitações HTTP regulares estão sendo redirecionadas para HTTPS. Se houver outro ou melhor método, por favor, me avise.
Obrigado pelo tutorial, está ótimo. Agora minha página 502 parece muito melhor.
No meu caso prático, preciso adicionar a configuração do nginx ao arquivo /etc/nginx/sites-enabled/discourse.conf.
Instalei o Discourse com sucesso após o nginx estar rodando o WordPress.
Encontrei o problema de o nginx não reconhecer o certificado renovado porque ele não foi reiniciado após a instalação, seguindo este guia. Para mim, a solução foi:
Obrigado pelo tutorial, que funciona muito bem para mim.
Estava apenas me perguntando: se, por exemplo, o Googlebot ver essa página de erro, ele saberá que se trata de uma página temporária? Ou precisamos enviar algum tipo de código de erro para torná-lo ciente da natureza temporária da alteração?
Prefiro não ver o Google remover todo o índice do meu fórum por causa de uma página de erro mais elaborada…
O Google deve interpretar os erros 500/502 como um sinal para ‘voltar mais tarde’. Desde que seu site não esteja sendo reconstruído com muita frequência, você não deverá ter problemas.
Tenho executado meu fórum atrás do nginx há bastante tempo e isso não afetou negativamente o ranqueamento.
Isso significa: "Ao encontrar (ou gerar) um código de resposta 502 Bad Gateway, envie o conteúdo do arquivo /errorpages/discourse_offline.html com um código de resposta 502 Bad Gateway. O = é o que indica qual código de resposta HTTP deve ser enviado.
Está tudo certo!
E concordo com @ashs; um minuto ou menos de erro 502, uma ou duas vezes por mês, não prejudicou a indexação nos buscadores. Frequentemente vejo postagens recentes retornadas nos resultados do Google.
Um erro 502 provavelmente indica que o Nginx não está iniciando, possivelmente devido a um erro de configuração. Executar nginx -t informa se o arquivo de configuração está correto. Se não houver erros, execute systemctl status nginx.service para verificar o status do serviço Nginx.
Minha pergunta está diretamente relacionada ao título do tópico, mas não ao método usado aqui, então espero que esteja tudo bem mantê-la nesta discussão.
Configurei algo muito simples para resolver esse problema e tenho uma pergunta específica.
Criei um droplet separado na DigitalOcean e instalei um servidor LAMP via marketplace. Em seguida, fiz upload de uma página HTML básica com algumas imagens para indicar que o servidor estava em manutenção. Depois, alternaria um IP entre meu servidor Discourse regular e esse servidor de manutenção, conforme necessário.
Aqui está a pergunta: para que o servidor de ‘manutenção’ carregasse corretamente, precisei obter um certificado via certbot para esse servidor (além do que já tinha para a instância principal do Discourse). Ou seja, 2 certificados para o mesmo domínio em servidores diferentes. Funcionou, mas sempre me preocupei se isso poderia causar problemas no futuro. O que li online sugere que isso é aceitável, mas gostaria de saber se alguém já teve experiência direta com isso.
Isso é perfeitamente válido. No entanto, dependendo de como você realizou a validação, as renovações de certificado podem não funcionar — por exemplo, se o seu servidor de “manutenção” estiver usando validação baseada em HTTP, isso falhará enquanto o domínio não estiver apontado para ele, o que provavelmente anula o propósito. Pode fazer sentido que o servidor de manutenção copie ocasionalmente o certificado mais recente do servidor principal, em vez de solicitar um novo ao Let’s Encrypt.
Vou admitir que não faço a menor ideia se o meu servidor está usando validação baseada em HTTP (fiz tudo através daquele incrível certbot), mas sua preocupação é totalmente lógica. Procurei um pouco, mas não encontrei nenhum recurso sobre como copiar certificados como você sugeriu. Além disso, imagino que eu precise de algum tipo de configuração de cron job. Se você tiver mais alguma sugestão, seria ótimo. Caso contrário, obrigado novamente pela sua ajuda.
Para copiar arquivos diretamente de servidor para servidor, scp ou rsync são boas ferramentas para usar – este pode ser um bom ponto de partida.
Minha sugestão seria, de fato, configurar uma tarefa cron para copiar o certificado do servidor principal para o servidor de manutenção regularmente
Ah, e para explicar o contexto da validação baseada em HTTP: para verificar se o domínio realmente pertence a você, o Let’s Encrypt solicitará um arquivo específico do seu servidor e aguardará uma resposta determinada. O Certbot pode lidar com isso automaticamente (configurando seu servidor temporariamente para retornar esse arquivo para a solicitação de validação), mas, claro, isso só funciona se a solicitação realmente chegar ao seu servidor. Se seu DNS não apontar para o seu servidor ou se você mudou o IP para outro lugar, a solicitação irá para o servidor errado, o Let’s Encrypt não receberá a resposta esperada e se recusará a assinar o certificado.
Se você quiser uma página “em construção” enquanto o site é reconstruído, você precisará realizar os passos onerosos acima. Eu recomendaria mudar para uma instalação de 2 contêineres, que é um pouco mais complicada de manter (você tem que saber quando reconstruir o contêiner de dados), mas tem apenas cerca de 30 segundos de inatividade quando o novo contêiner é iniciado, mas requer uma quantidade razoável de RAM no momento (2 GB pode não ser suficiente, mas não tenho certeza).
