Hi,
I’m already running the following and need to understand how to configure a Discource container with a production environment:
-Postgres Server
-Nginx (reverse proxy for all sites)
-Redis
-Docker cluster
My intention is to run a Discourse container and scale as needed. However, I need to protect data as done in production.
You will get most of the information you need from the Discourse Github repo and Discourse Docker Repo:
discourse/docs/INSTALL.md at main · discourse/discourse · GitHub
I’d suggest reading through both in detail, then asking specific questions if you get stuck on something.
I’ve read both pages in detail, as well as a ton of other information. Just a couple of points I’ll make:
I’ve run many rails containers before for enterprise applications. What I’m looking for is to understand if I’m going to need to build my own Discourse container (I hope not). And if not, where can I get the Discourse container (preferably from a ‘docker pull’ command) and start it with ‘docker stack deploy’ with a matching docker-compose.yml file.
I also need to know exactly what folders and files from inside the container I need to mount to the host (all our persistent data runs from a very fast NFS mount).
So, to recap, I intend to have a docker-compose.yml file that contains all the information to start the Discourse Rails app, including mounts, and the ability to scale replicas.
Sure, and we do not do that in our production instances, see: discourse_docker/samples at master · discourse/discourse_docker · GitHub
Runs fine for us
Nothing stopping you leveraging that pg and redis location are passed in via environment vars
This did not exist 3 years ago. So, yeah … maybe … but it would require a ton of new work.
Feel free to read through: Can Discourse ship frequent Docker images that do not need to be bootstrapped?
Sam, I appreciate the info. I’ll read through all of it and let you know shortly.
Note: It seems to me that the work required here to make this type of solution available is to carefully read through ‘launcher’ and produce deployment instructions that include the creation process and docker-compose.yml. I plan on doing this because I need it for myself. I’ll host my instructions on my own github repo for this (which doens’t exist yet) and link it back here.
Did you get the chance to create that github repo with instructions?
Me encuentro en la misma situación en 2020. Docker Swarm, Kubernetes y Rancher parecen ser los marcos de orquestación más populares y el método preferido para ejecutar contenedores en entornos de producción. Este proyecto hace que la configuración sea muy difícil, ya que se utiliza una herramienta que genera e inicia los contenedores. ¿Por qué adoptar la tecnología de contenedores para su proyecto tan temprano, solo para frustrar a los usuarios más adelante al no mantenerse al día con dicha tecnología?
¿Existe algún enfoque que podamos adoptar para ejecutar esto dentro de nuestro clúster? ¿Podemos guardar las imágenes compiladas por el script en un registro privado de Docker para, a su vez, añadirlas a nuestros archivos docker-compose.yml que podrían utilizarse para despliegues de pilas?
Sí, y esa es la forma correcta de hacerlo.
Compraron bolas de cristal de mala calidad para predecir el futuro. Les dije que compraran unas mejores para el próximo proyecto 
En serio, como preguntaste, es fácil guardar la imagen resultante en un registro de contenedores y desplegarla después con la herramienta que más te guste.
Y dado que puedes ejecutar dicho contenedor usando algunos scripts de bash, Puppet, Chef, Ansible, Terraform, integrados en la AMI, scripts de user-data, Docker Swarm, Docker Compose, Kubernetes, Capistrano, AWS ECS o muchas otras formas, sería muy fuera de nuestro alcance dictar la gestión de tu infraestructura.
@Falco, muchas gracias por tu aportación, es muy apreciada.
He intentado convencer a nuestro cliente de que deberían suscribirse a una licencia comercial para Discourse, pero son firmes en su decisión de querer tener Discourse alojado en su propia infraestructura local (on-premises).
Habría sido excelente si Discourse ofreciera contratos de soporte, ya que el cliente está dispuesto a pagar por servicios. Por ejemplo, ya están pagando por la orquestación de Elastic on-premises.
Este es un negocio muy arriesgado y peligroso en el que meterse, porque te culpan de todos los problemas del cliente y, por lo general, no tienes (o tienes un acceso extremadamente limitado) a su infraestructura real, ni tampoco tienes autoridad para cambiar nada, ¡incluso si la tuvieras!
Es un modelo de negocio que reúne lo peor de todos los mundos.