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.
Por fin me tomé el tiempo para volver a instalar Discourse. Después de evaluar dónde estoy ahora y cuánto mantenimiento parecen requerir dos contenedores, creo que por ahora me quedaré con uno. Si en el futuro necesito dos contenedores, revisaré todo lo que se dice aquí. Aparte de instalar plugins, lo cual no parece ser algo que tenga que hacer tan a menudo como gestionar componentes, que la comunidad esté caída durante 20 minutos en un momento del día en el que hay menos personas en línea, junto con un banner que avise a la gente de que la comunidad estará caída un día y a una hora determinadas, parece bastante razonable por ahora.
A ver cómo va.
Requiere tanto como un contenedor solo 
Y menos sufrimiento 
¿Puedes aclararme cómo funciona?
No estoy seguro de si me estabas respondiendo a mí o a @Jagster. ¿A qué te refieres?
Porque el proceso de inicialización del nuevo contenedor mientras tu sitio sigue en línea es mucho menos estresante: si la compilación falla, no tienes que entrar en pánico y cuentas con todo el tiempo necesario para solucionarlo sin dejar de estar en línea.
Vale, así que estás recomendando tener ambos, de ahí lo de “menos dolores de cabeza”.
Entonces, como alguien sin mucha experiencia en esto, tener 2 contenedores no significa dos instancias de Discourse, ¿verdad?
Estoy leyendo el tema
y
para ver si puedo entender cuánto trabajo requiere y qué atención neceso prestar, para no acabar con algo que no pueda gestionar y hacer que el proceso sea más problemático que todos los demás problemas que pueden surgir con solo uno.
Solo quiero alabar la información compartida sobre la configuración de dos contenedores. Yo usaba uno y normalmente tardaba entre 3 y 5 minutos (en un servidor dedicado con 64 GB de RAM).
¿Podrías explicarme, con ejemplos claros y simples, cuándo se deben actualizar ambos contenedores en una instalación dual? Me refiero a qué actualizaciones de Discourse requieren reiniciar ambos y cuáles solo requieren reiniciar el web_container recién creado.
Primero sigues instrucciones muy simples sobre cómo iniciar el sistema de 2 contenedores. Después, en la mayoría de los casos, solo necesitas:
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only ) 2>&1 | tee ~/$(date +%Y-%m-%d_%H-%M-%S)-upgrade.log'
La parte de tee es solo para el registro, porque resulta más fácil (para mí) revisarlo que la salida de tmux que estoy usando.
Pero, básicamente, es exactamente lo mismo que usar app.yml y reconstruir, excepto que molesta mucho menos a los usuarios. Por supuesto, hay un contenedor de datos, pero solo necesita atención y cuidados muy rara vez; y si vas a hacer trucos más sofisticados con el contenedor, probablemente sepas qué hacer y cuándo con los contenedores también.
Si la actualización falla con 2 contenedores, aún tienes un foro activo y funcionando, mientras que con uno solo se bloquearía.
Así que solo el inicio inicial es un poco más exigente, pero las instrucciones son bastante claras. Diría que usar mail-reveiver es una tarea más difícil, si se utiliza Amazon SES.
Por ejemplo, este es el tipo de comentario que no puedo simplemente ignorar, ya que parece que actualizar/actualizar (upgrade) deja de ser tan simple como hacer clic en un botón, y se convierte en algo que requiere más concentración y atención, lo cual para una persona experimentada puede parecer fácil y obvio, pero quizás no para alguien que no lo es:
¿Dirías que las instrucciones de este tema siguen siendo válidas en 2026, dado que ese post es de 2015?
No me importa intentarlo, ya que acabo de instalar Discourse hoy de nuevo. Si algo sale mal, siempre puedo volver a un solo contenedor. Solo quiero asegurarme de que a mitad del proceso no haga algo que ya no sea correcto en 2026…
Ahorrar unos minutos para mí significa más de 20 minutos. Es cierto que ocurre una vez al mes si se actualiza una vez al mes, pero yo actualizo al menos dos veces por semana. Y si algún plugin falla y hay que intentarlo varias veces (porque, por supuesto, estamos trabajando con instancias en vivo 
), ese tiempo de inactividad prolongado es simplemente doloroso.
No hay detalles en los anuncios de cada nueva versión que seguir. Mcdanlj puede tenerlos, pero él no es un administrador de sistemas común, sino que trabaja en un nivel mucho más alto.
Estoy confundido…
Mientras dices:
tu respuesta anterior a esta da la impresión de que hay más trabajo, cuando dices:
Eso por sí solo hace que suene como si mantener dos contenedores fuera más complejo, no igual que uno. Claro, entiendo lo de los tiempos de inactividad y todo eso, pero el mantenimiento de los propios contenedores parece más complejo y propenso a errores que una simple actualización con un solo contenedor. ¿O me estoy perdiendo algo?
Eso es correcto:
Contenedor 1 = sitio web y nginx
Contenedor 2 = base de datos y redis
(Creo que lo tengo bien)
Lo del Contenedor 1 cambia mucho
Lo del Contenedor 2, muy rara vez.
Y puedes actualizar el contenedor 1 sin actualizar el contenedor 2.
Y mejor aún, puedes preparar un reemplazo para el contenedor 1 y luego cambiarlo en unos pocos segundos (la preparación se llama “bootstrapping”).
Te falta ver que, con un solo contenedor, al ejecutar ./launcher rebuild app, tanto la parte web como la de datos se detienen y ambas se actualizan. Sin embargo, la parte de datos apenas necesita actualizaciones, y después de la tarea todo se vuelve a iniciar si no hay ningún problema.
Con dos contenedores, solo se reconstruye el contenedor “web”, no el de datos. Si todo va bien, se elimina el contenedor antiguo y se inicia el nuevo. Si algo sale mal, tu contenedor “web” antiguo y funcional sigue en uso.
Así que, la única diferencia real es cómo se gestiona el software y un par de cosas más de la base de datos.
Claro, la configuración de 1 contenedor también es una opción, por supuesto. Pero el punto principal es que, cuando se crea la de 2 contenedores, la única diferencia real en el nombre de dificultad es el comando utilizado al actualizar — y para eso está alias
Eso se escribía en los viejos tiempos de los anuncios manuscritos, que decían algo sobre que era hora de actualizar la base de datos ahora. El nuevo sitio automatizado es más llamativo, pero no hay una nota humana sobre lo que realmente es más importante, como solía haber.
Hoy en día, supongo que hay que notar un post de que la base de datos está recibiendo una actualización. Parece que me he perdido esos durante meses.
Sin embargo, esto sucede una vez cada pocos años, y se reconstruye cuando se reconstruye explícitamente la BD, y CDCK parece haber preservado la compatibilidad con versiones anteriores de pgsql durante un tiempo. Así que nunca realmente me ha afectado. Hasta ahora.
Me gusta mucho la configuración de dos contenedores (¡o más!) para mí mismo, pero todavía la matizo porque no es la más fácil para todos. Me resulta difícil juzgar para quién la implementación de dos contenedores se sentirá como “por supuesto, eso es simple” y para quién será “ay, solo quiero presionar un botón”.