Hola chicos.
¿Es posible, incluso si no está cubierto/admitido oficialmente, ajustar Discourse/contenedor para que se inicie/arranque más rápido? (fuera de ajustar los recursos del host | y el propio contenedor)
Puedes intentar usar varios archivos de contenedor en lugar de un único archivo app.yml independiente.
Pero seamos sinceros, casi nadie necesita reconstruir contenedores con frecuencia, ¿verdad?
Si necesitas instalar complementos, no es necesario reconstruir el contenedor. Tengo formas no oficiales de instalar complementos sin reconstruir.
¿Realmente te refieres a que arranque más rápido, es decir, que empiece a servir páginas antes después de reiniciar el contenedor? No. Simplemente lleva un tiempo poner en marcha Rails y todo lo demás.
Si te refieres al tiempo de inactividad asociado a la reconstrucción de un contenedor, entonces la solución de dos contenedores es lo que buscas.
Y si eso no es lo suficientemente rápido y quieres cero tiempo de inactividad, entonces puedes hacer cosas con un balanceador de carga y arrancar el nuevo contenedor mientras el antiguo sigue sirviendo páginas y luego apagar el antiguo una vez que el nuevo esté listo.
No (necesariamente) me refiero a reconstruir.
Digamos que uno administra, como preferiría, todo con docker
Incluso un reinicio de docker del contenedor parece hacer que Discourse haga una larga lista de cosas al arrancar — sí, eso era lo que quería decir — ¿se puede ajustar/recortar esto, cosas de Ruby/Rails? (¿Por qué se hace todo eso en cada inicio? ¿No puede persistir eso?)
Solución de dos contenedores — ¿qué es eso?
¿Son dos contenedores con las partes relevantes sin colisionar y en el mismo host hablando (ambos contenedores) con el mismo pgSQL y Redis externos?
¿O es una configuración sin tiempo de inactividad?
Tiene que leer un montón de código para estar listo para servirlo. ¿Alguna vez has arrancado tu teléfono, una computadora o un televisor moderno? Lleva algo de tiempo. Es exactamente así. El contenedor tiene todo un sistema operativo dentro.
Sí. Está separando los raíles+nginx en su propio contenedor y teniendo postgres y redis en otro contenedor (o como quieras proporcionar redis y postgres).