Olá, é normal o site ficar offline ao instalar/atualizar temas e plugins?
1 curtida
É normal que o site fique offline ao fazer uma reconstrução.
As soluções são usar uma instalação de dois contêineres, que permite construir um novo contêiner, de modo que o tempo de inatividade seja inferior a um minuto, ou criar uma página “voltaremos em breve” para exibir enquanto o site estiver inativo, o que não altera o tempo de inatividade, mas todos saberão que você está ciente de que seu site está inativo.
Todos acham que pelo menos uma dessas soluções é muito difícil e totalmente sem valor.
4 curtidas
Apenas para acrescentar, ao contrário dos plugins, a instalação ou atualização de temas e componentes de temas não exigiria nenhum tempo de inatividade. 
4 curtidas
Existe alguma documentação sobre o método que você mencionou? Além disso, parece irônico, considerando que é muito adequado para SEO em termos de discurso, mas há uma interrupção durante o carregamento e os robôs do Google não conseguem rastrear o site.
Quantas vezes você espera instalar um novo plugin? Isso geralmente é uma ocorrência muito rara.
Você pode atualizar plugins online com interrupção mínima do serviço, pois os contêineres são trocados.
2 curtidas
Obrigado pelas respostas. 
1 curtida
Dê uma olhada em Add an offline page to display when Discourse is rebuilding or starting up quando se sentir corajoso.
2 curtidas
Olá 
Não tenho certeza e talvez eu esteja errado (ainda não tentei), mas isso agora é uma coisa principal? Existe um novo template há alguns meses em discourse/templates chamado offline-page.template.yml e dentro dele ele aciona o GitHub - discourse/discourse-offline-page: offline page for discourse. Que é o site HTML estático durante o carregamento do Discourse. Há também um PR sobre isso em discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
3 curtidas
Parece que isso só atingiria metade disso? Apareceria ao iniciar, mas não ao reconstruir, se eu entendi bem as reconstruções:
Adiciona um template para buscar e servir arquivos HTML estáticos de GitHub - discourse/discourse-offline-page: offline page for discourse quando o nginx estiver disponível, mas o rails não.
^ O PR do github
2 curtidas
Mas um passo na direção certa, obrigado @Don (e @featheredtoast ! )
Sim @Firepup650 eu me perguntei por que eu não tinha visto isso, e acredito que você respondeu o porquê!
Tem uns bons 
aqui! 
Eu me pergunto se este é um passo prévio para uma configuração permanente padrão de dois contêineres, onde um contêiner nginx é construído separadamente?!??! 
2 curtidas
Você me pegou - há um movimento em andamento para tornar o serviço de páginas offline mais amplamente possível - os commits e repositórios mencionados são a base para que isso esteja disponível, mas ainda não está implementado.
5 curtidas
Por algum motivo, nenhum dos meus usuários vê isso em reconstrução. Bem, pelo menos no chat, e é por isso que houve alguns incidentes em que um usuário perdeu apenas a mensagem escrita.
Minha opinião é que a situação em que não informamos absolutamente nada sobre o tempo de inatividade para usuários já logados é o maior problema de UX único no Discourse. Claro, posso entender as explicações de onde vem a natureza desse aplicativo, e os desenvolvedores meio que se pintaram em um canto desde o início (situações semelhantes às com rascunhos e algumas outras coisas), mas isso não apaga o problema em si.
Temos algumas soluções alternativas. Usar o Nginx como proxy reverso na frente do Discourse exibindo uma página de erro ajustada é uma delas. E quando um administrador tem problemas, a resposta será “apoiamos apenas o padrão”. Esse foi o motivo real pelo qual desisti disso.
Dois contêineres diferentes são uma solução. Ou pelo menos mantém o tempo de inatividade muito curto. Há muitos avisos sobre isso, então estou um pouco assustado em seguir esse caminho.
Ou podemos atualizar apenas às vezes, informar os usuários antes que aconteça e desativar o acesso público. Sim, essa é uma solução, mas… agora é o ano de 2024 e apenas o sistema bancário usa isso em meu ambiente 
Usar um servidor de staging é algo que deveria ser feito. Bem, essa é uma solução de nível corporativo, cara e bastante difícil quando feita corretamente, e ama sua própria equipe de TI.
Portanto, os novos planos vazados 
são uma melhoria real, de fato. Bem, se precisar de contêineres separados, então é hora de mergulhar de cabeça, suponho.
1 curtida
É exatamente a mesma coisa, exceto que raramente você também precisa reconstruir o contêiner de dados.
1 curtida
Mas o tempo de inatividade é muito mais curto do que esse tipo de 20 minutos, não é?
1 curtida
O chat pode ter coisas diferentes da visualização normal do site, pois acredito que seja um acesso mais em tempo real em comparação com a capacidade de cache de páginas.
Concordo. A manutenção anunciada e planejada, na minha opinião, é melhor como nos velhos tempos dos BBSs baseados em DOS. Havia uma opção para ter uma mensagem do sistema alertando que o desligamento planejado estava chegando e desconectaria os usuários no horário designado. Naqueles dias, era tipicamente para fazer pacotes de e-mail entre BBSs em rede.
1 curtida
Sim. O tempo de inatividade geralmente é inferior a um minuto, mas você precisará de RAM ou swap suficientes para reconstruir um contêiner enquanto o outro é criado.
1 curtida