Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
2 curtidas
Olá,
Introdução
Obrigado pela solução, @fefrei! Implementamos isso em https://community.hiveeyes.org/ e funciona perfeitamente.
Mais reflexões
No entanto, gostaríamos de referenciar a questão relacionada de @mlinksva em Site maintenance mode during rebuilds? aqui, pois isso também ressoa conosco e ainda não é resolvido pela solução /errorpages. Trata-se de melhorar o texto genérico “Desculpe, não foi possível carregar esse tópico, possivelmente devido a um problema de conexão.”. Tentaremos detalhar isso com mais profundidade.
Servindo discourse_offline.html
Isso é perfeito quando os usuários chegam pela primeira vez ao site.
Servindo um texto diferente de “Desculpe por isso”
No entanto, ao navegar dentro do Discourse, ele vai gritar com você assim:
sem revelar nada sobre o motivo.
Como já conhecemos você, provavelmente haverá um recurso de personalização para alterar esse texto, certo? Talvez tenhamos apenas perdido isso. Também não investigamos se o recurso Admin » Backup » Habilitar somente leitura já resolveria isso, conforme descrito em Maintenance Mode?.
De qualquer forma, fez sentido para nós trazer esse tópico aqui novamente e esperamos que não se importe se isso fosse tolo.
Com cordiais saudações,
Andreas.
P.S.: @staff: Como essa discussão de alguma forma saiu do controle em relação aos detalhes apropriados de configuração do Nginx ou servidor web, gostaria de sugerir uma refatoração completa, dividindo esses posts em um tópico com nome adequado, como “Configurando o servidor web para a página offline”. Tenho certeza de que vocês encontrarão um bom título. Obrigado desde já se gostarem da sugestão e acharem que vale a pena segui-la.
Agora, na verdade, nos sentimos bobos ao encontrá-lo imediatamente como um bloco de texto personalizável do site:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
Alteramos o texto padrão js.topic.server_error.description para:
Obrigado por ouvir ;].
3 curtidas
Hm. Não temos certeza se alterar esse texto realmente funciona para nós. Precisamos considerar algo especial aqui ao modificar esse elemento?
Além disso, gostaríamos de mencionar que, durante um intervalo de tempo específico em que o site estava fora do ar, ele exibia uma mensagem diferente, como:
Você tem alguma ideia de como poderíamos alterar isso também?
1 curtida
Eu uso isso, mas quero uma página web offline personalizada e não estou conseguindo fazer isso.
Guia maravilhoso.
Mas se você tivesse incluído alguns comandos para renovar automaticamente esse certificado também, seria um guia completo.
Porque eu vi o link mencionado aqui. Mas esse link apenas ensina a instalar o certificado do zero ou a renová-lo.
Mas não consegui encontrar orientações sobre como “renovar automaticamente” o mesmo.
Obrigado.
1 curtida
Ótimo ponto! Atualizei esta seção acima na postagem original 
1 curtida
Alguém mais notou que está vendo um erro 500 mais genérico quando a atualização ocorre? Talvez eu tenha pegado um momento ruim?
1 curtida
Quando o contêiner é interrompido durante uma reconstrução, nada está em execução para gerar um erro 500.
4 curtidas
Alguém já tentou usar outro contêiner Docker para isso, a fim de evitar todos esses passos manuais, como sugerido no início?
Sim, muitos já o fizeram. Veja Move from standalone container to separate web and data containers. Note que containers separados exigem uma instalação mais complexa, e muitos dos guias aqui no Meta assumem uma instalação em container único (standalone). Antes de migrar para containers separados, certifique-se de entender o que cada um dos dois containers faz e como você interagirá com eles daqui para frente. O ponto mais importante a notar: app não será mais um destino válido para o comando ./launcher.
5 curtidas
hmm, por algum motivo, este tópico ainda menciona “nginx na frente” em duas postagens…
a propósito, o que eu realmente quero é:
- ter a página offline discutida aqui
- redirecionar http → https e o domínio raiz → www no meu servidor web. Não quero usar o Cloudflare para isso porque alguns de seus IPs estão banidos na Rússia.
Então, conforme entendi, só preciso descobrir como fazer isso apenas no container web 
Agora estou confuso.
Nenhum desses objetivos requer uma configuração de contêiner separado. Você está procurando configurar ambas as etapas acima e, independentemente, está procurando contêineres separados? Ou você estava pensando em contêineres separados achando que são necessários para concluir o acima?
Conforme entendi, o tratamento da página offline (reconstrução) não pode estar no mesmo container, pois ele não estará em execução. Assim, a solução proposta no tópico atual é adicionar o nginx na frente. No entanto, como foi discutido neste tópico, isso requer muitas etapas manuais e é específico do sistema operacional. Por isso, pensei que usar outro container Docker para esse nginx frontal seria mais confiável e mais fácil de manter.
Ah, agora estou acompanhando. Nesse caso, ignore o tópico que vinculei anteriormente. Ele discute a separação do servidor web do Discourse do banco de dados. Isso não é necessário aqui.
Instalar o Nginx em um contêiner Docker, em vez de diretamente no sistema operacional, é definitivamente possível, mas não conheço nenhum guia específico do Discourse para fazer isso. Se seguir por esse caminho, certifique-se de entender o OP deste tópico (as alterações necessárias para criar a página offline e instalar um proxy Nginx na frente) e de que você tem domínio de como o Docker funciona, especialmente na configuração de rede entre dois contêineres Docker. Note também que provavelmente teremos ajuda limitada, pois não temos experiência em fazer isso.
Também percebi que isso não está mais funcionando.
Implementei a abordagem do @fefrei no início de novembro e na época funcionava perfeitamente. Talvez seja porque eu parava o container manualmente e fazia um git pull, em vez de usar /admin/upgrade.
1 curtida
4 posts foram movidos para um novo tópico: Adicionar suporte a uma página offline nativa durante a reconstrução
Fizemos exatamente isso recentemente e a página offline entrou em ação com sucesso.
No momento, acabamos de fazer a atualização online através de /admin/upgrade e descobrimos que o Discourse não foi para o modo offline de forma alguma! Independentemente de isso ter sido melhorado recentemente ou não, ou se simplesmente tivemos sorte desta vez, é ótimo ver uma atualização online ocorrendo sem experimentar nenhum comportamento significativo de tempo de inatividade.
O Discourse nunca deve ficar offline ao executar atualizações através do Docker Manager (/admin/upgrade). Isso costuma acontecer com você? Se sim, devemos iniciar um tópico de #suporte sobre isso.