Me gustaría abrir una discusión sobre las mejores prácticas para realizar tareas de mantenimiento esenciales en una instancia de Discourse minimizando o eliminando el tiempo de inactividad.
Tareas como cambiar la configuración de recursos críticos (por ejemplo, UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) o aplicar actualizaciones importantes suelen requerir un launcher rebuild app, que puede llevar una cantidad de tiempo considerable, a veces 30 minutos o más.
Mi pregunta es: ¿Cuáles son las estrategias recomendadas para que los administradores del sistema realicen estas actualizaciones esenciales y cambios de configuración con la menor cantidad de tiempo de inactividad para el usuario?
¿Existen técnicas avanzadas, como implementaciones “blue/green” u otras estrategias de implementación sin tiempo de inactividad, que sean compatibles o recomendadas para Discourse? ¿O es el proceso estándar de rebuild el único método compatible, y el enfoque debe centrarse en optimizar el tiempo de reconstrucción en sí?
Estoy interesado en escuchar a cualquiera que tenga experiencia en la gestión de instancias grandes o de alto tráfico y cómo es su flujo de trabajo para el mantenimiento.
Si tiene una instalación de dos contenedores, el nuevo contenedor se compila mientras el antiguo se ejecuta. El tiempo de inactividad es solo la cantidad de tiempo que se tarda en iniciar el nuevo contenedor. El único problema es que necesita suficiente RAM para compilar un contenedor mientras el otro se ejecuta.
Si desea tiempo de inactividad cero, necesita un balanceador de carga que mantenga el contenedor antiguo en ejecución hasta que el nuevo se haya iniciado por completo. Luego, apaga el contenedor antiguo y realiza las migraciones posteriores a la actualización.
Discourse es tan estable que esto es bastante innecesario para la mayoría de las instalaciones (¡pero supongo que podrías considerarlo para requisitos de alta disponibilidad muy altos o si estás alojando a otros!)
No creo haber tenido una sola interrupción en 7 años debido a un “fallo” de producción…
Los momentos más arriesgados en la vida de un Discourse son siempre en la reconstrucción.
La configuración de dos contenedores te da la capacidad de iniciar una nueva compilación antes de comprometerte con ella, aunque eso no detectará algunos errores en tiempo de ejecución, por supuesto.
El problema es que si tus migraciones se han ejecutado, es posible que necesites comprometerte con la nueva compilación y, por lo tanto, normalmente intentarías rastrear y corregir la fuente de esos errores en lugar de revertir.