تشغيل Discourse مع WordPress (Docker) على خادم افتراضي واحد باستخدام وكيل Nginx العكسي

ويكي المجتمع Sysadmins
1

مقدمة

بشكل افتراضي، يربط تثبيت Discourse “المستقل” (standalone) بالمنافذ 80 و 443. لاستضافة تطبيق آخر مثل WordPress على نفس الخادم، يجب عليك إعادة تكوين Discourse للاستماع على منفذ داخلي واستخدام Nginx على مستوى المضيف كـ “وكيل عكسي” (Reverse Proxy) لإدارة حركة المرور وشهادات SSL.

1. نظرة عامة على البنية المعمارية

  • Nginx المضيف (Host Nginx): البوابة الأساسية التي تستمع على المنفذين 80 و 443. يتعامل مع إنهاء SSL (SSL termination) ويوجه الطلبات إلى الحاوية المناسبة بناءً على server_name.

  • حاوية Discourse: مُعاد تكوينها للاستماع على localhost:8080.

  • حاوية WordPress: مُدارة عبر Docker Compose، وتستمع على localhost:8081.

2. المرحلة أ: إعادة تكوين Discourse

عدّل ملف /var/discourse/containers/app.yml للتخلي عن المنافذ العامة:

  1. تغيير تعيين المنفذ (Port Mapping):

    YAML

    expose:
  - "8080:80"   # يعين منفذ المضيف 8080 إلى منفذ الحاوية 80

  2. تعطيل SSL الداخلي: علّق قوالب SSL و Let’s Encrypt:

    YAML

    templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  # - "templates/web.ssl.template.yml"
  # - "templates/web.letsencrypt.ssl.template.yml"

  3. إعادة البناء (Rebuild): قم بتشغيل ./launcher rebuild app.

3. المرحلة ب: نشر WordPress عبر Docker Compose

نظّم موقع WordPress الخاص بك في دليل مخصص. تأكد من أن وحدة تخزين قاعدة البيانات دائمة لمنع فقدان البيانات.

YAML

services:
  db:
    image: mariadb:10.11
    environment:
      MYSQL_ROOT_PASSWORD: 'your_secure_password'
    volumes:
      - ./mysql_data:/var/lib/mysql
  wordpress:
    image: wordpress:latest
    ports:
      - "8081:80"
    volumes:
      - .:/var/www/html

4. المرحلة ج: تكوين Nginx النهائي (SSL والمنفذ 443)

يتطلب الإعداد الاحترافي في عام 2025 دعم HTTPS الكامل و HTTP/2. بعد تثبيت Nginx على المضيف الخاص بك (sudo apt install nginx)، أنشئ تكوينًا لنطاقاتك.

نصيحة احترافية: قم بتشغيل sudo certbot --nginx لتوليد كتل SSL تلقائيًا، ولكن تأكد من أنها تتضمن رؤوس الوكيل (proxy headers) التالية لكي يعمل Discourse بشكل صحيح.

Nginx

server {
    listen 443 ssl http2;
    server_name discourse.com;

    # شهادات SSL بواسطة Certbot
    ssl_certificate /etc/letsencrypt/live/discourse.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/discourse.com/privkey.pem;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme; # حاسم لكشف HTTPS في Discourse
    }
}

5. الدروس المستفادة بصعوبة وأفضل الممارسات

  • بيانات اعتماد قاعدة البيانات: إذا كانت كلمات المرور الخاصة بك تحتوي على أحرف خاصة مثل & أو ?، فقم دائمًا بوضعها بين علامتي اقتباس مفردتين ' ' في ملفات التكوين وأوامر الطرفية لمنع أخطاء تفسير الصدفة (shell interpretation).

  • أذونات الملفات: تعمل حاويات WordPress كـ www-data (معرف المستخدم 33). إذا قمت بتحميل أو فك ضغط الملفات كـ root، فيجب عليك تشغيل chown -R 33:33 . لتجنب أخطاء الخادم الداخلي 500.

  • إعدادات Cloudflare: عند استخدام شهادة SSL على الخادم (Let’s Encrypt)، اضبط إعدادات SSL/TLS في Cloudflare على Full (Strict). هذا يمنع حلقة “إعادة التوجيه المفرط” (Too Many Redirects) التي يسببها عادةً وضع “Flexible”.

  • وحدات التخزين الدائمة (Persistent Volumes): لا تقم أبدًا بتشغيل docker compose down أو rebuild دون التحقق من تخزين ملفات قاعدة البيانات الخاصة بك في وحدة تخزين دائمة (مثل ./mysql_data).

الخلاصة: فصل تطبيقاتك عن المنافذ 80/443 باستخدام وكيل عكسي هو الطريقة الأكثر قابلية للتوسع لإدارة خادم افتراضي خاص متعدد المواقع. إنه يسمح بالإدارة المركزية لشهادات SSL وتصحيح الأخطاء بسهولة من خلال سجلات Nginx على مستوى المضيف.

إعجابَين (2)