طريقة تثبيت Discourse على خادم VPS باستخدام Docker

تثبيت Discourse على خادم افتراضي خاص (VPS): حاوية واحدة، ملف إعداد واحد

لتثبيت Discourse على خادم VPS، شغّل أداة التثبيت الخاصة بالمشروع، وأجب عن أسئلة المعالج المختصر، ثم انتظر اكتمال عملية البناء. يأتي Discourse في شكل حاوية Docker واحدة تحتوي على تطبيق Rails وقاعدة بيانات PostgreSQL وRedis وخادم nginx. كل ما ستعدله لاحقاً موجود في ملف واحد هو /var/discourse/containers/app.yml، وأي تغيير يطرأ على الموقع يتطلب إعادة بناء الحاوية.

طريقة التثبيت الرسمية هي discourse_docker: وهي عبارة عن سكربت shell يحمل الرمز launcher مع مجموعة من قوالب YAML. لا يدعم Discourse ملف Compose تكتبه بنفسك، كما أن الحاوية غير مصممة ليتم تفكيكها يدوياً. إذا كنت معتاداً على تشغيل الخدمات على خادم VPS باستخدام Docker Compose، فتوقع هيكلية مختلفة. لا يوجد ملف docker compose up -d هنا، والأمر ./launcher rebuild app هو المسؤول عن عملية النشر.

متطلبات Discourse قبل البدء

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

• الذاكرة. تشغّل حاوية واحدة كلاً من PostgreSQL وRedis وSidekiq وخادم ويب Ruby. تتطلب خطوة البناء (build) تجميع الأصول (assets)، وهي تستهلك ذاكرة أكبر مما يستهلكه الموقع أثناء التشغيل.
• اسم نطاق حقيقي. ينص ملف الإعداد النموذجي بوضوح على: "لن يعمل Discourse باستخدام عنوان IP مجرد".
• مسار بريد صادر. تعتمد عمليات تفعيل الحساب، وإعادة تعيين كلمة المرور، ودعوات الإدارة، والرسائل الملخصة على بروتوكول SMTP (بروتوكول نقل البريد البسيط).
• المنفذان 80 و443 متاحان على المضيف، ما لم تقم عمداً بنقل Discourse خلف وكيل (proxy) تستخدمه بالفعل.

[
  {
    "label": "Documented minimum",
    "ram_gb": 1,
    "storage_gb": 10
  },
  {
    "label": "Documented recommended",
    "ram_gb": 2,
    "storage_gb": 20
  }
]

تحدد وثيقة التثبيت الرسمية الحد الأدنى بـ 1 جيجابايت من ذاكرة الوصول العشوائي مع مساحة تبديل (swap) و10 جيجابايت من مساحة القرص، وتوصي بـ 2 جيجابايت من ذاكرة الوصول العشوائي مع 20 جيجابايت من مساحة القرص. اعتبر الرقم في السطر الأول هو الحد الأدنى لإتمام عملية التثبيت، وليس الرقم الذي ترغب في تشغيل مجتمعك عليه. هذا الفارق مهم لأن ذروة استهلاك الذاكرة تحدث أثناء البناء، وليس بسبب حركة الزوار.

وجّه النطاق إلى الخادم قبل التثبيت

أنشئ سجل A لاسم المضيف الذي ستستخدمه، ثم تحقق منه من الخادم نفسه.

dig +short forum.example.com
curl -4 -s https://ifconfig.co

يجب أن يطبع كلا الأمرين نفس العنوان. يجب أن يتطابق العنوانان لأن معالج الإعداد يُجري اختبار اتصال مقابل اسم المضيف الخاص بك، وسيفشل هذا الاختبار إذا كان السجل لا يزال يشير إلى مكان آخر. قد يكون السجل الذي أنشأته قبل دقيقتين لا يزال مخزناً في الذاكرة المؤقتة، لذا انتظر حتى تنقضي قيمة TTL (زمن البقاء) القديمة بدلاً من محاولة تجاوز المعالج.

