Oh man that’s tragic. So sorry to hear 
7 Me gusta
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam y este tema dejan claro que esto nunca se resolverá, aunque bitnami acaba de hacerlo…
Al menos obtuvimos una respuesta a nuestra pregunta, que es no.
¿Qué hay de evitar usar root en primer lugar? Usar fakeroot muestra que el principal obstáculo son las rutas codificadas (como /var). De lo contrario, excepto por los diversos errores y problemas que tiene la configuración actual, podría funcionar.
Es una lástima ver un software tan bueno con un procedimiento de configuración obligatorio tan mal diseñado, basado en una mala comprensión de la contenerización. Está claro para mí que se ha hecho con las mejores intenciones; aún así, el resultado es algo que no se puede implementar en ningún lugar fuera de un entorno de aficionado.
1 me gusta
Nuestra imagen se ejecuta como usuario de discourse, y creo que la oficial también.
De todos modos, es genial que el mundo “corporativo” esté interesado, porque tiene mucho más tiempo/dinero que el del aficionado 
¡Estoy seguro de que la comunidad apreciará tu contribución para mejorar el ecosistema!
1 me gusta
Esto ciertamente no es correcto, implementamos nuestra imagen usando nomad en flotas de máquinas, hay más de 10000 contenedores de discourse ejecutándose en aws y metal en este preciso instante.
3 Me gusta
Las herramientas requieren acceso root para ejecutarse y necesitan tener acceso a /var del host.
A menudo colaboro con comunidades y empresas de código abierto para mejorar su configuración de contenedores. Estaría encantado de ayudar y/o considerar la financiación para tener una configuración contenerizada más razonable.
No es obligatorio. Es solo que si necesitas ayuda para configurarlo, esa es la forma de hacerlo. He ayudado a clientes que usan gke, eks, ecs, por ejemplo. Puedes contactarme si necesitas ayuda con tus requisitos particulares.
/var no está codificado; trabajé recientemente con alguien que lo tenía en /var/www/discourse (lo que parecía una muy mala idea, ya que corre el riesgo de servir datos secretos a la web, pero era una “política”).
No está mal diseñado, está mal diseñado si tuvieras que diseñarlo hoy en lugar de hace una década. Fue un buen diseño en ese entonces, y todavía funciona para administrar su infraestructura e incluso para muchas personas que no saben nada de administración de sistemas.
2 Me gusta
Supongo que no te basas en las herramientas oficiales como discourse-setup, que requiere ser root para ejecutarse y probablemente está pensada para una configuración local.
Echa un vistazo al código fuente de discourse-setup. Si estás familiarizado con la configuración y la optimización del rendimiento de Discourse, no es obligatorio.
Launcher hace todo el trabajo pesado para construir la imagen a partir del archivo yml resultante.
2 Me gusta
Todo se puede hacer, pero me parece un esfuerzo innecesario.
- Usa
fakerootantes de cada comando /varse puede cambiar editando el archivo yaml:sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml--skip-connection-test(encontrado al mirar el código, porque el script no puede verificar la conexión si hay un proxy inverso)- Veo algo relacionado con certbot que ya sé que tendré que averiguar cómo deshabilitar ya que la descarga SSL generalmente se realiza externamente
- Los puertos de
containers/app.ymlse pueden cambiar para que se usen puertos>= 1024, pero no parece ser suficiente:Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
No quiero ser desagradable, pero tener múltiples servicios ejecutándose en un solo contenedor siempre ha sido un mal diseño, ya que significa tener poca o ninguna forma de saber lo que está sucediendo con los servicios individuales, tener que configurar un mecanismo personalizado de análisis de registros fuera de Docker, sin healthchecks útiles, no poder depender fácilmente de una base de datos externa, etc. Se puede hacer si es el único servicio que ejecuta en su negocio, pero si cada otro servicio comienza a hacerlo, la mayoría de los beneficios de usar contenedores simplemente desaparecen.
Estaría feliz de enviar algunas PR y documentación para que Discourse funcione en un entorno compatible con Docker sin acceso root, pero desacoplar los servicios y tener una configuración estándar sería una tarea grande sin garantía de que se incorpore al código principal.
Si no está de acuerdo con aspectos fundamentales de cómo está construido Discourse, ¿ha considerado usar un producto diferente?
3 Me gusta
Ok, lo entiendo mejor.
Discourse tiene una opinión firme sobre las herramientas para autoalojarse. Les permite brindar soporte eficiente a la mayoría de los administradores no tan experimentados que desean implementar Discourse. Puedes estar de acuerdo o no, yo también estuve un poco triste en el pasado, pero ahora lo entiendo mejor 
Si tienes una necesidad diferente a la de una rápida puesta en marcha como la mayoría de la gente, entonces estás mayormente solo. Una vez que lo sabes, está bien
Tenemos la misma necesidad de una imagen Docker de Discourse independiente. La ejecutamos en Kubernetes con Minio, fue un poco complicado ponerla en marcha, y todavía requiere mucho esfuerzo. También recibimos una buena ayuda de Discourse para hacerlo.
Nuestro trabajo está disponible aquí:
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(no está suficientemente documentado, ni probado, ni mantenido o actualizado a tiempo, ni automatizado, y probablemente un poco personalizado, es lo que es)
Si la gente está interesada en mejorarlo, no dudes en venir y hacer un PR, o chatear aquí: https://matrix.to/#/#libresh:liiib.re
Pero sí, el equipo de Discourse tiene una opinión firme sobre la versión comunitaria de Discourse. Puedes estar de acuerdo o no, pero brindan la mayor parte del soporte a la gente, y por lo poco que he visto, es un soporte increíble, así que creo que fue una buena decisión
6 Me gusta
Estos son aspectos fundamentales de cómo se empaqueta Discourse, más que del propio Discourse, que es un gran software, pero tienes razón, debería considerar diferentes soluciones.
2 Me gusta
Puedes quitar las plantillas para postgres y redis (así como ssl y let’s encrypt) y usar las tuyas.
2 Me gusta
Gracias por compartir. También encontré GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar e imágenes de bitnami. El principal problema es que estas soluciones no tienen soporte oficial. Me pregunto si podría ser una idea tener una configuración de Docker alternativa con soporte de la comunidad, en lugar de tener varios repositorios personalizados, ya que no sería eficiente distribuir el esfuerzo en varios lugares.
1 me gusta
Tienes razón, la configuración se puede cambiar efectivamente. Si consigo que funcione sin un gran esfuerzo, intentaré enviar algunas PR para mejorar las herramientas o la documentación existentes, como ejecutarlo sin permisos de root. Eso debería ser compatible con las opiniones del equipo de desarrollo, al tiempo que brinda cierto alivio a algunos administradores de sistemas más exigentes.
9 años después, ¿parece que Docker idiomático está cubierto por el discurso de Bitnami?
Pero en otros lugares de este foro hay afirmaciones de que consume mucha memoria y no tiene soporte. Me sorprendió ver cuánta fricción todavía existe en la configuración canónica al intentar ponerlo en funcionamiento en la nube.
Muchos servicios hoy en día como redis, postgres y almacenamiento compatible con s3 son fáciles de configurar y mover entre diferentes hosts como digitalocean, supabase, aws, etc., por lo que el backend es portátil. La VM que ejecuta Discourse parece que también debería ser fácil de escalar/intercambiar con compilaciones deterministas. Es una pena que esté tan cerca de este ideal pero se vea frenado.
Como dijo otro usuario, esto es sorprendente:
La lógica aludida anteriormente en el hilo de que hacer esto más fácil podría obstaculizar oportunidades comerciales es extraña. Los intereses comerciales tendrán personal para lidiar con las compilaciones complejas, por lo que esto afecta más a los desarrolladores individuales que a nadie. Mi caso de uso personal es que dirijo una comunidad muy grande (sin fines de lucro). Por lo tanto, no entra en la categoría de aficionado por escala ni comercial por ingresos.
1 me gusta
Eh… estoy pensando en configurar un foro/tablón de comunidad y obviamente pensé en usar Discourse (porque disfruto la experiencia del usuario final), pero de nuevo me encontré con el obstáculo de una instalación/gestión completamente hostil…
A lo largo de los años me he vuelto súper aficionado a tener todo funcionando con un simple archivo docker-compose, añadiendo un par de elementos adicionales (base de datos, minio para almacenamiento compatible con s3 y demás), pero no… Discourse sigue siendo súper hostil en este caso.
Lo siento, pero ¿tener algún “lanzador” tonto para iniciar las cosas?
Y luego el proceso de actualización que dice:
Crea una nueva imagen base manualmente ejecutando:
./launcher rebuild my_image
lo siento, ¿reconstruir manualmente la imagen? Como WTF… es como tener/usar docker pero en realidad no usarlo…
¿Funciona ./launcher rebuild app? Ese es el comando habitual.
Además, ¿seguiste la guía de instalación estándar?
No tengo nada constructivo que comentar, así que te pido que intentes actualizar el servidor de Mastodon, Pixelfed, Moodle… Discourse es increíblemente fácil.
Un comando manual es un obstáculo 
2 Me gusta