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?
Anche nel 2020 mi trovo con la stessa domanda. Docker Swarm, Kubernetes e Rancher sembrano essere framework di orchestrazione molto popolari e sembrano essere il metodo preferito per eseguire container in ambienti di produzione. Questo progetto rende molto difficile la configurazione, dato che si utilizza uno strumento che genera e avvia i container. Perché adottare così presto la tecnologia dei container per distribuire il proprio progetto, solo per frustrare gli utenti in futuro non tenendo il passo con tale tecnologia?
Esiste qualche approccio che possiamo adottare per farlo funzionare all’interno del nostro cluster? Possiamo salvare le immagini create dallo script in un registro Docker privato per poi aggiungerle ai nostri file docker-compose.yml utilizzabili per le distribuzioni di stack?
Sì, ed è la strada da seguire.
Hanno comprato delle sfere di cristallo scadenti per prevedere il futuro. Gliel’avevamo detto di comprarne di migliori per il prossimo progetto 
Seriosamente, come hai chiesto, è facile salvare l’immagine risultante in un registro dei container e distribuirla successivamente utilizzando lo strumento che preferisci.
E dato che puoi eseguire tale container tramite script bash, Puppet, Chef, Ansible, Terraform, integrato nell’AMI, script user-data, Docker Swarm, Docker Compose, Kubernetes, Capistrano, AWS ECS o molti altri metodi, sarebbe fuori dalla nostra portata dettare la gestione della tua infrastruttura.
@Falco, Grazie mille per il contributo, è molto apprezzato.
Ho provato a convincere il nostro cliente ad acquistare un abbonamento alla licenza commerciale per Discourse, ma è fermamente deciso a voler ospitare Discourse sulla propria infrastruttura on-premises.
Sarebbe stato fantastico se Discourse vendesse direttamente contratti di supporto, dato che il cliente è disposto a pagare per i servizi. Stanno già pagando, ad esempio, per l’orchestrazione on-premises di Elastic.
È un settore molto rischioso e pericoloso in cui entrare, perché vieni incolpato per tutti i problemi del cliente e di solito non hai (o hai accesso estremamente limitato) alla sua infrastruttura reale, né hai l’autorità per modificare qualcosa, anche se ne avessi!
È un modello di business “il peggio di tutti i mondi”.