قرر الآن ما إذا كان السجل سيمر عبر شبكة توصيل محتوى (CDN). يخفي السجل الذي يمر عبر وكيل عنوان خادمك، مما يؤدي إلى فشل طلب الشهادة الخاص بالحاوية، لأن تحدي ACME (بيئة إدارة الشهادات التلقائية) يتم الرد عليه بواسطة الوكيل بدلاً من Discourse. أبقِ السجل بدون وكيل (unproxied) عند التثبيت الأول.

تشغيل المثبّت الرسمي

يؤدي أمر واحد إلى تثبيت git، وتثبيت Docker باستخدام سكربت التثبيت الخاص بـ Docker، واستنساخ discourse_docker في /var/discourse، وبدء معالج الإعداد.

wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash

إذا كان Docker مثبّتاً بالفعل على الخادم وتفضل تنفيذ كل خطوة بنفسك، يمكنك القيام بالعمل يدوياً.

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

نفّذ الأمر بصلاحيات root. إذا بدأت التشغيل كمستخدم عادي، سيتوقف discourse-setup فوراً مع ظهور This script must be run as root. Please sudo or log in as root first.. وفي حال عدم وجود Docker على الخادم، سيتوقف البرنامج مع ظهور Docker is not installed. Please install Docker first.، لأن الاستنساخ اليدوي لا يثبت أي شيء نيابة عنك.

ما يطلبه معالج الإعداد، وما يكتبه

اعتباراً من أغسطس 2026، يُعد discourse-setup غلافاً برمجياً خفيفاً. يقوم بتشغيل discourse/setup-wizard:release كحاوية تستخدم شبكة المضيف مع ربط مقبس Docker، ليتمكن المعالج من فحص الجهاز الذي يقوم بتهيئته. يطلب المعالج اسم المضيف وعناوين البريد الإلكتروني للمسؤول، ثم يطلب بيانات كتلة SMTP الخاصة بك. بعد ذلك، يكتب المعالج ملف containers/app.yml، ثم يعيد البناء.

هناك سلوكان يجدر بك معرفتهما قبل البدء. إذا كان الجهاز يعاني من نقص في الذاكرة ولا يحتوي على مساحة تبديل (swap)، يتوقف المعالج ويعرض عليك إنشاءها: يقوم الغلاف حينها بإنشاء ملف /swapfile بحجم 2 جيجابايت، ويضيفه إلى /etc/fstab، ويضبط vm.swappiness = 10 في /etc/sysctl.d/30-discourse-swap.conf، ثم يعيد تشغيل المعالج. عند انتهاء المعالج، يطبع Rebuilding app in 5 seconds (Ctrl+C to cancel)... وينفذ ./launcher rebuild app على المضيف. تستغرق عملية البناء هذه عدة دقائق على خادم VPS صغير، وتكون المرة الأولى هي الأبطأ لأن كل مورد يُجمّع من الصفر.

يسرد ./discourse-setup --help الأعلام (flags) المهمة عند حدوث خطأ ما. يكتب --skip-rebuild ملف الإعداد دون إجراء عملية البناء، بينما يتخطى --skip-connection-test فحوصات DNS والمنافذ. استخدم --skip-connection-test فقط عندما تعرف مسبقاً سبب فشل الاختبار، على سبيل المثال عندما يقع المضيف خلف جدار ناري للشبكة تتحكم أنت فيه.

اقرأ ملف app.yml قبل إعادة البناء الأولى

يكتب المعالج ملفاً أصبح الآن تحت مسؤوليتك للصيانة. افتحه باستخدام sudo nano /var/discourse/containers/app.yml. هذه هي الأجزاء التي تحدد كل شيء تقريباً.

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  ## Uncomment these two lines if you wish to add Lets Encrypt (https)
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

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

env:
  DISCOURSE_HOSTNAME: "forum.example.com"
  DISCOURSE_DEVELOPER_EMAILS: "you@example.com"
  DISCOURSE_SMTP_ADDRESS: smtp.example.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: user@example.com
  DISCOURSE_SMTP_PASSWORD: "your-smtp-password"

