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 온프레미스 오케스트레이션 비용을 지불하고 있거든요.
이것은 매우 위험하고 위험한 사업 분야입니다. 왜냐하면 고객의 모든 문제에 대해 책임을 지게 되지만, 실제로는 고객의 인프라에 접근할 수 없거나(또는 극히 제한적으로만 접근할 수 있으며), 설령 접근할 수 있다 하더라도 아무것도 변경할 권한이 없기 때문입니다.
이것은 ‘모든 면에서 최악인’ 비즈니스 모델입니다.