Mejoras de producción: procedimiento correcto a seguir

Hola,

Estoy a punto de actualizar nuestro servidor de Discourse en producción (nos autoalojamos en EC2 siguiendo las instrucciones oficiales de instalación) y quería confirmar el enfoque recomendado.

No tenemos habilitado el botón de actualización en la interfaz de usuario, por lo que se realizará en la instancia de EC2. Ahora, creo que hay 2 formas principales de hacerlo:

  • Reconstruir nuestro servidor EC2, lo que descargará una copia fresca del repositorio GitHub de discourse_docker y utilizará las plantillas allí, es decir, web.template.yml actualmente hace referencia a la imagen base discourse/base:2.0.20260209-1300. Este enfoque eliminaría el servidor actual en ejecución e iniciaría el nuevo.
  • Iniciar sesión en el servidor EC2 existente y ejecutar los siguientes comandos para reconstruir la imagen actual y reiniciar el contenedor:
    • ./launcher rebuild app

Tengo 2 preguntas:

  1. ¿Qué enfoque debería usarse para el mantenimiento normal?
  2. Si ejecutamos el comando rebuild app, ¿aún se descarga la rama main del repositorio discourse_docker?

He leído el sitio https://releases.discourse.org y puedo ver que la versión 2026.3.0 aún no se ha lanzado. Mi entendimiento es que no deberíamos usar las versiones más recientes de main de una versión en producción, ya que aún están en desarrollo activo.

Agradezco mucho cualquier ayuda. Gracias.

Si deseas actualizar a la última versión, simplemente realiza la actualización manualmente desde el panel de administración.
Si deseas actualizar a la versión esr, solo necesitas especificar esr al final del archivo containers/app.yml.

params:
  version: esr

Luego, reconstruye la aplicación.

Asegúrate de que la red funcione correctamente.

1 me gusta

Gracias por la respuesta.

Entonces, al establecer la versión como esr, ¿eso anula la imagen base utilizada en las plantillas?

No queremos que la actualización esté habilitada en la interfaz de administración, por lo que necesitaremos una forma de hacerlo en la instancia o simplemente reconstruyendo la instancia y dejando que nuestro AutoEscalador la gestione.

Si usamos esr, ¿cómo se actualiza cuando se lanza una corrección crítica? ¿De nuevo, simplemente reconstruimos a través del lanzador/nueva instancia EC2 de forma mensual para incorporar cualquier actualización de la versión esr?

¿Has leído Understanding Discourse release channels y Configure a supported tracking branch to get Discourse software updates? Yo describiría la diferencia más bien como tener acceso a los últimos cambios de inmediato o recibirlos un poco más tarde. Lo segundo puede ser muy útil para desarrollos personalizados que necesitan ser adaptados primero. De lo contrario, preferiría tener acceso a las últimas características y correcciones. Por supuesto, esto conlleva el riesgo de nuevos errores, pero la versión que se congeló hace tres semanas también contiene errores que quizás ya se hayan corregido en la versión más reciente, aunque generalmente no son lo suficientemente graves como para justificar su retroportación a la última release.

También ten en cuenta que la downgrade no está soportada, por lo que si estás en una versión posterior a la ESR actual, debes esperar a que se publique la próxima ESR.

1 me gusta

Si actualmente estás en una versión significativamente antigua, podrías beneficiarte de ejecutar un git pull antes del comando del lanzador.

¡Ah, me perdí la publicación Configure a supported tracking branch to get Discourse software updates!

Por las respuestas hasta ahora, creo que usaré la rama release, ya que realizamos una actualización mensual.

Muchas gracias por esto.

1 me gusta