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?
Je me pose la même question en 2020. Docker Swarm, Kubernetes et Rancher semblent être des frameworks d’orchestration très populaires et paraissent être la méthode préférée pour exécuter des conteneurs dans des environnements de production. Ce projet rend la configuration très difficile, car vous utilisez un outil qui génère et lance les conteneurs. Pourquoi adopter si tôt la technologie des conteneurs pour votre projet, seulement pour frustrer les utilisateurs plus tard en ne suivant pas l’évolution de ladite technologie ?
Existe-t-il une approche que nous pourrions adopter pour faire fonctionner cela dans notre cluster ? Pouvons-nous sauvegarder les images générées par le script dans un registre Docker privé, afin de les ajouter ensuite à nos fichiers docker-compose.yml utilisables pour les déploiements de piles ?
Oui, c’est la bonne approche.
Ils ont acheté de mauvaises boules de cristal pour prédire l’avenir. Je leur ai dit d’en acheter de meilleures pour le prochain projet 
Sérieusement, comme vous l’avez demandé, il est facile de sauvegarder l’image résultante dans un registre de conteneurs et de la déployer ensuite avec l’outil de votre choix.
Et comme vous pouvez exécuter ledit conteneur via des scripts bash, Puppet, Chef, Ansible, Terraform, intégré dans une AMI, un script user-data, Docker Swarm, Docker Compose, Kubernetes, Capistrano, AWS ECS ou bien d’autres méthodes, il serait hors de notre champ d’action de dicter la gestion de votre infrastructure.
@Falco, Merci beaucoup pour vos retours, ils sont très appréciés.
J’ai essayé de convaincre notre client d’acheter un abonnement de licence commerciale pour Discourse, mais il est catégorique : il souhaite que Discourse soit hébergé sur son propre infrastructure sur site.
Il aurait été idéal si Discourse proposait des contrats de support, puisque le client est prêt à payer pour des services. Il paie déjà, par exemple, pour l’orchestration sur site d’Elastic.
C’est un secteur très risqué et dangereux dans lequel s’engager, car vous êtes tenu responsable de tous les problèmes des clients, alors que vous n’avez généralement aucun accès (ou un accès extrêmement limité) à leur infrastructure réelle, et vous n’avez pas l’autorité pour modifier quoi que ce soit, même si vous en aviez la possibilité !
C’est un modèle d’affaires qui combine tous les pires scénarios.