El contenedor en el host nunca ejecuta install-nginx como se mencionó anteriormente.
No estoy seguro de que este tema sea particularmente útil.
No te gusta la arquitectura de Discourse, no aceptas las explicaciones de los desarrolladores sobre cómo se optimiza el producto, no pareces estar familiarizado con Docker y, según tu propia admisión, mientes en tus preguntas, lo que está desperdiciando nuestro tiempo en conjunto.
Este tema ya tiene la etiqueta unsupported-install porque te estás desviando mucho del alcance del soporte gratuito proporcionado a la comunidad. Si esto realmente te importa, ¿por qué no inicias un tema en Marketplace? De esa manera, puedes invertir tu propio dinero en pagar a un consultor para que te eduque, en lugar de nuestro tiempo.
No, lo siento. ¿Entonces necesito poner los comandos sed anteriores en la sección de hooks de app.yml? ¿Hay algún ejemplo de cómo hacerlo para modificar un archivo en el repositorio docker_discourse durante el arranque? Actualmente, esa sección solo tiene un comando git clone para plugins.
Probablemente podría incluir esos comandos sed en una sección cmd como el git clone, pero no sé en qué directorio vivirá el script install-nginx.
Además, ¿dónde se encuentra app.yml? No pude enlazar a la sección hooks anterior porque el directorio containers está vacío en el repositorio 
Toda la documentación para hacer esto existe aquí en meta. A todos nos gusta saltarnos la lectura del manual, pero en este caso realmente deberías volver a lo básico.
Francamente, estás abordando todo esto al revés.
Voy a señalar de nuevo a la etiqueta #unsupported-install: la expectativa es que si decides desviarte de la instalación estándar, asumirás tú mismo la carga técnica adicional.
¿Cómo instalaste la instancia?
Lo siento, pero sí me esfuerzo en buscar documentación antes de publicar. Me encantaría tener un manual de Discourse y ya he leído muchos de los temas etiquetados con #howo. Desafortunadamente, parece que no existe un manual de Discourse.
Agradezco mucho tu ayuda con esto, y estoy seguro de que también ayudará a otros en el futuro que estén buscando documentación sobre cómo realizar estas acciones…
Primero ejecuté discourse-setup, lo que finalmente me dio una instalación rota. Luego edité manualmente app.yml y ejecuté ./launcher rebuild app.
Creo que esta es una discusión interesante, solo para conocer mejor Discourse.
Yo optaría por nginx, quizás modificando lo suficiente el app.yml para agregar el módulo mod_security durante el proceso de compilación, y tener mi propia imagen base construida.
Ahora bien, Discourse es un software complejo que se ejecuta sobre Rails, lo cual es aún más complicado de implementar de manera fácil y consistente. Por eso, el equipo ha dado un paso adicional en la imagen Docker que crean.
La imagen tiene mucha magia negra, con toneladas y toneladas de optimizaciones solo para funcionar lo mejor posible en la instalación soportada.
Sabiendo esto, y siendo capaz de resolver todas las piezas del rompecabezas (como los 2-3 repositorios necesarios para que Discourse funcione), no es imposible lograr lo que deseas ejecutar.
Ahora bien, sabiendo que tu configuración es nginx -> varnish -> apache, ¿por qué no ejecutas nginx -> varnish -> Discourse con mod_security agregado a la imagen base y configurado mediante hooks?
Es muy, muy poco probable que mod_security aumente tu seguridad. Las personas que mantienen Discourse están muy preocupadas por la seguridad, por lo que es probable que los problemas que mod_security pretende solucionar ya estén resueltos. Además, la probabilidad de que, al agregar mod_security a tu imagen, Discourse deje de funcionar, es significativamente mayor que cero. Si instalas mod_security y descubres que Discourse no funciona, tendrás que encargarte tú mismo de modificar Discourse para que funcione con mod_security, ya sea convenciendo a los mantenedores de Discourse de que has identificado un problema de seguridad legítimo o asumiendo la responsabilidad de mantener tu propio fork en el futuro.
De esto no puede salir nada bueno. Es altamente improbable que de esto pueda salir algo bueno.
De acuerdo, otro WAF roza la seguridad por oscuridad.
Se están realizando esfuerzos proactivos reales para mantener la seguridad de Discourse:
Este tema se ha desviado de la pregunta original sobre ejecutar Discourse en Apache (en lugar de un proxy de vuelta a Nginx).
Pero creo que una discusión sobre colocar un WAF (mod_security u otro) delante de Discourse es útil para la comunidad, por lo que he creado un tema distinto para discutir específicamente Discourse + WAF aquí: