تشغيل مواقع ويب أخرى على نفس الجهاز الذي يعمل عليه Discourse

[Discourse]

إذا كنت ترغب في تشغيل مواقع ويب أخرى على نفس الجهاز الذي يعمل عليه Discourse، فأنت بحاجة إلى إعداد وكيل NGINX أو HAProxy إضافي أمام حاوية Docker.

ملاحظة: هذا مخصص للمسؤولين المتقدمين

يفترض هذا الدليل أنك قد قمت بالفعل بإعداد Discourse ليعمل بشكل صحيح - وإلا، فقد يكون من الصعب تحديد ما إذا كانت الإعدادات تعمل بشكل صحيح أم لا.

لا يمكنك استخدام ./discourse-setup لإعداد Discourse إذا كان خادم آخر يستخدم المنفذ 80 أو 443. ستحتاج إلى نسخ وتحرير samples/standalone.yml باستخدام محرر النصوص المفضل لديك.

تثبيت nginx خارج الحاوية

أولاً، تأكد من أن الحاوية لا تعمل:

cd /var/discourse
./launcher stop app

ثم قم بتثبيت nginx و certbot:

sudo apt-get update && sudo apt-get install nginx certbot python3-certbot-nginx

تغيير تعريف الحاوية

هنا نغير طريقة إعداد Discourse فعلياً. لا نريد أن تستمع الحاوية إلى المنافذ - بدلاً من ذلك، سنخبرها بالاستماع إلى ملف خاص.

تحتاج إلى تعديل /var/discourse/containers/app.yml لتعطيل ssl وإضافة قالب لإنشاء مقبس nginx. يجب أن يبدو هكذا:

# القوالب الأساسية المستخدمة؛ يمكن تقليلها لتشمل وظائف أقل لكل قالب حاوية:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  # - "templates/web.ssl.template.yml" # إزالة - سيتم التعامل مع https بواسطة nginx الخارجي
  # - "templates/web.letsencrypt.ssl.template.yml" # إزالة - سيتم التعامل مع https بواسطة nginx الخارجي
  - "templates/web.socketed.template.yml"  # <-- تمت الإضافة

تأكد من إزالة أو تعليق المنافذ المعرّضة بوضع # في المقدمة.

# أي المنافذ التي يجب تعريضها؟
# expose: علّق القسم بأكمله بوضع # في مقدمة كل سطر
# - "80:80"   # http
# - "443:443" # https

الآن يمكنك

/var/discourse/launcher rebuild app

إعادة بناء Discourse لجعل بياناته متاحة عبر المقبس.

إذا كنت تستخدم بعض الوكلاء العكسيين الآخرين الذين لا يمكنهم استخدام مقبس ويب، يمكنك بدلاً من ذلك تعريض منفذ مختلف في القسم أعلاه مثل - 8080:80.

إنشاء «موقع» NGINX لـ nginx الخارجي

أنشئ ملف موقع لـ Discourse:

cd /etc/nginx/sites-available
cp default discourse.example.com
cd ../sites-enabled
ln -s ../sites-available/discourse.example.com

بعد ذلك، عدّل هذا الملف عن طريق تعليق هذه الأسطر:

        #listen 80 default_server;
        #listen [::]:80 default_server;

وتعديل server_name و location stanza على هذا النحو:

    server_name discourse.example.com;  # <-- قم بتغيير هذا

location / {
                proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
                proxy_set_header Host $http_host;
                proxy_http_version 1.1;
                proxy_set_header X-Forwarded-For $remote_addr;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Real-IP $remote_addr;

}

إذا كنت تستخدم تثبيتاً من حاويتين، فسيكون سطر المقبس:

                proxy_pass http://unix:/var/discourse/shared/web-only/nginx.http.sock:;

ثم، في واجهة سطر الأوامر:

certbot --nginx
```\nواتبع التعليمات. إذا لم تفهم المطالبات، فمن المحتمل أنك لا ينبغي أن تقوم بذلك، ولكن يمكنك الرجوع إلى وثائق `certbot` للمساعدة.

يرى @pfaffman أن `certbot` سيقوم بذلك نيابةً عنك، ولكن إذا قمت بإجراء تغييرات على تكوين nginx، فستحتاج إلى

sudo service nginx reload

## إنشاء مواقعك الأخرى

لقد انتهيت من قسم Discourse!

أنشئ مواقع NGINX أخرى، ثم اربطها وفعلها، كما في الخطوة الأخيرة أعلاه.

## نصائح

- `sudo netstat -tulpn` : سيخبرك هذا بأي المنافذ المستخدمة
- `/var/log/nginx/error.log` : هو موقع سجل nginx على Ubuntu. سيخبرك هذا بما هو الخطأ عندما تحصل على خطأ 502 Bad Gateway.

[angus (Angus McLeod)]

The guide in the first post is great and, on the whole, still works just fine

There are three things worth noting:

1. I initially missed some of the app.yml changes. There are 3 things you need to change in your app.yml. If you miss any of these things it won’t work:

   1. Comment out all ssl templates in the templates. If you are using letsencrypt you will have two:

      # - "templates/web.ssl.template.yml"
      # - "templates/web.letsencrypt.ssl.template.yml"
      

   2. Add a socket template:

      - "templates/web.socketed.template.yml" 
      

   3. Comment out all exposed ports:

      # - "80:80"   # http
      # - "443:443" # https
      

2. As others mentioned, I had to change the ssl cert and key names in the discourse.conf:

   ssl_certificate      /var/discourse/shared/standalone/ssl/discourse.angusmcleod.com.au.cer;
   ssl_certificate_key  /var/discourse/shared/standalone/ssl/discourse.angusmcleod.com.au.key;
   

3. Turns out my site didn’t have a dhparams.pem key (dh stands for Diffie Hellman, there’s some good explanations of what this is here). You can generate this yourself:

   openssl dhparam -out /var/discourse/shared/standalone/ssl/dhparams.pem 2048
   

Some other things you may find useful:

• sudo netstat -tulpn: This will tell you what ports are being used

• /var/log/nginx/error.log: Is the location of the nginx log on ubuntu. This will tell you what the error is when you get a 502 Bad Gateway error.

• You may finish a ./launcher rebuild app, excitedly go to your domain to see if it worked and be greeted with a depressing 502 Bad Gateway error. Before giving up in frustration, try restarting nginx one more time:

  sudo service nginx restart

  This clinched it for me.

Now my sandbox is using nginx outside the container (although I haven’t added the extra website yet).

[raphael_jolivet]

Hi,

I am just doing a fresh install of Discourse.
I am very surprised that :

• The setup script does not simply allow to setup on a different port, disabling SSL support, and then it’s up to us to do reverse proxy as we want (Apache, Nging) : It seems such a common setup, it would save hundreds of hours of life to humanity
• I am even more surprised that the setup redirects us to an outdated forum topic, in which we need to dig for the proper information, instead of a proper documentation page, kept up to date.

Thanks guys anyway for your work, but I think there is room for improvement here.
Cheers

[mottosso (Marcus Ottosson)]

Just wanted to share how I accomplished this, it was a little easier than I first thought.

From an already running machine, with Caddy acting as a reverse proxy for a number of existing Docker containers already.

1. Clone discourse as per the official instructions
2. Copy /var/discourse/samples/standalone.yml → /var/discourse/containers/app.yml
3. Fill in SMTP settings and website address
4. Comment out 443:443 from the expose: section
5. Replace 80:80 → 3001:80, 3001 being the port I’m serving via Caddy
6. Run ./launcher rebuild app
7. Done

Whop!

[riking (Kane York)]

@TheBestPessimist I swapped the order of the HTTP/HTTPS sections, it works better than adding a “don’t do this!” notice

[sam (Sam Saffron)]

I would recommend just doing double NGINX, it is far more complex to set it up direct and has virtually no performance cost. Getting it right would be very hard cause we serve some files direct and have a layer of caching that is tricky to configure.

Note, customizing NGINX is easy with mixin templates have a look at the various example templates here: discourse_docker/templates at master · discourse/discourse_docker · GitHub

[cfstras (Claus Strasburger)]

PSA: If you want to allow uploads larger than 1MB to your site, you’ll also have to set client_max_body_size 100M in any nginx config that sits in front of your site.

For reference, here’s the full nginx config I use:

nginx config for other sites on same host

server {
    if ($host = discourse.mysite.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = backupname.mysite.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80; listen [::]:80;
    server_name discourse.mysite.org;
    server_name backupname.mysite.org;

    location / {
        proxy_pass http://unix:/var/discourse/shared/mysite/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# nginx 1.14.1 | intermediate profile | OpenSSL 1.1.0f | link

server {
    listen 443 ssl http2;  listen [::]:443 ssl http2;
    server_name discourse.mysite.org;
    server_name backupname.mysite.org;

    # from discourse examples
    http2_idle_timeout 5m; # up from 3m default
    client_max_body_size 50M; # allow 50M uploads

    location / {
        proxy_pass http://unix:/var/discourse/shared/mysite/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Real-IP $remote_addr;
    }
    ssl_certificate /etc/letsencrypt/live/backupname.mysite.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/backupname.mysite.org/privkey.pem; # managed by Certbot

    ###### https://mozilla.github.io/server-side-tls/ssl-config-generator/ ####

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;

    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /etc/letsencrypt/live/backupname.mysite.org/chain.pem;

    resolver 1.1.1.1;

}

[Godmar_Back]

إرشادات أنغوس لا تزال تعمل؛ لكن لدي سؤال: هل سيظل LetsEncrypt يعمل تلقائيًا مع هذا الإعداد بعد 3 أشهر عند موعد تجديد الشهادات؟ (أفترض/آمل أن الإجابة بنعم، حيث أن خادم nginx يقرأها مباشرة من /var/discourse/shared/standalone؟)

[Blechpirat (Karsten)]

@Godmar_Back واجهت هذه المشكلة للتو، ولم يتم تجديد شهادتي.

@angus - نظرًا لأننا نستخدم شهادات letsencrypt التي أنشأها discourse، لكننا علقنا الأجزاء ذات الصلة في app.yml، فأعتقد أن سكريبت التحديث لم يعد يُشغّل. هل وجدت حلاً لذلك؟

[Blechpirat (Karsten)]

لقد حاولت الدخول إلى التطبيق وتشغيل الأمر التالي:

"/shared/letsencrypt"/acme.sh --cron --home "/shared/letsencrypt" --force

وهو ما أظهَر لي على الأقل وجود مشكلة:

my.site.com: خطأ في التحقق: فشل جلب https://my.seite.com/.well-known/acme-challenge/XXXXXXXedited-out-XXXXXXXXXXXXXXXXXXXX: خطأ في الحصول على بيانات التحقق
[الأربعاء 25 آب 10:41:37 ت ع م 2021] يرجى التحقق من ملف السجل لمزيد من التفاصيل: /shared/letsencrypt/acme.sh.log

يُكرّر ملف acme.sh.log إلى حد كبير رسالة الخطأ، لكنه يُخبرني أيضًا أن جميع ملفات الإعداد فارغة.

من ناحية أخرى، حدّث acme.sh نفسه، لذا أفترض أنه لم يكن يعمل في الخلفية منذ فترة، ربما منذ أن انتقلت إلى nginx الخارجي.

[pfaffman (Jay Pfaffman)]

@Blechpirat

تمت إزالة التعليق عن الأجزاء ذات الصلة في ملف app.yml، وأظن أن سكريبت التحديث لم يعد يُشغّل.

ستحتاج إلى معالجة هذه الأمور خارج الحاوية. اتبع أي دليل مخصص لـ Let’s Encrypt و Nginx.

[Simon_Manning]

بما أن الفترة التي يمكنك فيها التعديل على المنشور قد انتهت، يمكنك الإشارة إليه. يمكنك الإشارة إلى أي منشور، بما في ذلك منشوراتك الخاصة، بالنقر على النقاط الثلاث ثم أيقونة العلم الموجودة في أسفل المنشور.

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

[herrdu]

https://meta.discourse.org/t/upload-problem-with-https-or-http2-and-s3/202799/3

[Nope]

لقد قمت للتو بتثبيت discourse الجديد على خادمي الجديد، وبعد استعادة النسخة الاحتياطية، واجهت الآن مشكلة تتعلق بـ SSL.

يُظهر النظام رسالة تفيد بأن “بعض أجزاء هذه الصفحة غير آمنة، مثل الصور”، وبعد بحث سريع على جوجل، تبين لي أن هذا يعني أن الصور والخطوط وما إلى ذلك لا يتم تقديمها عبر بروتوكول https. ومع ذلك، يبدو أن كل شيء يعمل بشكل صحيح.

لقد قمت بنسخ إعدادات NGINX، ولم تكن موجودة من قبل قبل استعادة النسخة الاحتياطية.

هل لديكم أي أفكار؟

https://parentofsociety.com

[JammyDodger]

يمكنك التحقق من أن force_https مفعّل في إعدادات المسؤول. كانت هناك بعض المشكلات المتعلقة بذلك مؤخرًا.

[cmdntd]

@riking

لا يمكنك استخدام ./discourse-setup لإعداد Discourse إذا كان خادم آخر يستخدم المنفذ 80 أو 443. ستحتاج إلى نسخ وتعديل samples/standalone.yml باستخدام محرر النصوص المفضل لديك.

إذا كان لدي Discourse docker على الخادم، ولكنه كان يستخدم المنفذ 980 و 9443 (وكيل احتياطي)
هل يمكنني استخدام ./discourse-setup لإعداد Discourse آخر؟ (سحب مجلد آخر من discourse)
أليس هذا أبسط؟

[Stephen]

لماذا قد تفعل ذلك بدلاً من تشغيل مواقع متعددة؟

[pfaffman (Jay Pfaffman)]

@cmdntd

هل يمكنني استخدام ./discourse-setup لإعداد Discourse آخر؟ (سحب مجلد آخر من discourse)

يمكنك إنشاء appy.yml ولكن لا يمكنك استخدام discourse-setup. انسخ الآخر وقم بتحريره.

@Stephen

لماذا ستفعل ذلك بدلاً من تشغيل مواقع متعددة؟

إنه نوعًا ما أكثر تعقيدًا ويتطلب أن تستخدم جميع المواقع نفس البريد والإضافات. بالنسبة لمعظم الناس، من الأسهل فقط تشغيل خادم آخر، أعتقد.

[cmdntd]

@pfaffman

إنه أكثر تعقيدًا ويتطلب من جميع المواقع استخدام نفس البريد والإضافات. بالنسبة لمعظم الناس، من الأسهل تشغيل خادم آخر، على ما أعتقد.

نعم، بالضبط
وسيتم دعم الخادم الفردي بشكل أكبر من قبل فريق discourse

@pfaffman

يمكنك إنشاء appy.yml ولكن لا يمكنك استخدام discourse-setup. انسخ الآخر وقم بتحريره.

هل يمكنك شرح كيفية القيام بذلك؟

1. كان لدي app.yml
   هل يمكنني نسخ مجلد discourse آخر، و app02.yml؟

2. هل يمكنني تشغيل ./discourse-setup عندما أقوم بنسخ مجلد discourse02 و app02.yml؟
   كيف يمكنني تكوينه هنا؟
   أريد التأكد من أن الحاويتين لا تتعارضان مع بعضهما البعض.

3. اسم الحاوية الحالية الخاصة بي هو “app”.
   هل يمكنني تغيير اسمها عن طريق إعادة تسمية app.yml؟