Actualmente, cuando realizamos cualquier tipo de mantenimiento (excepto simplemente actualizar) y queremos poner el sitio fuera de línea o establecerlo en modo solo lectura, no hay forma de mostrar a los visitantes un mensaje sobre lo que está sucediendo ni una estimación de cuánto tiempo estará el sistema inaccesible.
Sería ideal contar con un modo fuera de línea completo que permitiera a la administración proporcionar actualizaciones de estado y mensajes a los visitantes durante este tiempo de inactividad, para gestionar las expectativas y hacer que los visitantes se sientan cómodos con la situación en lugar de preguntarse qué podría estar ocurriendo.
Para el registro, aquí está el comentario original que dio lugar a esta división, según @jomaxro:
Lo que realmente se necesita aquí es un modo fuera de línea / de mantenimiento integrado que incorpore esta metodología y la capacidad de ofrecer mensajes personalizados a los usuarios mientras el sistema está en modo fuera de línea y/o mantenimiento.
Podría ser algo integrado en el administrador de actualizaciones (renombrar “administrador de actualizaciones” a “Administrador del Sistema Discourse” e incluir actualizaciones, registros, procesos y copias de seguridad todos juntos en esta área).
Esto haría que el sistema fuera menos frágil, más amigable y útil tanto para administradores como para usuarios.
Docker Manager, el plugin oficial que soportamos para las actualizaciones, no causa ningún tiempo de inactividad. No debería ser necesario realizar cambios en el plugin, ya que ya soporta actualizaciones sin interrupción. El problema que aborda este howto son las actualizaciones (reconstrucciones) realizadas desde la línea de comandos. Estas solo son necesarias de forma infrecuente, unas pocas veces al año, cuando necesitamos actualizar una dependencia subyacente, como la versión de Ruby o Postgres.
No es posible hacer que Docker Manager maneje este tipo de actualizaciones, ya que Docker Manager, al igual que todo Discourse, está inactivo durante una reconstrucción. Cualquier solución debe estar fuera de Discourse, como la solución del proxy Nginx que proporciona este tema.
Hmm, creo que hay otras opciones aquí que estarían más alineadas con la naturaleza de Discourse… En lugar de descartar este concepto, hablemos de formas de mejorar la experiencia general en este sentido, especialmente si un administrador necesita - por una razón u otra - bajar el sitio para mantenimiento.
Una idea que me viene a la mente: ¿por qué no incorporar la solución de proxy Nginx mencionada por el OP en la configuración de Docker, de modo que se vuelva más predecible, manejable y consistente tanto para usuarios/administradores de Discourse como para el soporte (personas como tú aquí en el foro), en lugar de lidiar con soluciones desacopladas como la opción presentada aquí?
No tengo la intención de descartar el concepto, solo estoy indicando que usar un plugin de Discourse para resolver esto no funcionará. Permíteme mover esta discusión a un tema dedicado de #característica para una discusión adecuada.
@mreach, por favor edita la publicación original para detallar qué estás buscando y cómo te gustaría que funcione. Siéntete libre de editar el título según sea necesario.
Si deseas tener interrupciones minimizadas durante ./launcher rebuild app, necesitarás una configuración de varios contenedores.
Esto ya está documentado. Es una configuración más compleja.
Para tener una página “offline” con launcher rebuild en modo de contenedor único, tendríamos que intercambiar el contenedor por un contenedor dedicado especial de “el sitio está offline”. Esto no es imposible, pero requeriría aproximadamente dos semanas de ingeniería para que funcione perfectamente. No creo que podamos financiar esto en este momento, dado lo poco frecuente que es reconstruir un contenedor y cómo ya tenemos una forma documentada de realizar reconstrucciones sin interrupciones.
La instalación de dos contenedores permite actualizaciones con tiempo de inactividad mínimo la mayor parte del tiempo. A veces, al construir el nuevo contenedor se realiza una migración que hace que el sitio en ejecución se bloquee. Hay una forma de evitarlo, pero es bastante complicada y esas actualizaciones ocurren con poca frecuencia.
También podrías redirigir tu DNS (o utilizar una IP elástica o lo que Digital Ocean llame equivalente) y crear una instancia (droplet) o lo que AWS llame equivalente, con un servidor web que incluya tu mensaje de estado.
Por cierto, @jomaxro, ¿cómo separaste mi publicación para crear este nuevo tema aquí? ¿Cuáles fueron los pasos que seguiste? Sería bastante útil y práctico saberlo… No veo ningún método para esto en Discourse estándar.