DISCOURSE_HOSTNAME هو العنوان الذي يستجيب عليه الموقع، ومنه يبني Discourse روابطه، لذا فإن القيمة الخاطئة ستؤدي إلى موقع يُحمّل مرة واحدة ثم يوجهك إلى مكان آخر. DISCOURSE_DEVELOPER_EMAILS عبارة عن قائمة مفصولة بفواصل، وتصبح تلك العناوين حسابات إدارية تلقائياً عند التسجيل الأول. ضع عنوانك الخاص هناك وسجّل باستخدامه، لأن هذه هي الطريقة التي يتم بها إنشاء أول حساب إداري.

يخزن الملف كلمة مرور SMTP الخاصة بك كنص عادي، لذا قيد الوصول إلى المجلد باستخدام sudo chmod 700 /var/discourse/containers. الملف بصيغة YAML، مما يعني أن المسافات البيضاء جزء من الإعدادات: أي مفتاح غير محاذٍ بشكل صحيح سيؤدي إلى فشل البناء مع خطأ في التحليل ويتركك بدون موقع. أحد الفخاخ موثق في ملف العينة نفسه. الرمز # داخل كلمة مرور غير موضوعة بين علامتي اقتباس يبدأ تعليقاً، لذا ضع أي كلمة مرور تحتوي عليه بين علامتي اقتباس.

البريد الإلكتروني هو الخطوة التي تعيق معظم عمليات التثبيت

اعتباراً من أغسطس 2026، يتيح لك المعالج تخطي إعداد SMTP واستخدام تسجيل الدخول عبر Discourse ID بدلاً منه، ويحتوي app.yml على مفتاح DISCOURSE_SKIP_EMAIL_SETUP مطابق، موصوف هناك بأنه يتخطى التحقق من إعداد البريد الإلكتروني. يُعد التخطي خياراً معقولاً لإلقاء نظرة أولية على البرنامج. لكنه خيار سيء للمجتمع، لأنه بدون بريد صادر لن يتمكن أحد من تفعيل حسابه أو إعادة تعيين كلمة المرور.

المشكلة العملية هي أن معظم مزودي VPS يحظرون المنفذ الصادر 25، لذا فإن خادم بريد بسيط على الخادم لن يقوم بالتسليم. استخدم مرحلاً (relay) موثقاً على المنفذ 587، أو على 465 مع TLS (أمن طبقة النقل) الضمني. بالنسبة للمنفذ 465، اضبط DISCOURSE_SMTP_FORCE_TLS: true، وهو ما يوصي به ملف الإعداد النموذجي لهذا المنفذ. اختبر إمكانية الوصول من المضيف قبل إعادة البناء.

nc -vz smtp.example.com 587

النتيجة السليمة هي سطر واحد ينتهي بـ succeeded!. إذا توقف الأمر ثم انتهت مهلته، فهذا يعني أن المنفذ محظور في المسار الخارج من خادم VPS الخاص بك، ولا يوجد إعداد في Discourse يصلح ذلك. انتقل إلى منفذ يسمح به مزودك، أو اطلب من المزود فتحه.

بمجرد تشغيل الموقع، أرسل رسالة اختبار من صفحة البريد الإلكتروني في لوحة الإدارة (Admin)، ثم اقرأ علامتي التبويب "Skipped" و"Bounced" في نفس الصفحة. هذه الألسنة هي المكان الذي يسجل فيه Discourse البريد الذي رفض إرساله والبريد الذي رفضه المرحل، وهي توضح السبب، مما يوفر وقتاً أطول من قراءة السجلات.

TLS: دع الحاوية تحصل على شهادتها الخاصة

إذا كان Discourse يسيطر على المنفذين 80 و443، فاستخدم آلية الإصدار المدمجة فيه. قم بإلغاء التعليق عن سطري قالب SSL الموضّحين أعلاه، ثم أعد البناء. يقوم القالب بتشغيل acme.sh، ويخزن الشهادات في المجلد المشترك تحت /shared/ssl، ويجددها وفق جدول زمني داخل الحاوية، ويضبط Discourse لفرض استخدام HTTPS.

