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?
Estou com a mesma pergunta aqui em 2020. Docker Swarm, Kubernetes e Rancher parecem ser frameworks de orquestração muito populares e parecem ser o método preferido para executar containers em ambientes de produção. Este projeto torna a configuração muito difícil, pois você tem uma ferramenta que gera e inicia os containers. Por que adotar o envio do seu projeto em tecnologia de containers tão cedo, apenas para frustrar os usuários no futuro ao não acompanhar essa mesma tecnologia?
Existe alguma abordagem que possamos adotar para fazer isso rodar dentro do nosso cluster? Podemos salvar as imagens construídas pelo script em um registro Docker privado para, por sua vez, adicioná-las aos nossos arquivos docker-compose.yml que podem ser usados para implantações de pilhas?
Sim, e essa é a maneira correta de fazer.
Eles compraram bolas de cristal ruins para prever o futuro. Disse a eles para comprar melhores para o próximo projeto 
Sendo sério, como você perguntou, é fácil salvar a imagem resultante em um registro de contêiner e implantá-la depois usando a ferramenta que preferir.
E, como você pode executar esse contêiner usando alguns scripts bash, Puppet, Chef, Ansible, Terraform, integrado à AMI, script de user-data, Docker Swarm, Docker Compose, Kubernetes, Capistrano, AWS ECS ou muitas outras maneiras, seria muito fora do escopo para nós ditarmos o gerenciamento da sua infraestrutura.
@Falco, Muito obrigado pela contribuição, ela é muito apreciada.
Tentei convencer nosso cliente a adquirir uma assinatura de licença comercial para o Discourse, mas ele é inflexível em querer que o Discourse seja hospedado em sua própria infraestrutura local.
Seria ótimo se o Discourse vendesse contratos de suporte, já que o cliente está disposto a pagar por serviços. Eles já estão pagando, por exemplo, pela orquestração local do Elastic.
Este é um negócio muito arriscado e perigoso para entrar, pois você é responsabilizado por todos os problemas do cliente e, normalmente, não tem (ou tem acesso extremamente limitado) à infraestrutura real deles, nem autoridade para alterar qualquer coisa, mesmo que tivesse!
É um modelo de negócios do tipo “o pior de todos os mundos”.