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?
Ich habe 2020 dieselbe Frage. Docker Swarm, Kubernetes und Rancher scheinen sehr beliebte Orchestrierungsframeworks zu sein und gelten als bevorzugte Methode, um Container in Produktionsumgebungen auszuführen. Dieses Projekt ist jedoch sehr schwer einzurichten, da ein Tool die Container generiert und startet. Warum sollte man sein Projekt so frühzeitig auf Container-Technologie setzen, nur um Benutzer später zu frustrieren, indem man mit der genannten Technologie nicht Schritt hält?
Gibt es einen Ansatz, um dies in unserem Cluster auszuführen? Können wir die vom Skript erstellten Images in eine private Docker-Registry speichern und diese dann in unsere docker-compose.yml-Dateien integrieren, die für Stack-Bereitstellungen verwendet werden können?
Ja, und das ist der richtige Weg.
Sie haben schlechte Kristallkugeln gekauft, um die Zukunft vorherzusagen. Ich habe ihnen gesagt, sie sollen für das nächste Projekt bessere kaufen 
Im Ernst: Wie du gefragt hast, ist es einfach, das resultierende Image in einer Container-Registry zu speichern und es danach mit dem Tool deiner Wahl bereitzustellen.
Und da du diesen Container mit verschiedenen Bash-Skripten, Puppet, Chef, Ansible, Terraform, integriert in die AMI, User-Data-Skripte, Docker Swarm, Docker Compose, Kubernetes, Capistrano, AWS ECS oder auf viele andere Arten ausführen kannst, wäre es für uns völlig außerhalb unseres Aufgabengebiets, dein Infrastrukturmanagement vorzuschreiben.
@Falco, vielen Dank für deinen Input, das wird sehr geschätzt.
Ich habe versucht, unseren Kunden davon zu überzeugen, ein Business-Lizenz-Abonnement für Discourse zu kaufen, aber er besteht darauf, Discourse auf seiner eigenen On-Premises-Infrastruktur zu hosten.
Es wäre toll gewesen, wenn Discourse Support-Verträge anbieten würde, da der Kunde bereit ist, für Dienstleistungen zu zahlen. Er zahlt beispielsweise bereits für die On-Premises-Orchestrierung von Elastic.
Das ist ein sehr riskantes und gefährliches Geschäft, in das man sich begibt – denn man wird für alle Probleme des Kunden verantwortlich gemacht, hat typischerweise keinen (oder nur extrem eingeschränkten) Zugang zu dessen tatsächlicher Infrastruktur und verfügt auch nicht über die Befugnis, irgendetwas zu ändern, selbst wenn man das könnte!
Es ist ein Geschäftsmodell, das das „Schlechteste aus allen Welten