يجب أن يظل المنفذ 80 قابلاً للوصول من الإنترنت لكي تنجح هذه العملية، لأن تحدي HTTP يُجاب عليه هناك. إن جدار الحماية الذي يسمح بالمنفذ 443 فقط سيؤدي إلى بناء يكتمل بنجاح، لكن الشهادة لن تُصدر أبداً. تحقق من النتيجة باستخدام ./launcher logs app مباشرة بعد إعادة البناء.

هل يجب وضع Nginx أو Caddy في المقدمة؟

إذا كان Discourse هو خدمة الويب الوحيدة على الـVPS، فلا تفعل ذلك. الحاوية تشغّل بالفعل نسخة Nginx مضبوطة مسبقاً، وإضافة وكيل (proxy) ثانٍ يضيف قفزة إضافية، وشهادة أخرى تحتاج للتجديد، ومصدراً جديداً لأخطاء الترويسات (headers).

اجعل الوكيل في المقدمة فقط عندما يستضيف الـVPS مواقع أخرى. أضف templates/web.socketed.template.yml إلى قائمة القوالب، وعلّق (comment out) سطري expose، واترك قالبي SSL معلّقين. عندها ستستمع الحاوية على مقبس unix في /var/discourse/shared/standalone/nginx.http.sock ولن تشغل أي منافذ، مما يحرر المنفذين 80 و443 لوكيلك الخاص.

server {
  listen 443 ssl;
  server_name forum.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;
  }
}

النقطتان الرأسيتان بعد .sock جزء من صيغة مقبس unix في Nginx، ويرفض sudo nginx -t الإعداد بدونهما. كما أن X-Forwarded-Proto ليس اختيارياً أيضاً. يكتب Discourse روابط مطلقة، وبدون هذه الترويسة سيصدر روابط http:// داخل صفحة HTTPS، مما يدفع المتصفحات لحظرها كمحتوى مختلط. بعد تحويل الحاوية للعمل عبر مقبس، تصبح مسؤولية TLS تقع على عاتقك، لذا أصدر الشهادة على المضيف عبر Certbot على Ubuntu 24.04 وnginx. إذا لم تستقر على وكيل بعد، فإن مقارنة بين nginx وCaddy وTraefik تغطي المقايضات التي تقوم بها.

عمليات إعادة البناء والترقيات والأوامر التي ستستخدمها فعلياً

cd /var/discourse
./launcher rebuild app

يقوم rebuild بتدمير الحاوية قيد التشغيل، ويُنشئ حاوية جديدة من app.yml، ثم يشغّلها. يكون الموقع خارج الخدمة طوال فترة البناء، لذا تعامل مع أي تغيير في الإعدادات على أنّه وقت توقف مجدول لبضع دقائق.

تغيير القيم الموجودة تحت env: فقط لا يتطلب ذلك. يقوم ./launcher destroy app && ./launcher start app بإعادة إنشاء الحاوية من الصورة التي بنيتها مسبقاً، وهو أمر يستغرق ثوانٍ. أي تغيير تحت templates: أو hooks: يغيّر الصورة نفسها، لذا فهو يحتاج إلى إعادة بناء كاملة.

تصل الترقيات بطريقتين. تُطبَّق إصدارات النقاط (Point releases) من واجهة الويب في /admin/upgrade، والتي يوفرها الملحق docker_manager الذي يقوم app.yml باستنساخه أثناء البناء. أما التغييرات على الصورة الأساسية أو القوالب فتأتي عبر git.

cd /var/discourse
git pull
./launcher rebuild app

عمليات إعادة البناء هي النقطة التي تفشل فيها الخوادم الصغيرة، لأن تجميع الأصول (asset compilation) يمثل ذروة استهلاك الذاكرة في النظام بأكمله. إذا توقف البناء في منتصف الطريق، مع ظهور dmesg لسطر مثل Out of memory: Killed process يشير إلى عملية ruby، فهذا يعني نفاد الذاكرة أثناء البناء رغم أن الموقع كان يعمل بشكل جيد قبل ذلك. أضف مساحة تبديل (swap) وأعد تشغيل عملية البناء.

./launcher logs app
./launcher enter app
./launcher cleanup

