He propuesto una llamada arquitectura limpia para el nuevo servicio. Pero limpio no siempre significa simple.
¡Hola!
No estoy respondiendo a tu pregunta, solo tengo curiosidad. ¿Por qué crees que necesitas una página de mantenimiento? Parece bastante molesto de configurar para un beneficio mínimo.
Mis instancias están caídas 5 minutos al mes para las actualizaciones y eso es básicamente todo.
Cada vez que hacía cambios importantes, como instalar plugins, por ejemplo, a veces tardaba 20 minutos.
No es un gran problema, si consideramos que esto no se hace cada semana ni siquiera cada mes, pero para un visitante nuevo, esa página fea indicando que algo no funciona, no es una buena primera impresión. Incluso para los visitantes recurrentes que no saben que el sitio web estará fuera de servicio, eso puede meterlos en “modo pánico” pensando que toda la comunidad ha sido cerrada o algo así, quizás algunos de ellos me envíen un correo electrónico preguntándome qué está pasando.
Creo que es simplemente un buen detalle para el visitante, nuevo o antiguo, para que sepan qué está pasando.
Si este enfoque que sugirió Claude es algo que toma solo unos minutos, pero que no se toca de nuevo, creo que es un tiempo bien invertido.
Tardará segundos si te mudas a la instalación con dos contenedores.
Incluso puedes programar la transición durante la noche, si realmente quieres, mientras tú y/o tu público principal duermen.
No necesitas una página de mantenimiento.
Uso la construcción de contenedor dual detrás de Cloudflare CDN. El contenedor dual minimiza el tiempo de inactividad y mis dos foros principales de producción tienen un máximo de 30 segundos sin conexión durante las reconstrucciones. Me gusta tener una página de mantenimiento porque la página de error predeterminada del servidor web es fea y no da ninguna pista sobre cuánto tiempo estará fuera de línea.
Por ejemplo, para un sitio en your-domain.com, simplemente uso una ruta de Cloudflare Workers configurada en *yourdomain.com/* (incluye los asteriscos).
Paso 1: Crear la página de trabajador
Puedes configurar la página de mantenimiento en la página de configuración de workers & pages en Cloudflare: haz clic en el botón create application:
Luego usa la plantilla hello world:
Luego dale un nombre y haz clic en deploy:
Luego ve a la página de resumen para esa página de mantenimiento y haz clic en edit code:
Y pega este código en la ventana de código worker.js (sustituye tu dominio y el mensaje que quieras, edita el texto, el color del texto, el fondo, etc.):
export default {
async fetch(request, env, ctx) {
try {
// Fetch the original request from your server
const response = await fetch(request);
// If YOUR SITE is swapping containers, it throws a 502, 521, or 530
if (response.status === 502 || response.status === 521 || response.status === 530) {
return returnCustomErrorPage();
}
// If everything is fine, return the normal forum traffic
return response;
} catch (e) {
// If the server is completely unreachable
return returnCustomErrorPage();
}
}
};
function returnCustomErrorPage() {
const html = `
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>System Refresh - 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>Just a quick update window</h1>
<p><strong>YOUR-SITE</strong> is undergoing a brief 30-second system refresh.</p>
<p>Grab a quick sip of your drink—this page will automatically refresh as soon as we are back online.</p>
</div>
<script>
// Automatically check if the site is back up every 10 seconds
setInterval(function() {
window.location.reload();
}, 10000);
</script>
</body>
</html>
`;
return new Response(html, {
status: 503, // 503 is best for SEO so Google doesn't penalize you for downtime
headers: {
"Content-Type": "text/html;charset=UTF-8",
"Retry-After": "30"
}
});
}
Debería verse algo así. Haz clic en deploy para guardarlo:
Paso 2: Agregar la ruta
Ahora ve a la página de rutas de Cloudflare Workers y haz clic en el botón add route para abrir el modal de nueva ruta, completa la ruta del dominio y selecciona la página de trabajador que acabas de crear, luego haz clic en guardar:
Paso 3: Ejecutar actualizaciones o reconstrucciones
Ahora, cuando te conectes por SSH a tu servidor y ejecutes actualizaciones del sistema o hagas una reconstrucción, en lugar de una página de sitio caído o error, se mostrará esta página cuando ocurra el tiempo de inactividad (uso 30 segundos en la mía porque ese es el máximo para mis sitios)
Suelo agregar y eliminar mi ruta de página de trabajadores cada vez que hago mantenimiento, pero a algunos les gusta dejarla allí todo el tiempo (dejo el código real de la página, solo agrego y elimino la ruta).
Creo que eso es todo.
Opcional: Ejecutar actualizaciones con un script y programar
También uso un script de shell Unix en mi servidor para ejecutar la actualización específica del contenedor dual, que creé así:
cat << 'EOF' > /root/update-web.sh
#!/bin/bash
cd /var/discourse
echo "➡️ Pulling latest Discourse docker scripts..."
git pull
echo "➡️ Bootstrapping new web container in the background (takes ~8 mins)..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Bootstrap successful! Swapping containers..."
./launcher destroy web_only && ./launcher start web_only
echo "🚀 Done! Site updated with almost zero downtime."
else
echo "❌ Bootstrap failed! Aborting swap to keep current site online."
fi
EOF
chmod +x /root/update-web.sh
Luego lo ejecuto en el prompt de root en mi servidor con el comando ./update-web.sh.
edición: no sigas los pasos a menos que tengas una cuenta de Cloudflare de pago.
Puedes automatizarlo para una hora específica, como la 1:00 a. m. del domingo en tu hora local con una tarea cron. Para mí, 1:00 a. m. hora local es 8:00 a. m. UTC, (puedes averiguar la fecha UTC de tu servidor escribiendo date en el prompt de comandos cuando estés conectado por SSH).
Entonces:
Ejecuta este comando para abrir el programador de tareas de tu servidor:
crontab -e
(si te pide que elijas un editor, selecciona tu editor preferido, 1 para nano es probablemente lo más fácil)
Me desplazo hasta el final de los comentarios y pego esto:
0 8 * * 0 /root/update-web.sh >> /var/log/discourse-update.log 2>&1
(que significa ejecutar el archivo /root/update-web.sh a los minutos 0, hora 8 (UTC), cada domingo por la mañana)
Luego guarda y sale (si estás usando nano):
Ctrl + Opara guardar.Enterpara confirmar.Ctrl + Xpara salir.
Luego puedo ejecutar cat /var/log/discourse-update.log cuando me despierto los domingos por la mañana para verificar si se ejecutó correctamente. Si usas un programador de tareas cron, querrás dejar la ruta de la página de trabajadores.
Creo que eso es todo. Avísame si tienes preguntas jajaja. Es mucho más simple de lo que parece jajaja. 
¡Guau! ¡Realmente aprecio esa explicación detallada! 
Acabo de guardar tu respuesta en mis notas para que, cuando instale Discourse de nuevo pronto, pueda volver a consultarla. Sin duda te haré saber cómo me fue, incluso si tarda un poco en instalarlo. En este momento estoy terminando algunas cosas de programación y solo después me centraré en Discourse nuevamente.
Y estoy de acuerdo en que la página “web serve is down” es fea, y para los usuarios inexpertos, ese mensaje no significa mucho. Tener una página de mantenimiento simple con un mensaje personalizado siempre es preferible, incluso si implica algún trabajo de configuración.
Nuevamente, gracias muchísimo por tomarte el tiempo de compartir esto. Espero que otras personas encuentren esto útil 
y ahí está el problema.
No es un cambio sencillo y conlleva infraestructura adicional que hay que vigilar y mantener, y, en mi opinión, no merece la pena para unos segundos de tiempo de inactividad.
Entiendo a lo que te refieres, pero ese es solo un caso. ¿Qué pasa si algo se rompe de verdad y necesito arreglarlo, tardando más de unos pocos segundos?
Además, ¿cómo es que tú tienes unos pocos segundos de tiempo de inactividad y yo estaba viendo como 20 minutos, después de instalar plugins?
Porque en la configuración de dos contenedores (enlazada en ambos nuestros mensajes y una dependencia innegociable) iniciáis la nueva compilación mediante ./launcher bootstrap web_only (durante el cual vuestro sitio sigue funcionando al 100 %), y luego simplemente destruís y arrancáis inmediatamente el nuevo contenedor ya compilado (lo cual tarda unos segundos).
Ah, vale, eso sigue siendo para la configuración de 2 contenedores. Pensé que decías que no valía la pena el trabajo de construir la configuración de 2 contenedores por completo. Lo que dices que no vale la pena es solo el trabajo extra de la página de mantenimiento, ¿verdad?
Personalmente, sí.
Si quieres contar con cinturón y paracaídas para los usuarios web que accedan durante los 30-60 segundos con una navegación nueva, entonces una página de mantenimiento es razonable.
Tienes que sopesar el beneficio de eso frente al tiempo necesario para mantener la infraestructura asociada.
Ahora lo entiendo. Gracias.
Así que ahora pregunto: con 2 contenedores, esos 20 minutos aproximadamente siguen siendo un problema, la única diferencia es que puedo dejar que lo haga en uno de los contenedores, el que no está en vivo, y cuando esté listo, hacer el cambio. ¿Es así como funciona?
Sí, sigue tardando un poco en construir el contenedor. Por cierto, debes asegurarte de que tu servidor sea lo suficientemente potente para permitir que este proceso se ejecute en paralelo mientras atiendes a tu comunidad con normalidad (esencialmente, lo más importante al principio es garantizar suficiente memoria RAM, por lo que es muy importante asegurarte de tener suficiente espacio de SWAP). La construcción también ocupará al menos un núcleo, así que considera tener un servidor con 1 o 2 núcleos adicionales.
y parece ser un servidor menos eficiente…?Recomendaría al menos 4 GB y 3 núcleos (“vcpu”) para este tipo de configuración …
Como referencia, ya que se preguntó en otro tema, la (edición: incorrecta) respuesta: Any cheaper alternatives to Hetzner? - #2 by Canapin
Este es el único que coincide con eso… qué diferencia de precio…
Supongo que tendré que construirlo con un contenedor por ahora y, cuando llegue el momento (
), actualizarlo.
¡Gracias por la información, Robert!
No estoy de acuerdo y creo que sí vale la pena la página de mantenimiento. Por mi experiencia, cuando la gente ve la página de error de Discourse, lo primero que hace es pulsar «Actualizar» y entonces verá la breve página de mantenimiento, que recargará automáticamente el sitio cuando se complete el cambio de contenedor. No es mucho trabajo configurarlo y solo tienes que hacerlo una vez. Durante una reconstrucción con la configuración de doble contenedor, la parte de arranque ocurre en segundo plano y los usuarios pueden seguir usando el sitio; es el cambio de contenedor lo que causa la breve interrupción (a diferencia de una configuración estándar de un solo contenedor).
El coste y la selección del servidor es algo completamente distinto y debería estar en otro tema separado.
Supongo que ahora mismo estoy en el punto medio. Entiendo lo que quieres decir, así como lo que dice @merefield. Es un buen detalle tenerlo, y si solo se configura una vez, supongo que no es gran cosa, ¿verdad?
Al mismo tiempo, si realmente tarda hasta 60 segundos en el peor de los casos, no todo el mundo visitará la web exactamente en el segundo 0 y tendrá que esperar 60 segundos. Algunas personas verán la página fea durante 5 segundos, otras 20, otras 60. Algunas ni siquiera la verán (¿me equivoco?), por ejemplo, si solo están leyendo una respuesta o escribiendo una, ese cambio podría producirse antes de que pulsen ENVIAR o antes de que dejen de leer el tema y pulsen RESPONDER (o visiten otra página).
Mi problema con la ruta de nginx estaba más relacionado con lo de los 20 minutos en una configuración de un solo contenedor. Con la opción de tener 2 y pasar de 20 minutos a como máximo 60 segundos, me pregunto si realmente es relevante. Sobre todo, si puedo añadir un anuncio en la parte superior indicando que el servicio se interrumpirá durante unos segundos en un horario de poco tráfico, esto no será un gran problema, ¿verdad?
Tengo que sentarme a pensarlo. La configuración de 2 contenedores será algo que definitivamente implementaré, si encuentro una buena oferta de servidor.
¿Podrías aclarar esto de una manera que alguien básico como yo pueda entender? Todavía no estoy familiarizado con los trabajadores…
¿Por qué añades y eliminas la ruta de la página de trabajadores, si dejarla no es un problema? Entonces, si añado la página de mantenimiento, ¿realmente puedo configurarla una vez y, a partir de ese momento, siempre me conecto a mi servidor vía SSH desde la Terminal y hago todo allí como lo hago con un contenedor único, sin tener que ir nunca a Cloudflare?
@merefield mencionó que esto (página de mantenimiento, trabajadores, etc.) también es algo que necesita mantenimiento, así que me pregunto si realmente es algo que configuras y olvidas, o si hay algo que necesite hacerse de vez en cuando?