Si realizas las actualizaciones desde la UX, eventualmente recibirás un mensaje que dice que tienes que hacer una actualización de línea de comandos. No depende de Debian, sino de la imagen base de Discourse.
2 Me gusta
Y con el método de 2 contenedores no habría ningún botón de actualización de la GUI, ¿correcto?
La actualización de la GUI proviene del plugin discourse_docker. Si tienes ese plugin, tienes la actualización de la GUI.
Cuando se descubren vulnerabilidades en herramientas de manipulación de imágenes, la excepción de código remoto definitivamente ha ocurrido en el pasado, lo que significa que estás a una carga de imagen de un sistema comprometido.
Clear Linux estableció el estándar de la velocidad de arranque en Linux. Es un trabajo increíble, lo respaldo totalmente.
1 me gusta
Oh, eso cambia un poco las cosas entonces. Por alguna razón, pensé que el actualizador de la GUI no funcionaría con una instalación no estándar de 2 contenedores. En ese caso, siempre que el administrador sea técnicamente competente, parece que no hay muchas desventajas en una instalación de 2 contenedores. Definitivamente quiero tener actualizaciones de la GUI, por ejemplo, si viajo solo con mi teléfono y sale una actualización de seguridad importante de Discourse, al menos puedo aplicarla sin acceso SSH.
1 me gusta
Esa es mi creencia. Básicamente, solo necesitas prestar suficiente atención para saber cuándo hay una actualización de Postgres o Redis que requiere reconstruir el contenedor de datos. También necesitas saber cómo ejecutar ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, pero eso no es tan difícil. Simplemente puedes ejecutar ./launcher rebuild web_only, pero eso interrumpe el sitio mientras se reconstruye.
2 Me gusta
Para ser completo: la compilación de la interfaz de usuario web normalmente no tiene tiempo de inactividad; el arranque/destrucción/inicio tiene un tiempo de inactividad mínimo y solo lo haría de forma normal con una página de mantenimiento proporcionada externamente, como con nginx externo, como se documenta aquí. Pero eso es una buena práctica de todos modos, aunque solo sea para introducir direcciones IPv6 en el contenedor.
Muy bien, gracias. Y con una instalación de 2 contenedores, ¿todavía recibes notificaciones del panel de control de Discourse cuando el contenedor necesita ser reconstruido? Y luego, en ese caso, ¿podría determinar si reconstruir solo la aplicación o también el contenedor de datos?
1 me gusta
Sí. Lo veo ahora mismo porque no he aplicado la actualización “solo ha cambiado la versión” 3.1.0.beta1. 
1 me gusta
Este es un caso de “está bien hasta que deja de estarlo”: la gente entra en pánico cuando la actualización falla en la interfaz de usuario y no saben que deben ejecutar git pull; ./launcher rebuild app para solucionar el problema. Esto sucede cada vez que hay un cambio que invalida la actualización de la GUI, creo. Volvió a suceder:
Siento que este pánico resalta el valor de tener un mecanismo de actualización consistente y normal que evite esta experiencia.
Al mismo tiempo, me encontré con el también infrecuente caso de que el bootstrap rompa el sistema en funcionamiento: las actualizaciones con tiempo de inactividad cero ocasionalmente fallan así, ¿una o dos veces al año tal vez en promedio? Así que no te demores entre el bootstrap y el destroy/start.
Debería actualizar el texto para dejar eso claro, así que lo haré a continuación.
Aún no he implementado LibreTranslate, pero estoy considerando hacerlo para que mi sitio sea más accesible internacionalmente.
Si lo implemento con éxito, tengo la intención de editar eso en la publicación principal. 
2 Me gusta