Looking for Production Discourse Instructions

[Dan_Healy]

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.

[jomaxro (Joshua Rosenfeld)]

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.

[Dan_Healy]

I’ve read both pages in detail, as well as a ton of other information. Just a couple of points I’ll make:

• In a production HA environment, it is not acceptable to have a single container run Rail,Redis, Postgresql, and Nginx.
• It’s not clear to me if the current Discourse Docker solution will run properly on an existing Docker Cluster with many other containers already running
• Our environment already has HA Postgresql, Redis, and a Docker Cluster - These should be leveraged
• The Discourse rails app should have the ability to start with a ‘docker stack deploy’ function, not a ./launcher script.

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.

[sam (Sam Saffron)]

@Dan_Healy

In a production HA environment, it is not acceptable to have a single container run Rail,Redis, Postgresql, and Nginx.

Sure, and we do not do that in our production instances, see: discourse_docker/samples at master · discourse/discourse_docker · GitHub

@Dan_Healy

It’s not clear to me if the current Discourse Docker solution will run properly on an existing Docker Cluster with many other containers already running

Runs fine for us

@Dan_Healy

Our environment already has HA Postgresql, Redis, and a Docker Cluster - These should be leveraged

Nothing stopping you leveraging that pg and redis location are passed in via environment vars

@Dan_Healy

The Discourse rails app should have the ability to start with a ‘docker stack deploy’ function, not a ./launcher script.

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?

[Dan_Healy]

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.

[rbrlortie (Kara L.)]

Did you get the chance to create that github repo with instructions?

[Julian_Labuschagne]

أنا أجلس مع نفس السؤال هنا في عام 2020. تبدو Docker Swarm وKubernetes وRancher أطر عمل للتنسيق شائعة جدًا، وتبدو الطريقة المفضلة لتشغيل الحاويات في بيئات الإنتاج. هذا المشروع يجعل الإعداد صعبًا للغاية نظرًا لأنك تستخدم أداة تقوم بتوليد وتشغيل الحاويات. لماذا يتم تبني نشر مشروعك على تقنية الحاويات بهذه السرعة المبكرة، فقط لإحباط المستخدمين لاحقًا في المستقبل من خلال عدم مواكبة هذه التقنية المذكورة؟

هل هناك أي نهج يمكننا اتخاذه لتشغيل هذا داخل مجموعتنا؟ هل يمكننا حفظ الصور المُنشأة من السكربت في سجل Docker خاص لإضافتها بعد ذلك إلى ملفات docker-compose.yml الخاصة بنا والتي يمكن استخدامها لنشر المكدسات؟

[Falco]

@Julian_Labuschagne

هل يمكننا حفظ الصور المُنشأة من السكربت في سجل Docker خاص، ومن ثم إضافتها إلى ملفات docker-compose.yml التي يمكن استخدامها لنشر المجموعات (stack deployments)؟

نعم، وهذه هي الطريقة الصحيحة.

@Julian_Labuschagne

لماذا اعتمدنا تقنية الحاويات (container technology) في وقت مبكر جدًا لمشروعك، فقط لإحباط المستخدمين لاحقًا في المستقبل؟

لقد اشتروا كرات بلورية رديئة للتنبؤ بالمستقبل. لقد أخبرتهم بشراء كرات أفضل للمشروع القادم

بجدية، كما سألت، من السهل حفظ الصورة الناتجة في سجل حاويات (container registry) ونشرها لاحقًا باستخدام الأداة التي تفضلها.

وبما أنه يمكنك تشغيل هذه الحاوية باستخدام بعض سكريبتات Bash، أو Puppet، أو Chef، أو Ansible، أو Terraform، أو دمجها في صورة AMI، أو سكريبت بيانات المستخدم (user-data script)، أو Docker Swarm، أو Docker Compose، أو Kubernetes، أو Capistrano، أو AWS ECS، أو بطرق أخرى عديدة، فسيكون من غير المنطقي تمامًا أن نحدد إدارة البنية التحتية الخاصة بك.

[Julian_Labuschagne]

@Falco، شكرًا جزيلاً لك على المدخلات، فهي موضع تقدير.

لقد حاولت إقناع عميلنا بشراء اشتراك في رخصة تجارية لـ Discourse، لكنهم مصرون على استضافة Discourse على بنيتهم التحتية الخاصة بهم داخل المنشأة.

كان سيكون رائعًا لو كانت Discourse تبيع عقود دعم فقط، حيث إن العميل مستعد لدفع ثمن الخدمات. فهم يدفعون بالفعل مقابل تنسيق Elastic داخل المنشأة على سبيل المثال.

[codinghorror (Jeff Atwood)]

هذا عمل خطير ومحفوف بالمخاطر للغاية للدخول فيه، لأنك تتحمل اللوم على جميع مشاكل العميل، وعادة لا يكون لديك أي وصول (أو وصول محدود للغاية) إلى بنيتها التحتية الفعلية، كما أنك لا تملك السلطة لتغيير أي شيء، حتى لو كان لديك ذلك!

إنه نموذج عمل “أسوأ ما في كل العوالم”.