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?
Я задаю тот же вопрос в 2020 году. Docker Swarm, Kubernetes и Rancher кажутся очень популярными фреймворками оркестрации и, похоже, являются предпочтительным методом запуска контейнеров в производственных средах. Этот проект очень сложно настроить, поскольку у вас есть инструмент, который генерирует и запускает контейнеры. Зачем внедрять контейнерные технологии для вашего проекта так рано, лишь чтобы разочаровать пользователей в будущем, не следуя за развитием этих технологий?
Есть ли какой-либо подход, который мы могли бы использовать, чтобы запустить это внутри нашего кластера? Можем ли мы сохранять собранные образы из скрипта в частный реестр Docker, чтобы затем добавлять их в наши файлы docker-compose.yml, которые могут использоваться для развёртывания стеков?
Да, и это правильный подход.
Они купили плохие хрустальные шары, чтобы предсказывать будущее. Я же говорил им купить получше для следующего проекта 
Если серьёзно, как вы и спрашивали, сохранить полученный образ в реестр контейнеров и затем развёртывать его с помощью предпочитаемого вами инструмента — это совсем несложно.
Поскольку указанный контейнер можно запускать с помощью различных bash-скриптов, Puppet, Chef, Ansible, Terraform, встроенных в AMI, скриптов user-data, Docker Swarm, Docker Compose, Kubernetes, Capistrano, AWS ECS или множеством других способов, нам было бы крайне неуместно диктовать, как управлять вашей инфраструктурой.
@Falco, большое спасибо за ваш вклад, мы ценим это.
Я пытался убедить нашего клиента приобрести подписку на бизнес-лицензию для Discourse, но он категорически настаивает на размещении Discourse на собственной локальной инфраструктуре.
Было бы здорово, если бы Discourse просто продавал договоры технической поддержки, поскольку клиент готов оплачивать услуги. Они уже, например, платят за оркестрацию Elastic на локальной инфраструктуре.
Это очень рискованный и опасный бизнес, потому что вы несете ответственность за все проблемы клиентов, при этом обычно у вас нет (или крайне ограниченный) доступ к их реальной инфраструктуре, и у вас нет полномочий что-либо изменить, даже если бы доступ был!
Это бизнес-модель «худшего из всех миров».