Ocorreu um erro na minha atualização
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Por favor, ajudem-me a corrigi-lo.
E aí!
Não estou respondendo à sua pergunta, só estou curioso. Por que você acha que precisa de uma página de manutenção? Parece bastante chato de configurar para pouco benefício.
Minhas instâncias ficam fora do ar por 5 minutos por mês para atualizações e é basicamente isso.
Sempre que eu fazia alterações significativas, como instalar plugins, por exemplo, às vezes levava 20 minutos.
Não é um grande problema, se considerarmos que isso não é feito toda semana ou mesmo todo mês, mas para um visitante novo, aquela página feia indicando que algo não está funcionando, não é uma boa primeira impressão. Até mesmo para visitantes recorrentes que não sabem que o site estará fora do ar, isso pode colocá-los em “modo de pânico”, pensando que toda a comunidade foi desativada ou algo assim, talvez alguns deles me enviando e-mails imediatamente perguntando o que está acontecendo.
Acho que é apenas um toque agradável para o visitante, novo ou antigo, para informá-los do que está acontecendo.
Se essa abordagem sugerida pelo Claude é algo que leva apenas alguns minutos, mas não precisa ser feita novamente, acredito que seja um tempo bem investido.
Leva apenas segundos se você migrar para a instalação com dois contêineres.
Você pode até agendar a migração para a noite, se realmente quiser, enquanto você e/ou seu público principal estiverem dormindo.
Você não precisa de uma página de manutenção.
Eu uso a construção de contêiner duplo atrás do CDN do Cloudflare. O contêiner duplo minimiza o tempo de inatividade e meus dois principais fóruns de produção têm no máximo 30 segundos offline durante as reconstruções. Gosto de ter uma página de manutenção porque a página padrão de servidor web está inativa é feia e não dá nenhuma dica sobre quanto tempo ficará offline.
A documentação para fazer isso está agora aqui:
Uau! Agradeço muito esse tutorial detalhado! 
Acabei de salvar sua resposta nas minhas anotações, então, quando eu instalar o Discourse novamente em breve, voltarei a consultá-la. Com certeza vou te contar como foi, mesmo que demore um pouco para eu fazer a instalação. No momento, estou terminando algumas coisas de codificação e só depois voltarei a me concentrar no Discourse.
E concordo que a página “web serve is down” seja feia, e para usuários inexperientes, essa mensagem não significa muito. Ter uma página de manutenção simples com uma mensagem personalizada é sempre preferível, mesmo que isso envolva algum trabalho de configuração.
Mais uma vez, obrigada muito por dedicar tempo para compartilhar isso. Espero que outras pessoas também achem útil 
E eis o problema.
Não é uma mudança simples e envolve infraestrutura adicional para se preocupar e manter, e, na minha opinião, definitivamente não vale a pena por alguns segundos de indisponibilidade.
Entendo o que você quer dizer, mas esse é apenas um caso. E se algo realmente quebrar e eu precisar corrigir, levando mais do que alguns segundos?
Além disso, como você está obtendo alguns segundos de indisponibilidade, enquanto eu estava vendo cerca de 20 minutos, após instalar plugins?
Porque na configuração com dois contêineres (vinculada em ambas as nossas postagens e uma dependência não negociável) você inicializa a nova compilação usando ./launcher bootstrap web_only (durante o qual seu site permanece 100% funcional), em seguida, você simplesmente destrói e inicia imediatamente o novo contêiner já compilado (o que leva segundos).
Ah, ok, isso ainda é para a configuração com 2 contêineres. Eu achei que você estava dizendo que não valia a pena o trabalho de construir a configuração com 2 contêineres completamente. O que você está dizendo que não vale a pena é apenas o trabalho extra da página de manutenção, certo?
Pessoalmente, sim.
Se você quiser redundância para os usuários da web que aparecerem com navegação atualizada durante os 30 a 60 segundos, então uma página de manutenção é justa.
Você tem que pesar o benefício disso contra o tempo necessário para manter a infraestrutura ao redor.
Agora entendi. Obrigado.
Então, minha pergunta é: com 2 contêineres, aquelas 20 minutos mais ou menos ainda continuam sendo um problema, a única diferença é que posso deixar que ele faça isso em um dos contêineres, o que não está ativo, e quando estiver pronto, fazer a troca. É assim que funciona?
Sim, ainda leva um tempo para construir o container. E, por falar nisso, você precisa garantir que seu servidor seja robusto o suficiente para permitir que esse processo ocorra em paralelo enquanto atende sua comunidade normalmente (essencialmente, o mais importante é garantir memória suficiente para começar – então, é muito importante ter SWAP suficiente). A compilação também ocupará pelo menos um núcleo, então considere ter um servidor com 1 ou 2 núcleos a mais.
e parece ser um servidor menos eficiente…?Recomendo pelo menos 4 GB e 3 núcleos (“vcpu”) para esse tipo de configuração …
Para referência, já que foi perguntado em outro tópico, a (edição: errada) resposta: Any cheaper alternatives to Hetzner? - #2 by Canapin
Este é o único que corresponde a isso… que diferença de preço…
Acho que vou ter que construí-lo com um único container agora e, quando chegar a hora (
), fazer o upgrade.
Obrigado pelas informações, Robert!
discordo e acho que vale a pena ter a página de manutenção. Na minha experiência, quando as pessoas veem a página de erro do Discourse, a primeira coisa que fazem é atualizar a página, e então elas verão a breve página de manutenção, que recarregará o site automaticamente quando a troca de contêineres estiver concluída. Não é muito trabalho para configurar e você só precisa fazer isso uma vez. Durante uma reconstrução com a configuração de contêineres duplos, a parte de inicialização acontece em segundo plano e os usuários ainda podem usar o site; é a troca de contêineres que causa a breve interrupção (ao contrário de uma configuração padrão de contêiner único).
custo do servidor e seleção são coisas completamente diferentes e devem estar em outro tópico separado.
Acho que estou no meio do caminho agora. Entendo o que você quer dizer, assim como @merefield. É um toque bacana ter isso, e se for configurado apenas uma vez, não é um grande problema, eu acho?
Ao mesmo tempo, se realmente levar até 60 segundos, no pior dos casos, nem todo mundo vai acessar o site exatamente no segundo 0 e ter que esperar 60 segundos. Algumas pessoas verão a página feia por 5 segundos, outras por 20, outras por 60. Algumas pessoas nem verão (acho?) por exemplo, se estiverem apenas lendo uma resposta ou escrevendo uma, essa troca pode acontecer antes que elas cliquem em ENVIAR ou antes que parem de ler o tópico e cliquem em RESPONDER (ou acessem outra página).
Minha questão com a rota do nginx estava mais relacionada à coisa dos 20 minutos em uma configuração de um único container. Com a opção de ter 2 e passar de 20 minutos para talvez no máximo 60 segundos, me pergunto se é realmente relevante? Especialmente se eu puder adicionar um anúncio no topo dizendo que as coisas ficarão indisponíveis por apenas alguns segundos, em um horário de baixo tráfego, isso não será um grande problema?
Preciso sentar e pensar sobre isso. A configuração de 2 containers definitivamente será algo a implementar, se eu encontrar uma boa oferta de servidor.
Você pode esclarecer isso de uma forma que uma pessoa leiga como eu possa entender? Ainda não estou familiarizado com workers…
Por que você adiciona e remove a página de rota dos workers, se deixá-la não é um problema? Então, se eu adicionar a página de manutenção, posso realmente configurá-la uma vez e, a partir desse momento, sempre acessar meu servidor via SSH no Terminal e fazer tudo lá, como faço com um único container, sem nunca precisar ir ao Cloudflare?
@merefield mencionou que isso (página de manutenção, workers, etc.) também é algo que precisa ser mantido, então me pergunto se é realmente algo que você configura e esquece, ou se há algo que precisa ser feito de vez em quando?