@pfaffman Si echas un vistazo a los cambios que hice, no he modificado las instrucciones de la plantilla web en discourse_docker, simplemente las he separado en 3 archivos, y eso es lo único que he solicitado realmente: uno de ellos ejecuta instrucciones que pueden ser independientes del entorno, como la instalación de gemas de Ruby, el repositorio de Discourse y los plugins, y así sucesivamente; otro realiza algunas validaciones y el tercero ejecuta tareas específicas del entorno, como la migración de la base de datos y la compilación previa de los activos.
La complejidad que creo que añade es que, cuando se agrega algo a esos archivos, el equipo de Discourse debe considerar si son o no específicos del entorno (como depender de elementos en la base de datos) y, basándose en eso, definir en qué archivo deben incluirse.
La instalación oficial funcionaría de la misma manera que ahora, excepto que incluiría las 3 plantillas en el archivo app.yml (o haría que el archivo templates/web.template.yml incluya esas 3, si es posible, y en este caso, desde la perspectiva del usuario, nada cambiaría), en lugar de hacerlo en más de un paso (no tendría las ventajas de la instalación en dos pasos, pero funcionaría exactamente como se hace actualmente, por lo que no habría cambios disruptivos).
Sé que las tareas de administración de sistemas pueden ser realmente complejas, pero intenté hacerlo de la manera más directa posible, considerando cómo se hace actualmente, para evitar demasiada complejidad (por eso no he mencionado k8s, separar los servicios en un archivo docker-compose o cosas similares, ya que requeriría cambios importantes, y en su lugar me basé en cómo se realiza en la instalación oficial).