Atualmente, quando realizamos qualquer tipo de manutenção (exceto simples atualizações) e desejamos tirar o site do ar ou colocá-lo no modo somente leitura, não há como exibir aos visitantes uma mensagem explicando o que está acontecendo ou fornecendo uma estimativa de quanto tempo o sistema ficará inacessível.
Seria ideal contar com um modo offline abrangente que permitisse à administração fornecer atualizações de status e mensagens aos visitantes durante esse período de inatividade, de modo a gerenciar expectativas e fazer com que os visitantes se sintam bem em relação à situação, em vez de ficarem se perguntando o que está acontecendo.
Para registro, aqui está o comentário original que originou essa divisão, conforme mencionado por @jomaxro:
O que realmente precisa ser feito aqui é um modo offline/manutenção integrado que incorpore essa metodologia e a capacidade de exibir mensagens personalizadas aos usuários enquanto o sistema estiver no modo offline e/ou de manutenção.
Isso poderia ser algo integrado ao gerenciador de atualizações (renomear o gerenciador de atualizações para “Gerenciador do Sistema Discourse” e reunir atualizações, logs, processos e backups nessa mesma área).
Isso tornaria o sistema menos frágil, mais amigável e útil tanto para administradores quanto para usuários.
O Docker Manager, o plugin oficial que suportamos para atualizações, não causa nenhuma interrupção. Não deveria haver necessidade de alterações no plugin, pois ele já suporta atualizações sem tempo de inatividade. O problema que este howto aborda são as atualizações (reconstruções) feitas via linha de comando. Essas são necessárias apenas ocasionalmente, algumas vezes por ano, quando precisamos atualizar uma dependência subjacente, como a versão do Ruby ou do Postgres.
Não é possível fazer com que o Docker Manager lide com esse tipo de atualização, pois o Docker Manager, assim como todo o Discourse, fica indisponível durante uma reconstrução. Qualquer solução deve estar fora do Discourse, como a solução de proxy Nginx fornecida neste tópico.
Hmm, acho que há outras opções aqui que estariam mais alinhadas com a natureza do Discourse… Em vez de rejeitar esse conceito, vamos conversar sobre maneiras de melhorar a experiência geral nesse aspecto, especialmente se um administrador precisar — por um motivo ou outro — tirar o site do ar para manutenção.
Uma ideia que me vem à mente: por que não incorporar a solução de proxy Nginx mencionada pelo autor original (OP) na configuração do Docker? Assim, ela se tornaria mais previsível, gerenciável e consistente tanto para usuários e administradores do Discourse quanto para o suporte (pessoas como você aqui no fórum), em vez de lidar com soluções desacopladas como a opção apresentada aqui?
Não tenho a intenção de descartar o conceito, apenas estou afirmando que usar um plugin do Discourse para resolver isso não funcionará. Vou mover essa discussão para um tópico dedicado de #recurso para uma discussão adequada.
@mreach, por favor, edite o OP para detalhar o que você está procurando e como gostaria que funcionasse. Sinta-se à vontade para editar o título conforme necessário também.
Se você deseja ter interrupções minimizadas durante ./launcher rebuild app, será necessário uma configuração com múltiplos containers.
Isso já está documentado. É uma configuração mais complexa.
Para que o launcher rebuild em modo de container único tenha uma página “offline”, teríamos que substituir o container por um container especial dedicado de “o site está offline”. Isso não é impossível, mas exigiria cerca de duas semanas de engenharia para funcionar perfeitamente. Não acredito que possamos custear isso no momento, dada a raridade da reconstrução de um container e o fato de já termos uma maneira documentada de realizar reconstruções sem interrupções.
A instalação com dois contêineres garante atualizações com tempo de inatividade mínimo na maioria das vezes. Às vezes, a construção do novo contêiner executa uma migração que derruba o site em execução. Existe uma maneira de contornar isso, mas é bastante complicada e essas atualizações ocorrem com pouca frequência.
Você também pode alterar o apontamento do seu DNS (ou usar um IP elástico ou o que a Digital Ocean chamar disso) e iniciar uma instância (ou o que a AWS chamar disso) com um servidor web contendo sua mensagem de status.
A propósito, @jomaxro, como você separou minha postagem para este novo tópico aqui? Quais foram os passos que você seguiu? Seria bastante útil saber… Não estou vendo nenhuma metodologia para isso no Discourse padrão.