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 オーケストレーションに対して支払いを行っています。
これは非常にリスクが高く、危険なビジネスです。なぜなら、顧客のあらゆる問題の責任を問われ、通常は実際のインフラにアクセスできない（あるいは極めて限定的なアクセスしか許されない）うえ、仮にアクセスできたとしても、何らかの変更を行う権限も持たないからです。
これは「最悪のビジネスモデル」と言えるでしょう。