Sí, lo haría en etapas:
si en este punto estás satisfecho, detente aquí, o:
jaja me alegra que lo preguntes porque no me tomé el tiempo de explicar esta parte (debería haberlo hecho, ¡hay mucho que explicar y Cloudflare es complejo!).
Cuando se configura la ruta de workers, cada carga de imagen y visualización de página en el foro se enruta a través de ese worker.
El plan gratuito de CDN de Cloudflare incluye un límite de 100.000 solicitudes/día en una ruta de worker.
Por lo tanto, si tienes un foro relativamente activo, para evitar alcanzar el límite de tu nivel gratuito en un día, es una buena idea no tenerlo activado todo el tiempo. Esto se refiere solo a la ruta del worker, no a la página de mantenimiento; puedes dejar la página de mantenimiento activada todo el tiempo, ya que no se activa a menos que tengas la ruta del worker asignada. Esto se refiere solo a la parte del paso 2 donde asignaste la ruta (que es fácil de configurar y eliminar). A menos que uses un plan de pago de Cloudflare, es una buena práctica tenerlo activado solo cuando estás realizando tu propio mantenimiento.
remove para desvincular la página de worker de la ruta.Si tienes un plan de pago de Cloudflare, no tienes nada de qué preocuparte. Sin embargo, en ese caso, puedes usar las páginas de error de Cloudflare en lugar de una página de workers… (¿mencioné que Cloudflare es bastante complejo? jajaja).
configuración avanzada de administrador a continuaciónSi alguien desea automatizar completamente sus actualizaciones en el plan gratuito, debería usar un token de API de Cloudflare, su zone-id y un comando curl para obtener el route id de los workers. Luego, edita el script /root/update-web.sh con algunas cosas más divertidas para activar y desactivar la ruta del worker automáticamente:
#!/bin/bash
cd /var/discourse
CF_TOKEN="tu_token_real_aquí" #<---token de API de Cloudflare
ZONE_ID="xxxx" #<---de tu página de perfil de Cloudflare
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"
echo "➡️ Descargando los últimos scripts de Docker de Discourse..."
git pull
echo "➡️ Preparando nuevo contenedor web en segundo plano..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ ¡Bootstrap exitoso!"
# Activar el Worker de Mantenimiento de Cloudflare
echo "🚧 Habilitando página de mantenimiento..."
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
# Intercambiar los contenedores (Ventana de tiempo de inactividad de 30 segundos)
echo "🔄 Intercambiando contenedores..."
./launcher destroy web_only && ./launcher start web_only
# Desactivar el Worker de Mantenimiento de Cloudflare
echo "🌍 Deshabilitando página de mantenimiento..."
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 "🚀 ¡Hecho! Sitio actualizado con cero tiempo de inactividad visible."
else
echo "❌ ¡Bootstrap fallido! Abortando intercambio para mantener el sitio actual en línea."
fi
Uso la versión anterior del script porque no me importa automatizar todo y me gusta estar presente para hacer actualizaciones/reconstrucciones. Simplemente añado la ruta de workers justo antes de hacer una actualización y luego la elimino después. Solo toma unos segundos.
Mis pasos generales son:
sudo apt update && sudo apt upgrade -y, luego reiniciar el servidor si es necesario)./update-web.shNo tengo ni idea de programación ni del mundo del desarrollo, más allá de haber hecho una cosa de hello world con Visual Basic hace mucho, mucho tiempo. Pero puedo hacer algunas cosas, porque sé mejor cómo administrar mis servidores de WordPress y Mastodon/Pixelfed, y de alguna manera también mi Discourse. Además, por ahí hay algo llamado IA (que no es tan fácil para un principiante como se anuncia).
No sé si esto es siquiera remotamente posible con Discourse debido a Docker, pero en el mundo ordinario de Nginx-Varnish-WordPress, construí un sistema donde un servidor Plesk recibe información de errores 50x y muestra una página de error. De hecho, tengo tres configuraciones: el frontend de Nginx muestra contenido de instantáneas generadas si Varnish está caído, Varnish comienza a usar la instantánea para contenido no en caché cuando el backend relacionado con WordPress está caído, y la tercera es una página de error si el frontend de Nginx no responde.
Las cosas de Varnish no son posibles para Discourse, pero no veo ninguna razón por la que no se pueda construir una especie de telaraña en el mundo de Docker también, donde cualquier error 50x mostrara una página de error.
Ese podría ser un sistema muy propenso a errores. Y no tengo la más mínima idea de qué pasaría si hubiera más de un puñado de usuarios.
También está la respuesta más obvia, por supuesto: usar Nginx antes de Discourse. Usé eso antes de pasar a la configuración de 2 contenedores.