Sim, eu faria isso em etapas:
se nesse ponto você estiver satisfeito, pare por aqui, ou:
Haha, estou feliz que você tenha perguntado, porque eu não tive tempo para explicar essa parte (eu deveria ter – há muito o que explicar e o Cloudflare é complexo!).
Quando a rota do worker está configurada, cada carregamento de imagem e visualização de página no fórum passa por esse worker.
O plano gratuito de CDN do Cloudflare inclui um limite de 100.000 solicitações por dia em uma rota de worker.
Portanto, se você tiver um fórum relativamente movimentado, para evitar atingir o limite do plano gratuito em um dia, é uma boa ideia não mantê-lo ativo o tempo todo. Isso se refere apenas à rota do worker, não à página de manutenção – você pode deixar a página de manutenção ativa o tempo todo; ela só será acessada se a rota do worker estiver ativa. Trata-se apenas da etapa 2 onde você atribuiu a rota (que é fácil de configurar e remover). A menos que você esteja usando um plano pago do Cloudflare, é uma boa prática mantê-lo ativo apenas quando estiver realizando sua própria manutenção.
remove para desanexar a página do worker da rota.Se você estiver em um plano pago do Cloudflare, não há nada com que se preocupar. No entanto, nesse caso, você pode usar as páginas de erro do Cloudflare em vez de uma página de worker… (eu mencionei que o Cloudflare é bastante complexo? LOL)
configuração avançada de administrador abaixoSe alguém quiser automatizar totalmente suas atualizações no plano gratuito, deve usar um token de API do Cloudflare, seu ID de zona e um comando curl para obter o route id (ID da rota) do worker. Em seguida, edite o script /root/update-web.sh com algumas coisas mais divertidas para ativar e desativar a rota do worker automaticamente:
#!/bin/bash
cd /var/discourse
CF_TOKEN="your_actual_token_here" #<---Token de API do Cloudflare
ZONE_ID="xxxx" #<---da sua página de perfil do Cloudflare
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"
echo "➡️ Baixando os scripts mais recentes do Docker do Discourse..."
git pull
echo "➡️ Iniciando o container web novo em segundo plano..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Bootstrap bem-sucedido!"
# Ativar o Worker de Manutenção do Cloudflare
echo "🚧 Habilitando a Página de Manutenção..."
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"pattern":"*your-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null
# Trocar os containers (Janela de indisponibilidade de 30 segundos)
echo "🔄 Trocando containers..."
./launcher destroy web_only && ./launcher start web_only
# Desativar o Worker de Manutenção do Cloudflare
echo "🌍 Desabilitando a Página de Manutenção..."
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"pattern":"*your-site.com/*","script":null}' > /dev/null
echo "🚀 Concluído! Site atualizado com zero indisponibilidade visível."
else
echo "❌ Bootstrap falhou! Abortando a troca para manter o site atual online."
fi
Eu uso a versão anterior do script porque não me importo em automatizar tudo e gosto de estar presente para fazer atualizações/reconstruções. Eu apenas adiciono a rota do worker logo antes de fazer uma atualização e a removo depois. Leva apenas alguns segundos para fazer.
Minhas etapas gerais são:
sudo apt update && sudo apt upgrade -y, e reiniciar o servidor se necessário)./update-web.shNão entendo nada de programação nem do mundo do desenvolvimento, além de ter feito uma coisa básica de hello world com Visual Basic há muito, muito tempo. Mas consigo fazer algumas coisas, porque sei administrar melhor meus servidores WordPress e Mastodon/Pixelfed, e de algum jeito também meu Discourse. Além disso, por aí existe aquela tal coisa chamada IA (que não é tão fácil para um iniciante quanto a propaganda faz parecer).
Não sei se isso é de alguma forma possível com o Discourse por causa do Docker, mas no mundo comum de Nginx-Varnish-WordPress, eu construí um sistema onde um servidor Plesk recebe informações sobre erros 50x e exibe uma página de erro. Na verdade, tenho três configurações: o Nginx da frente exibe o conteúdo de um snapshot gerado se o Varnish cair, o Varnish passa a usar o snapshot para conteúdo não em cache quando o backend relacionado ao WordPress cai, e a terceira é uma página de erro caso o Nginx da frente não responda.
As coisas do Varnish não são possíveis para o Discourse, mas não vejo nenhum motivo pelo qual não se poderia construir essa teia de segurança no mundo do Docker também, onde qualquer erro 50x exibiria uma página de erro.
Esse poderia ser um sistema muito propenso a erros, no entanto. E não faço a mínima ideia do que aconteceria se houvesse mais do que uma mão cheia de usuários.
Existe também a resposta mais óbvia, é claro: usar um Nginx antes do Discourse. Eu usei isso antes de migrar para a configuração de 2 containers.