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 中、用户数据脚本、Docker Swarm、Docker Compose、Kubernetes、Capistrano、AWS ECS 或许多其他方式，那么由我们来规定你的基础设施管理方式就完全超出我们的职责范围了。
@Falco，非常感谢您的反馈，我们很感激。
我曾尝试说服我们的客户购买 Discourse 的商业许可订阅，但他们坚持要在自己的本地基础设施上托管 Discourse。
如果 Discourse 能直接出售支持合同就好了，因为客户愿意为服务付费。例如，他们已经在为本地 Elastic 编排付费。
这是一个非常高风险、危险的行业——因为你会被归咎于客户的所有问题，而且你通常无法（或仅有极其有限的权限）访问他们的实际基础设施，即使能访问，你也没有权力更改任何内容！
这是一种“最糟糕”的商业模式。