يطبع logs مخرجات الحاوية، ويفتح enter صدفة (shell) داخلها، بينما يحذف cleanup الحاويات التي توقفت لأكثر من 24 ساعة. نفّذ cleanup من وقت لآخر، لأن كل عملية إعادة بناء تترك خلفها حاوية قديمة، مما يؤدي إلى نفاد مساحة القرص في خوادم VPS الصغيرة بصمت.

النسخ الاحتياطي، والملف الذي لا يتضمنه النسخ الاحتياطي

خذ نسخاً احتياطية من صفحة Backups في لوحة Admin. يصل الأرشيف إلى المضيف في المسار /var/discourse/shared/standalone/backups/default/. تعمل المهمة نفسها من واجهة الأوامر (shell).

cd /var/discourse
./launcher enter app
discourse backup

يعكس الأمر discourse restore <filename> العملية، وتُرفض عمليات الاستعادة حتى تشغّل discourse enable_restore. وُجدت هذه الحماية لضمان عدم قيام أمر خاطئ بالكتابة فوق منتدى يعمل حالياً.

هناك فجوتان يجب عليك سدهما بنفسك. يحتوي الأرشيف على قاعدة البيانات، ولا يحتوي على الملفات المرفوعة إلا إذا كان إعداد النسخ الاحتياطي الذي يتضمن المرفقات مفعلاً، لذا تحقق من هذا الإعداد قبل الاعتماد عليه. لا يتضمن الأرشيف أبداً app.yml، لذا فإن الاستعادة على خادم VPS جديد لا تزال تتطلب اسم المضيف (hostname) وإعدادات SMTP الخاصة بك، مما يعني ضرورة نسخ ذلك الملف إلى خارج الخادم أيضاً.

يوجد الأرشيف أيضاً على القرص نفسه الذي يضم الموقع الذي يحميه، وهذا لا يُعد نسخاً احتياطياً. انقل الأرشيف إلى مكان آخر وفق جدول زمني.

rsync -avz root@forum.example.com:/var/discourse/shared/standalone/backups/default/ ~/discourse-backups/

تكلفة المنتدى النشط من ذاكرة الوصول العشوائي (RAM)

يضبط التمهيد (bootstrap) القيم UNICORN_WORKERS و db_shared_buffers بناءً على الذاكرة والمعالج اللذين يكتشفهما، ويحدد ملف الإعداد النموذجي سقفاً للمخازن المؤقتة المشتركة (shared buffers) عند ربع إجمالي الذاكرة. كل عامل من عمال unicorn هو عملية Ruby كاملة، ويعمل Sidekiq على تنفيذ المهام في الخلفية بجانبها، لذا فإن استهلاك الذاكرة يرتبط بعدد الطلبات المتزامنة وليس بعدد الأعضاء المسجلين. المنتدى الهادئ الذي يضم بضع مئات من الأعضاء لا يمثل عبئاً تشغيلياً ثقيلاً.

لا تحدد حجم الخادم بناءً على رقم ورد في مقال، بما في ذلك هذا المقال. قم بقياس احتياجاتك بنفسك.

free -m
docker stats --no-stream

الاستخدام المستمر لملف التبادل (Swap) مع بطء في تحميل الصفحات يعني أنك تعاني من نقص في ذاكرة الوصول العشوائي. أما ثبات استهلاك الذاكرة مع بطء الصفحات فعادة ما يشير إلى سبب آخر، لذا اقرأ ./launcher logs app قبل شراء خطة أكبر. أضف فحصاً من خارج الخادم أيضاً، لأن المنتدى الذي تنفد ذاكرته في الساعة 3 صباحاً يتوقف بصمت: مراقب حالة Uptime Kuma ذاتي الاستضافة على مضيف منفصل يخبرك بالأمر قبل أن يلاحظ أعضاؤك ذلك.

متى يكون Discourse خياراً غير مناسب

