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 da Cloudflare. O contêiner duplo minimiza o tempo de inatividade e meus dois fóruns principais 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 fora do ar é feia e não dá nenhuma dica sobre quanto tempo ela ficará offline.
por exemplo, para um site em your-domain.com eu simplesmente uso uma rota do Cloudflare Workers definida como *yourdomain.com/* (inclua os asteriscos).
Passo 1: Criar a página do worker
você pode configurar a página de manutenção na página de configurações workers & pages na Cloudflare - clique no botão create application:
então use o modelo hello world:
então dê um nome a ele e clique em deploy:
então vá para a página de visão geral dessa página de manutenção e clique em edit code:
e cole este código na janela de código worker.js (substitua seu domínio e qualquer mensagem que você quiser, edite o texto, a cor do texto, o fundo, etc):
export default {
async fetch(request, env, ctx) {
try {
// Busca a solicitação original do seu servidor
const response = await fetch(request);
// Se SEU SITE estiver alternando contêineres, ele gera um 502, 521 ou 530
if (response.status === 502 || response.status === 521 || response.status === 530) {
return returnCustomErrorPage();
}
// Se tudo estiver bem, retorna o tráfego normal do fórum
return response;
} catch (e) {
// Se o servidor estiver completamente inacessível
return returnCustomErrorPage();
}
}
};
function returnCustomErrorPage() {
const html = `
<!DOCTYPE html>
<html lang="pt-BR">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Atualização do Sistema - YOUR-SITE.com</title>
<style>
body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; text-align: center; padding: 50px; color: #333; background-color: #f9f9f9; }
h1 { font-size: 2.5em; margin-bottom: 0.5em; color: #9400D3; }
p { font-size: 1.2em; line-height: 1.5; }
.container { max-width: 600px; margin: 0 auto; background: white; padding: 40px; border-radius: 8px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); }
</style>
</head>
<body>
<div class="container">
<h1>Apenas uma breve janela de atualização</h1>
<p><strong>YOUR-SITE</strong> está passando por uma breve atualização de sistema de 30 segundos.</p>
<p>Tomem um gole rápido da sua bebida — esta página será atualizada automaticamente assim que estivermos de volta online.</p>
</div>
<script>
// Verifica automaticamente se o site está de volta a cada 10 segundos
setInterval(function() {
window.location.reload();
}, 10000);
</script>
</body>
</html>
`;
return new Response(html, {
status: 503, // 503 é o melhor para SEO para que o Google não penalize você pelo tempo de inatividade
headers: {
"Content-Type": "text/html;charset=UTF-8",
"Retry-After": "30"
}
});
}
deve ficar mais ou menos assim. clique em deploy para salvá-lo:
Passo 2: Adicionar a rota
agora vá para a página de rotas do Cloudflare worker e clique no botão add route para abrir o novo modal de rota, preencha a rota do domínio e selecione a página do worker que você acabou de criar, depois clique em salvar:
Passo 3: Executando atualizações ou reconstruções
agora, quando você fizer ssh no seu servidor e executar suas atualizações do sistema ou fizer uma reconstrução, em vez de uma página de site fora do ar ou erro, esta página será exibida quando o tempo de inatividade realmente ocorrer (eu uso 30 segundos no meu porque esse é o máximo para meus sites)
eu costumo adicionar e excluir minha página de rota de workers sempre que estou fazendo manutenção, mas alguns gostam de simplesmente deixá-la lá o tempo todo (eu deixo o código real da página, apenas adiciono e removo a rota).
acho que é isso.
Opcional: Executar atualizações com um script e agendar
eu também uso um script de shell unix no meu servidor para executar a atualização específica do contêiner duplo, que eu criei assim:
cat << 'EOF' > /root/update-web.sh
#!/bin/bash
cd /var/discourse
echo "➡️ Baixando os scripts mais recentes do Discourse docker..."
git pull
echo "➡️ Preparando novo contêiner web em segundo plano (leva ~8 mins)..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Bootstrap bem-sucedido! Alternando contêineres..."
./launcher destroy web_only && ./launcher start web_only
echo "🚀 Pronto! Site atualizado com quase zero tempo de inatividade."
else
echo "❌ Bootstrap falhou! Abortando a alternância para manter o site atual online."
fi
EOF
chmod +x /root/update-web.sh
então eu o executo no prompt de root no meu servidor com o comando ./update-web.sh.
edição: não execute as etapas abaixo a menos que você tenha uma conta paga da Cloudflare.
você pode automatizá-lo para um horário específico, como 1 da manhã de domingo no seu horário local com um trabalho cron. para mim 1:00am local é 8:00 AM UTC, (você pode descobrir a data UTC do seu servidor digitando date no prompt de comando quando conectado via ssh).
então:
execute este comando para abrir o agendador de tarefas do seu servidor:
crontab -e
(se ele pedir para você escolher um editor, selecione seu editor preferido, 1 para nano é provavelmente o mais fácil)
eu rolo até o final dos comentários e colo isso:
0 8 * * 0 /root/update-web.sh >> /var/log/discourse-update.log 2>&1
(o que significa executar o arquivo /root/update-web.sh no minuto 0, hora 8 (UTC), toda manhã de domingo)
então salve e saia (se você estiver usando nano):
Ctrl + Opara salvar.Enterpara confirmar.Ctrl + Xpara sair.
então eu posso executar cat /var/log/discourse-update.log quando acordo nas manhãs de domingo para verificar se ele foi executado corretamente. se você usar um agendador de tarefas cron, então você quererá deixar a rota da página de workers.
acho que é tudo. me avise se você tiver dúvidas rs. é muito mais simples do que eu fiz parecer rs. 
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?