Esa fue una nota sobre por qué la muestra de composición que publiqué no usaba la imagen PG genérica.
Hmm… ¿pero no dirías que esto hace que otras formas sean más complejas?
¡Entendido! 
Como gurú de Docker, ¿no debería ser todo esto muy fácil para ti?
3 Me gusta
Como estoy tratando de explicar desde hace un par de días, con la solución actual proporcionada, hace que todo sea menos fácil ;-).
En resumen;
Una imagen simple de Discourse (similar a la de Bitnami) con un montón de variables de entorno para configurar cosas básicas (como el acceso a Redis, la base de datos) sería más que suficiente, pero por alguna razón esto es completamente inviable… 
Comparto aquí pruebas de concepto para hacer exactamente eso.
Para un plugin simple, seguro, pero no podemos asumir que un plugin tendrá un aspecto determinado: algunos plugins necesitan configuración adicional, gemas extra para instalar, o dependencias de gemas adicionales o programas externos que requieren un apt-get install. Eso debería integrarse en una imagen personalizada.
Sería genial ver esto hecho, pero no es trivial.
re: Actualización web, tampoco se espera que los operadores de Discourse conozcan la CLI o docker.
1 me gusta
Solo necesitas construir tu propia imagen con el lanzador (lo cual puedes hacer con las acciones de GitHub), enviarla a un repositorio e iniciarlo con las variables de entorno. Aún necesitas migrar la base de datos, precompilar los activos y enviarlos a S3. Puedes migrar la base de datos y skip_post_deployment_migrations para que el contenedor antiguo pueda seguir funcionando hasta que el nuevo esté en marcha, y luego apagarlo y ejecutar el resto de las migraciones. Pero eso es demasiado complicado para alguien que no sabe mucho más sobre Discourse de lo que creo que quieres saber. Y hay muchas, muchas cosas que pueden salir mal, por eso la solución actual, que es horrible por todas las razones que describes, es la mejor solución para miles de personas que no saben qué es bash.
En la mayoría de los casos, solo necesitas ejecutar ./launcher rebuild app, excepto una vez cada par de años cuando necesitas actualizar la base de datos, así que tienes que hacerlo dos veces. Simplemente no puedes obtener ese nivel de simplicidad con docker-compose. Existe la posibilidad de que si docker-compose fuera utilizable cuando empezaron, podrían tenerlo en lugar de tener que crear el suyo propio, pero las cosas no salieron así.
Si quieres usar la imagen de Bitnami, puedes hacerlo, pero no obtendrás mucha ayuda aquí. Apuesto a que también funciona para mucha gente.
1 me gusta
hmm… para un lenguaje/entorno que se supone que es universal e independiente de la plataforma, depender del gestor de paquetes del sistema operativo subyacente parece bastante extraño… 
Esto es a lo que me refería anteriormente, que Discourse parece estar firmemente anclado en la “vieja” forma de gestionar software/foros de PHP
Entonces, para resumir toda la discusión (y posiblemente poner eso en el primer mensaje para evitar repasarlo hasta la saciedad ):
- Discourse está adaptado y enfocado en “gente normal” y toda la configuración está orientada a satisfacer sus necesidades
- Dado lo raro que es Ruby (entorno) y (1) es prácticamente imposible proporcionar imágenes de docker oficiales lo suficientemente genéricas en el repositorio oficial de Discourse
¿correcto?
Lo diría un poco diferente
Dado que no hay una oferta oficial de imágenes (por defecto) de otra manera de configurar Discourse que no sea el lanzador, lo que hace que el lanzador sea la forma predeterminada y básicamente única (recomendada) de configurar Discourse, se podría argumentar que la declaración original sigue siendo válida 
Pero esas son solo semánticas.
En cualquier caso, el tema es:
¿Puede Discourse distribuir imágenes Docker frecuentes que no necesiten ser inicializadas?
De toda la discusión parece que: “No, Discourse no puede/no quiere distribuir imágenes Docker frecuentes que no necesiten ser inicializadas”, q.e.d.
Por lo tanto, la sugerencia de agregar un comentario justo en la parte superior, de que tal imagen no se proporcionará, ¡ahorraría MUCHOS problemas!
Esta es una suposición incorrecta
Aún no hemos priorizado el envío de una imagen oficial con un paquete de plugins específicos
Es un trabajo que estamos considerando, tenemos muchas ideas sobre cómo hacerlo, simplemente no ha sido una prioridad para la empresa
5 Me gusta
traducción de una persona que trabaja en otro proyecto: “puede que suceda en el futuro, pero puede que no… dado que no es una prioridad / no está en una hoja de ruta, las posibilidades de que suceda son mínimas o nulas”
Aunque, en un tono más serio, ¡una configuración tan básica con un conjunto sensato de complementos sería genial!
¡Gracias por tu aporte! <3
Para tu información, he configurado una forma para que yo mismo cree una imagen de Discourse en una caja de desarrollo y la implemente en un servidor de una manera que elimina el requisito de usar el script del lanzador.
Más discusión sobre eso aquí en una solicitud de extracción que creé.
Lo configuré de una manera que lo hace totalmente compatible con la configuración oficial de Docker de Discourse, por lo que no tienes que preocuparte de que esta solución quede sin soporte o se rompa.
El resumen de cómo funciona es que hice que la imagen de Docker fuera responsable de ejecutar los comandos de arranque al iniciar (en lugar del script launcher).
1 me gusta
Enfoque genial.
También: interesante launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI)!
2 Me gusta