يُعد Discourse تطبيقاً ضخماً يتطلب تثبيتاً ثقيلاً ودورة إعادة بناء (rebuild) لكل إعداد موجود في app.yml. هذه التكلفة توفر لك أدوات إشراف حقيقية ومحرك بحث يعمل بكفاءة حتى عند تضخم الأرشيف. بالنسبة لمجموعة من ثلاثين شخصاً يبحثون عن مكان للدردشة، فإن هذا النظام أكبر بكثير مما تتطلبه محادثاتهم. اقرأ مقارنة برمجيات المنتديات ذاتية الاستضافة أولاً، واختر Discourse لأنك تحتاج إلى الميزات التي يقدمها، وليس لأنه الاسم الذي تعرفه مسبقاً.

FAQ

هل يمكنني تثبيت Discourse على خادم VPS بدون اسم نطاق؟

لا. تنص الإعدادات المرفقة على أنّ Discourse لن يعمل باستخدام عنوان IP مجرد، وDISCOURSE_HOSTNAME مطلوب. يبني Discourse روابط مطلقة انطلاقاً من اسم المضيف هذا، لذا فإن استخدام عنوان IP يؤدي إلى كسر الروابط ومنع إصدار الشهادات. أنشئ سجل A قبل البدء، وتأكد باستخدام dig +short forum.example.com من أنه يترجم إلى عنوان خادمك.

هل يجب عليّ إعداد SMTP لإنهاء التثبيت؟

اعتباراً من أغسطس 2026 يمكنك تخطي ذلك. يوفر معالج الإعداد تسجيل الدخول عبر Discourse ID كبديل، ويحتوي app.yml على خيار يتخطى التحقق من إعداد البريد الإلكتروني. لأي استخدام يتجاوز التجربة الأولية، قم بإعداده، لأن تفعيل الحساب وإعادة تعيين كلمة المرور يتمان عبر البريد. استخدم مرحلاً (relay) موثقاً على المنفذ 587 أو 465، حيث إن معظم مزودي VPS يحظرون المنفذ 25 الصادر.

لماذا فشلت عملية إعادة بناء Discourse في منتصف الطريق؟

الذاكرة هي السبب المعتاد. تتطلب عملية تجميع الأصول (assets) أثناء البناء ذاكرة أكبر مما يحتاجه الموقع أثناء التشغيل، لذا قد يفشل خادم يعمل بشكل جيد في إعادة البناء. إذا أظهر dmesg أن Out of memory: Killed process يشير إلى عملية ruby، أضف مساحة تبديل (swap) (ملف التبديل الخاص بالمعالج هو 2 GB) وشغّل ./launcher rebuild app مجدداً. أما البناء الذي يتوقف بسبب خطأ YAML فيشير إلى خطأ في المسافات البادئة (indentation) في app.yml.

هل يجب أن يعمل Discourse خلف خادم Nginx أو Caddy الخاص بي؟

فقط إذا كان خادم VPS يستضيف مواقع أخرى أيضاً. إذا كان يعمل بمفرده على الخادم، اترك الحاوية تحتفظ بالمنفذين 80 و443 لتصدر شهادتها الخاصة، مما يقلل من الأجزاء المتحركة. للمشاركة في الجهاز نفسه، أضف templates/web.socketed.template.yml، وقم بالتعليق على أسطر expose، ووجّه الطلبات (proxy) إلى مقبس unix في /var/discourse/shared/standalone/nginx.http.sock. مرر X-Forwarded-Proto، وإلا سيصدر Discourse روابط http:// داخل صفحة HTTPS.

كيف أقوم بنسخ احتياطي لـ Discourse ذاتي الاستضافة؟

استخدم صفحة النسخ الاحتياطي (Backups) في لوحة الإدارة، أو شغّل discourse backup بعد ./launcher enter app. تُحفظ الأرشيفات على المضيف في /var/discourse/shared/standalone/backups/default/. تأكد من تفعيل الإعداد الذي يتضمن المرفقات، وانسخ /var/discourse/containers/app.yml بجانب الأرشيف، وانقلهما معاً إلى جهاز آخر، لأن النسخ الاحتياطي الموجود على نفس قرص الموقع لا ينجو من العطل الذي صُمم النسخ الاحتياطي للحماية منه.