لقد مضت عدة سنوات وأنا أدير منتدى Discourse يحتوي على كمية كبيرة من المحتوى ووفرة من الصور. يحتوي Maker Forums على أكثر من 100 جيجابايت من الصور وأكثر من 400,000 منشور، تم استيراد جزء كبير منها، بشكل أساسي من Google+، بينما تم إنشاء الباقي على الموقع. يصف هذا المنشور عناصر كيفية تهيئة Maker Forums في النهاية، وفي وقت لاحق، بعض حالات Discourse الأخرى. هذه هي المعلومات التي أتمنى لو كنت أعرفها عند البدء، والتي استخدمتها لمساعدة الآخرين على تجنب بعض المخاطر نفسها لحالات Discourse الخاصة بهم.
حان الوقت لجمهور أوسع.
تحذير: إذا لم تكن مرتاحًا للعمل كمسؤول أنظمة Linux، فمن المرجح أن هذا الدليل ليس لك. قد لا أكون على علم بجميع الطرق التي يفترض فيها معرفة Linux. إذا بدا هذا الاستنارة للقراءة، فقد تكون أنت الجمهور المستهدف. إذا بدا هذا مربكًا للقراءة، فمن المرجح أنك لست من الجمهور المستهدف. إذا بدا هذا كعمل، يرجى النظر في دفع CDCK أو @pfaffman لتشغيل Discourse نيابةً عنك؛ إنهم يعرفون ما يفعلونه. أو ابدأ بـ موقع discourse.group المجاني، ثم ادفع مقابل ما تنمو إليه.
أخطط (ولكن لا أضمن) لإبقاء هذا المستند محدثًا مع ممارساتي التي تغطي حالات Discourse التي أشارك في صيانتها. هذا مكتوب بشكل نصيحة، لكنني أعتزمه بشكل أساسي كنصيحة لنفسي ولأي مسؤولين يرثون نشرات Discourse التي كنت مسؤولاً عنها. بخلاف ذلك، يجب أن تعتبره نقطة انطلاق واحدة لـ بحثك الخاص لتحديد كيفية رغبتك في نشر Discourse.
إعداد النظام
استخدم نظام تشغيل مشتق من CentOS أو Ubuntu LTS. أي شيء يدعم Docker يمكن أن يعمل على الأرجح، لكنني استخدمت هذين.
Docker
أنا مستخدم Fedora. كنت أول قائد مشروع Fedora في Red Hat، وكنت أفضل بكثير تشغيل Discourse على Podman لأنني أرى أن نموذج أمانه أفضل من نموذج Docker. ومع ذلك، لا يتم دعم نشرات Discourse إلا على Docker، وستكون رائدًا كبيرًا إذا حاولت التشغيل على أي شيء آخر. (قد يعمل، في يوم من الأيام، مع Podman باستخدام podman-compose إذا تم دعم docker-compose في أي وقت.)
الآن بعد أن يدعم Docker cgroups v2، يمكنك تثبيت إصدارات Docker الرسمية على نظام مشتق من CentOS:
dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
dnf install --allowerasing docker-ce docker-ce-cli
(تضمين --alloweraseing بسبب تعارض مع podman، runc، و buildah التي قد تكون مثبتة بالفعل؛ يجب مسحها لتثبيت docker.)
systemctl enable --now docker
لقد اختبرت هذا مع AlmaLinux 9.
الأمان
هذا القسم لا علاقة له بـ Discourse per se، لكنه جزء من ممارستي الأمنية العادية. لا تسمح بالوصول إلى shell بكلمة مرور فقط لأي نظام على الشبكة، بما في ذلك VM الذي يشغل Discourse. قم بإعداد الوصول عبر SSH باستخدام مفتاح SSH مشفر بعبارة مرور، وقم بتكوين خادم ssh على VM الخاص بك لعدم السماح بالوصول بكلمة المرور.
laptop$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/.../.ssh/id_rsa):
Enter passphrase (empty for no passphrase): SOME LONG PHRASE
Enter same passphrase again: SOME LONG PHRASE
Your identification has been saved in .ssh/id_rsa
Your public key has been saved in .ssh/id_rsa.pub
تكون توزيعات Linux عادةً مضبوطة لتذكر عبارة المرور في الذاكرة، لذلك عليك فقط كتابتها مرة واحدة عند كل إقلاع. Windows ليس مريحًا بنفس القدر؛ قد تفكر في استخدام Pageant مع PuTTY للقيام بذلك.
أولاً، تحقق من أن SSH الوارد يعمل بدون كلمة مرور. فقط بعد ذلك، على الخادم، عدّل الملف /etc/ssh/sshd_config وابحث عن السطر PasswordAuthentication. اضبطه على no لتعطيل الوصول بكلمة المرور الوارد.
PasswordAuthentication no
جدار الحماية
ستحتاج إلى ترك المنافذ 80 و 443 مفتوحة بشكل عام لـ letsencrypt لتوليد وتجديد شهادات SSL الخاصة بك، حتى قبل أن يكون Discourse الخاص بك مفتوحًا للجمهور.
إذا كنت تستخدم firewalld، فإن هذه الأوامر ستحقق ذلك:
firewall-cmd --add-service http --add-service https --zone public
firewall-cmd --runtime-to-permanent
جهاز ونظام ملفات منفصل
اجعل /var/discourse/shared جهازًا منفصلًا بنظام ملفات خاص به، مع 20 جيجابايت من المساحة بالإضافة إلى ضعف المساحة التي تحتاجها للصور على الأقل؛ أضف المزيد من المساحة إذا كنت ستستخدم prometheus. إذا كان الجهاز سهل التوسع لاحقًا (مثل LVM أو أي تخزين كتلي سحابي مثل AWS elastic block storage) يمكنك مراقبته وتوسيعه حسب الحاجة؛ وإلا كن كريمًا في البداية. إذا كنت تستخدم جهاز تخزين كتلي شبكي، فلا تضع جدول تقسيم عليه. استخدام بدون جدول تقسيم سيجعله أسهل للتوسع؛ لن تضطر إلى تعديل جدول تقسيم. في العديد من الحالات ستتمكن من التوسع دون أي توقف للنظام.
على Maker Forums، هذا هو جهاز تخزين كتلي شبكي متصل بـ VM الذي يعمل عليه Maker Forums. على منتدى Discourse آخر، هو حجم تخزين كتلي من Digital Ocean. في Amazon، سيكون هذا AWS Elastic Block Storage. على نظام الاختبار الخاص بي الذي يشغل VM KVM تحت libvirt على Fedora، هو حجم LVM على مضيف Fedora مُصدّر إلى VM AlmaLinux كقرص افتراضي. في كل حالة، يمكنني إنشاء VM جديد، نسخ الملفات الرئيسية إليه، إيقاف VM القديم، ربط حجم /var/discourse/shared بـ VM الجديد، والعودة للعمل في دقائق. هذا يجعل ترقيات نظام التشغيل على VM منخفض المخاطر نسبيًا.
تأكد من أنك تبدأ بمساحة لا تقل عن 25 جيجابايت على نظام الملفات الجذري لـ VM الخاص بك، باستثناء أي مساحة لـ /var/discourse/shared. سيتم استخدام هذا لجميع حاويات docker، وسيفشل discourse launcher إذا كان أقل من 5 جيجابايت متاحًا في أي وقت. تريد أيضًا توفر مساحة كافية لتحديثات النظام. إذا لم يكن لديك مساحة قرص كافية، فهذا من الصعب التعافي منه.
في تهيئة الموقع، اضبط force_https لكن احذر من التحذيرات. اضبطه في الاختبار، قبل جعل موقع Discourse عامًا. لاحظ أنه حتى مع force_https تحتاج إلى فتح المنفذ 80، لإعادة التوجيه إلى SSL على المنفذ 443 وتجديد شهادة SSL الخاصة بـ letsencrypt. (ومع ذلك، إذا كنت تستخدم cloudflare، استخدم ميزته بدلاً من ذلك؛ يُقال إنه غير متوافق مع force_https في Discourse.)
تهيئة النواة
يوصي Redis (إحدى المكونات الرئيسية التي يُبنى عليها Discourse) بإيقاف الصفحات الكبيرة الشفافة عند استخدام الاستمرارية على القرص (وهو ما يفعله Discourse)، وأسمح أيضًا بالتجاوز الذاكرة.
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system
تثبيت Discourse
بينما يكون التثبيت الافتراضي حاوية واحدة، هذا يجعل كل ترقية، موصى بها شهريًا، عادةً 10-15 دقيقة من التوقف إذا تم من سطر الأوامر، وهو ضروري لبعض التحديثات، بما في ذلك تلك التي تحدث الأدوات التي يُبنى عليها Discourse، للأمان أو الميزات الجديدة، أو عندما يفشل التحديث المباشر من واجهة المستخدم لأي سبب. يمكنك تقليل هذا التوقف عمليًا مع تثبيت الحاويتين.
تثبيت الحاويتين
ابدأ التهيئة بحاويتين.
./discourse-setup --two-container --skip-rebuild
${EDITOR:-nano} containers/data.yml
./launcher rebuild data
# تفضيلي لاستخدام app.yml لكنك قد تلتزم بـ web_only.yml، اقرأ النص
mv containers/web_only.yml containers/app.yml
${EDITOR:-nano} containers/app.yml
./launcher rebuild app
هذا يجعل التوقف المطلوب للنظام كل بضعة أشهر قصيرًا جدًا، نادرًا ما يُلاحظ؛ لن يلاحظ العديد من المستخدمين ذلك على الإطلاق إذا لم ينقروا أو يتصفحوا المحتوى أثناء الانقطاع. هذا يسهل تطبيق معظم تحديثات الأمان؛ إنه مجرد وميض بدلاً من حوالي 15 دقيقة من إعادة بناء كل شيء. العملية التالية تعمل لمعظم التحديثات وتوفر عادةً حوالي 30-90 ثانية من التوقف، اعتمادًا بشكل أساسي على أداء نظام المضيف ومجموعة الإضافات المثبتة.
cd /var/discourse
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
لا تؤخر بين استدعاءات bootstrap و destroy/start. بشكل نادر (ربما مرة أو مرتين في السنة عمليًا)، ستسبب هجرات قاعدة البيانات التي تتم في نهاية مرحلة bootstrap أخطاء أكثر أو أقل خطورة للمستخدمين، بسبب الكود القديم الذي يصل إلى قاعدة البيانات المحدثة.
هذا يعني أنه عند تحديث Discourse، يجب عليك أيضًا التحقق مما إذا كنت بحاجة إلى تحديث حاوية البيانات أيضًا، لكن هذا نادرًا ما يكون مطلوبًا (تتوقع عادةً مرة أو مرتين في السنة). اعتمادًا على محتوى حاويات البيانات والتطبيق وسرعة النظام، سيؤدي هذا عادةً إلى توقف بين 5 و 20 دقيقة.
cd /var/discourse
git pull
./launcher stop app
./launcher rebuild data
./launcher rebuild app
لمزيد من المعلومات حول معرفة متى يجب تحديث حاوية البيانات، انظر:
(في نشراتي الخاصة، اخترت شخصيًا تسمية حاوية web_only باسم app لأنها أسهل في الكتابة ولأنها تجعل معظم التعليمات أسهل في المتابعة. هذا غير قياسي لكنني أقدّر سهولة الاستخدام. ومع ذلك، كان ذلك عملًا إضافيًا، ويعمل بالنسبة لي لأنني أعرف ما يحدث. إذا بدا ذلك سيئًا لك، التزم بـ web_only الافتراضي بدلاً من ذلك لنشر متعدد الحاويات.)
لاحظ أنه في وقت ما في المستقبل، قد يجبرك Docker على القيام بهجرة إلى تهيئة جديدة لربط حاوياتك:
إذا كان لديك 4 جيجابايت أو أكثر من الذاكرة، أو معالجات متعددة، اقرأ النصائح في:
جدول التحديثات
راقب وسم release-notes (انقر على release-notes وانقر على الجرس في الزاوية اليمنى العليا؛ أستخدم “مشاهدة المنشور الأول”) و/أو أضف https://meta.discourse.org/tag/release-notes.rss إلى تغذية RSS الخاصة بك لمعرفة متى تكون هناك إصدارات. اقرأ ملاحظات الإصدار قبل التحديث. إذا كان هناك تغيير في قاعدة البيانات، ستذكر ملاحظات الإصدار ذلك. ستشير أيضًا إلى الإصدارات التي تحتوي على تحديثات الأمان. اقرأ جميع ملاحظات الإصدار حتى إذا قمت بتخطي التحديث الفعلي إلى بعض الإصدارات؛ إذا لم تقم بقراءة ملاحظات الإصدار لإصدار يحدث قاعدة البيانات، قد تفوتك تعليمات تحديث قاعدة البيانات في ملاحظات الإصدار التي لم تقم بقراءتها.
البريد الإلكتروني
البريد الإلكتروني لا يزال أحد الطرق الرئيسية لإبقاء الناس متصلين. قم بإعداد البريد الصادر والوارد لجعل البريد الإلكتروني يعمل لصالحك. إذا واجهت مشاكل انظر:
الاستمرار في التواصل
رأى Maker Forums زوارًا عشوائيين الذين يغيبون لفترات طويلة قبل العودة. بشكل افتراضي، يتوقف Discourse عن إرسال رسائل بريد إلكتروني ملخصة بعد عام. فكر في ضبط suppress_digest_email_after_days على شيء أطول من الافتراضي 365 يومًا إذا كنت تريد تشجيع الزوار العشوائيين على العودة عندما يرون شيئًا جديدًا ومثيرًا للاهتمام. جعلته أطول بكثير لـ Maker Forums لدعم الزوار العشوائيين في مواكبة الأخبار. قراءة رسائل البريد الإلكتروني الملخصة هي طريقة صالحة “للتنصت” على منتدى، وأنت لا تعرف أبدًا متى سيثير شيء ما اهتمام شخص ما بالمساهمة.
وبالمثل، بشكل افتراضي، يتم حذف المستخدمين غير المميزين الذين لم يتفاعلوا كثيرًا (مستوى ثقة 0 بدون منشورات) في النهاية بعد 730 يومًا من عدم تسجيل الدخول. اضبط “تنظيف المستخدمين غير النشطين بعد أيام” على 0 لتعطيل حذف المستخدمين، إذا كنت تريد أن يكونوا قادرين على التنصت لقراءة رسائل البريد الإلكتروني الملخصة إلى الأبد.
فكر في إضافة إضافة المراجعة السنوية التي ستولد منشورًا مثل 2020: The Year in Review وفي النهاية ترسله بالبريد الإلكتروني إلى المستخدمين غير النشطين مما قد يشجعهم على تجديد المشاركة.
حاوية مستقبل البريد
قم بإعداد حاوية ثالثة كمستقبل للبريد. يضمن معالجة الارتدادات، يجعل معالجة الارتدادات الخاصة بك مستقلة عن مزود البريد الصادر، ويعطيك خيار الرد بالبريد الإلكتروني.
تأكد من أن لديك SPF مضبوطًا للثقة في مرسل البريد الإلكتروني الخاص بك؛ بشكل أساسي، سياسة مثل v=spf1 +mx -all إذا كنت ترسل وتستقبل عبر نفس MX، لكن أكثر تحديدًا قد يكون أكثر ثقة كحماية من البريد العشوائي. فكر في DKIM أيضًا.
إذا كنت تستخدم نفس اسم المضيف لاستقبال البريد الإلكتروني، يجب أن تنهي SSL خارج حاويتك كما في “صفحة غير متصلة” (انظر أدناه) وستحتاج إلى ربط شهادات certbot الخاصة بك في الحاوية وإعادة تشغيل الحاوية بعد تشغيل certbot.
إنهاء اتصالات SSL للمستخدم خارج الحاوية
هناك خياران لإنهاء SSL خارج الحاوية، أي منهما يجلب مزايا كبيرة مقارنة بإنهائه داخل الحاوية. قم بإعداد أحدهما بعد أن تكملت بنجاح discourse-setup وقمت بتهيئة منتداك.
nginx خارجي
استخدم nginx يعمل على نظام المضيف، بدلاً من فقط في حاوية، لاستضافة صفحة صيانة، ودعم تسجيل عناوين IPv6 إذا كان مضيفك يدعم IPv6. (بخلاف ذلك، سيتم تسجيل جميع اتصالات IPv6 وكأنها تأتي من عنوان RFC1918 الداخلي المرتبط بواجهة الشبكة الافتراضية المحلية الخاصة بك.) ستعرض هذه التهيئة صفحة صيانة مؤقتة أثناء معظم عمليات الصيانة والتي ستعيد التوجيه في النهاية إلى الصفحة التي كان المستخدم ينظر إليها.
لاحظ أن التعليمات على تلك الصفحة (حاليًا) تقترح تثبيت حزمة تسمى letsencrypt لكنها تسمى الآن عادةً certbot بدلاً من ذلك. إذا اتبعت التعليمات على تلك الصفحة لاستخدام --certonly، فلن تحتاج إلى إضافة nginx لـ certbot، لكن تثبيت إضافة nginx هو آلية أخرى. على مشتقات CentOS:
dnf config-manager --set-enabled crb
dnf install epel-release
dnf install certbot python3-certbot-nginx
systemctl enable --now certbot-renew.timer
تأكد من أن certbot يعيد تشغيل nginx وحاوية مستقبل البريد حتى لا ينتهي بك الأمر مع متصفحات أو بريد إلكتروني يحظر حركة المرور مع موقعك بسبب الاستمرار في استخدام شهادة قديمة منتهية الصلاحية.
# systemctl edit certbot-renew
لنظام بدون مستقبل بريد، أضفت السطرين:
[Service]
ExecStartPost=/bin/systemctl reload nginx
على نظام حيث أستخدم حاوية مستقبل بريد منفصلة تشارك أيضًا الشهادة من النظام:
[Service]
ExecStartPost=/bin/systemctl reload nginx
ExecStartPost=/bin/sh -c 'cd /var/discourse && ./launcher restart mail-receiver'
إذا كنت تستخدم SELinux، فإن حاويات Ubuntu ليست مضبوطة لتسمية ملف nginx.http.sock بـ httpd_sys_content_t حتى يتمكن nginx الخارجي من الوصول إليه. لديك خياران.
الأول هو تشغيل nginx في وضع التسامح، إزالة حماية SELinux له: semanage permissive -a httpd_t
ومع ذلك، هذا يزيل حماية SELinux عن الخدمة الأكثر صلة على الأرجح! لإبقاء SELinux مفعلًا، ستحتاج إلى السماح لـ nginx بالوصول إلى صفحات الخطأ والتبديل من التوجيه عبر مقبض المجال unix إلى منفذ (وهو أبطأ بـ µs قليلة، لكن يجب ألا يكون ملحوظًا للمستخدمين).
أولاً، نفذ هذه الأوامر للسماح لـ nginx بالوصول إلى صفحات الخطأ:
semanage fcontext -a -t httpd_sys_content_t /var/www
restorecon -R -v /var/www
ثم في app.yaml الخاص بك، علّق أو احذف - "templates/web.socketed.template.yml"، اعرض المنفذ 80 كمنفذ مختلف على الجهاز المحلي وأعد بناء الحاوية.
expose:
- "8008:80" # http
لا تستخدم https هنا — لقد أنهيت SSL في nginx الخارجي، ورأس X-Forwarded-Proto يخبر Discourse أن الطلب جاء عبر https. تأكد من أن المنفذ 8008 (أو أي منفذ آخر اخترته) غير معروض للجمهور بإعدادات جدار الحماية الخاص بك.
ثم نفذ هذا الأمر للسماح لـ nginx بالاتصال عبر الشبكة إلى الحاوية:
setsebool -P httpd_can_network_connect 1
ثم عدّل تهيئة nginx الخارجي من التوجيه عبر nginx.http.sock إلى http://127.0.0.1:8008 (أو المنفذ الذي اخترته) وقم بإزالة رأس Connection: close الافتراضي، حتى لا يضطر nginx الخارجي إلى إنشاء اتصال IP جديد لكل طلب.
...
location / {
proxy_pass http://127.0.0.1:8008;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
# Disable default "Connection: close"
proxy_set_header "Connection" "";
...
إزالة web.socketed.template.yml أزالت أيضًا استدعاء real_ip، لذا أضف ذلك مرة أخرى. تأكد من أن نطاق عنوان IP الذي تستخدمه منطقي؛ الافتراضي لـ Docker هو استخدام مساحة عنوان RFC1918 172.16* التي لا يتم توجيهها على الإنترنت العام حسب السياسة. أضف إلى ملف app.yml الخاص بك شيئًا مثل هذا في قسم التشغيل، واختر واحدة أو أكثر من مساحات عناوين RFC1918 أو أي شيء آخر مناسب لنشرك:
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header X-Forwarded-For;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from.conf
chmod: 644
contents: |
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 172.16.0.0/12;
set_real_ip_from 10.0.0.0/8;
هذا مطلوب لعمل الحد من المعدل بشكل صحيح، وكذلك لإسناد عناوين IP للتسجيل والأخير للاستخدام للمستخدمين.
لمزيد من المعلومات:
خدمة خارجية
لم أقم بتكوين Fastly أو Cloudflare أمام Discourse، لكن آخرين فعلوا، وعلى عكس nginx الخارجي الذي يعمل على المضيف، يمكن أن تسمح لك بتقديم صفحة صيانة بينما يكون نظام المضيف متوقفًا تمامًا، مثل عند إعادة التشغيل أثناء تحديث النظام على مضيفك. إذا كان هذا يستحق الجهد بالنسبة لك، إليك كيفية القيام بذلك:
لا تستعجل التحميلات إلى S3
كن متأكدًا جدًا من أنك تريد دائمًا استخدام S3 (أو ما يعادله) للصور المحملة قبل تمكين enable_s3_uploads أثناء الإعداد، أو الهجرة إليه لاحقًا. كن على دراية بأن استخدام S3 (s3_endpoint) مع CDN المرتبط به (s3_cdn_url) للصور سيؤدي أيضًا إلى تقديم javascript عبر ذلك CDN. الهجرة من S3 مرة أخرى إلى التخزين المحلي غير مدعومة ولا توجد خطط ملموسة لتنفيذها في الوقت الحالي. إنه “باب ذو اتجاه واحد” لا يمكن حتى إلغاؤه بنسخة احتياطية واستعادة كاملة. إذا استخدمت S3 أو ما شابه، لا تستخدم Digital Ocean Spaces بدلاً من S3. هناك مراجع هنا على meta بأنها غير موثوقة.
نقلت موقعي لتقديم الصور عبر Digital Ocean Spaces و CDN المرتبط به في وقت مبكر، واضطررت لكتابة مئات الأسطر من الكود المخصص للهجرة مرة أخرى إلى التخزين المحلي، مما تسبب في أضرار طفيفة في حالة Discourse الخاصة بي في العملية، بسبب عدم فهم “الباب ذو الاتجاه واحد” جيدًا.
لمزيد من المعلومات:
لا تحتاج إلى تمكين تحميلات S3 لاستخدام CDN لـ Discourse الخاص بك. فكر في استخدام CDN مستقل (مثل Cloudflare، CloudFront، Fastly، GCS CDN) أمام Discourse يدير صوره الخاصة. فهمي غير المباشر هو أن التحذير من عدم التوصية بـ Cloudflare يعود إلى تعديل “Rocket Loader” لـ JavaScript؛ وأن في الوقت الحالي، طالما أنك لا تستخدم “Rocket Loader” فإنه يعمل بشكل صحيح.
إعدادات Discourse للإشراف
على أي موقع حيث يكون الإشراف نشطًا، فكر بشدة في تهيئة enable_whispers التي تسمح للمشرفين والإداريين بالتحدث عن موضوع في السطر. أيضًا، تم منح مشرفي الفئات المزيد من القدرات في الإصدارات الحديثة من Discourse. يستحق أن تكون على دراية بـ enable_category_group_moderation إذا كان لديك خبراء في مواضيع مختلفة بفئاتهم الخاصة، أو إذا كان لديك فئات منفصلة وظيفيًا مثل تلك الخاصة بالدعم.
يمكن أن يكون تحديد الموقع الجغرافي مفيدًا عند محاولة فهم ما إذا كانت الحساب شرعية.
ميزة Discourse Templates مفيدة حقًا للمشرفين. تسمح لك بالتعاون على الردود الشائعة. لدينا بضع عشرات في Maker Forums. لديها ميزات أكثر من إضافة “الردود الجاهزة” السابقة التي تحل محلها.
ستساعد ميزة ملاحظات المستخدم المشرفين على مشاركة الملاحظات حول المستخدمين. يمكنك استخدام هذه لأشياء مثل:
- “راقب هذا المستخدم، قد يكون ضارًا لأن …”
- “بينما يبدو هذا السلوك مشبوهًا، لقد التحققت من أن هذا مستخدم شرعي من خلال …”
- “أنا بالفعل في محادثة مع هذا المستخدم لمعالجة المخاوف، المشرفون الآخرون لا يحتاجون إلى التزاحم.”
إمكانية الوصول للمعلومات
إضافة Discourse Solved لا تحدد فقط المشكلات المحلولة حتى يتمكن زوار الموقع من تحديدها بسهولة أكبر، لكنني أفهم أنها قد تعطي أيضًا أولوية لنتائج بحث Google.
المعلومات العامة أكثر سهولة من المعلومات الخاصة. على Maker Forums، دليل الأسئلة الشائعة الخاص بنا ينصح بشدة ضد الرسائل الشخصية ويذكر الجميع بأن الرسائل الشخصية ليست خاصة حقًا. ومع ذلك، بشكل افتراضي، قد يرى المستخدمون الرسالة:
لقد رددت على user 3 مرات، هل كنت تعلم أنه يمكنك إرسال رسالة شخصية لهم بدلاً من ذلك؟
إذا كنت تريد حقًا تشجيع المستخدمين على الذهاب إلى الرسائل الشخصية، أقترح أن تذهب إلى Admin → Customize → Text وتعدل قالب get_a_room لإصلاح فصل الفواصل.
إذا، مثل Maker Forums، تريد إبقاء المحادثة عامة لخدمة الجميع، Admin → Settings → Other → get_a_room_threshold يمكن ضبطه أعلى، مثل 1000000.
وبالمثل، إذا كان لديك منتدى يقدم المساعدة، فإن الافتراضي max_replies_in_first_day 10 قد يدفع المستخدمين الجدد في محادثة يطلبون المساعدة إلى الرسائل الشخصية عندما يستهلكون ميزانيتهم من الردود. فكر في زيادة هذا الإعداد لتجنب دفع المحادثات إلى الرسائل الشخصية.
ربط المستخدمين، بناء مجتمع
بعض الإضافات يمكن أن تساعد في ربط المستخدمين ببعضهم البعض.
إذا لم يكن لديك الكثير من المستخدمين المتزامنين في منتداك، فكر في إضافة Who’s Online لإعطاء الناس شعورًا أكبر بالاتصال. قد ترغب في تقييد العرض للمستخدمين المسجلين الدخول فقط، ربما فقط أولئك الذين وصلوا إلى مستوى ثقة 1 على الأقل. يمكنك استخدامه فقط لإضافة علامة حضور (whos_online_avatar_indicator) إلى الصور الرمزية عن طريق ضبط whose_online_minimum_display عاليًا جدًا و whos_online_hide_below_minimum_display صحيحًا. يمكن أن يكون هذا مفيدًا لمنتديات الدعم لدعم وتشجيع الأسئلة والإجابات السريعة بينما يساعد المستخدمين على حل المشكلات.
ومع ذلك، يمكن أن يكون شعور الحضور ذو حدين. مستخدم يكون متصلًا في وقت مختلف من معظم مستخدمي المنتدى قد يشعر بالوحدة، أو قد يبدو المنتدى كـ “مدينة أشباح” بالنسبة لهم.
إذا كان لديك مستخدمون في العديد من البلدان وتريد أن يكون لديهم تلميحات حول متى يكون كل منهم متاحًا على الأرجح، فكر في إضافة National Flags، وشجع المستخدمين على ضبط علم وطني في ملفاتهم الشخصية.
أحد الأمور الصعبة هو الترجمة. سيكون من المريح مساعدة الناس على التواصل عندما لا يتحدثون نفس اللغة، لكن حاليًا (حتى وقت كتابة هذا التقرير) لا توجد خدمات ترجمة ذات طبقات مجانية. إذا اخترت الدفع مقابل خدمات الترجمة، يمكنك تمكين الترجمة مع إضافة Discourse Translator.
النسخ الاحتياطي
للملفات النظامية، فكر في عمل نسخة احتياطية على الأقل لـ:
/var/discourse/containers(لتفاصيل تهيئة discourse)/var/www(لصفحات الخطأ)/etc/ssl(لتهيئة letsencrypt، لتجنب الحاجة إلى تهيئة certbot كجزء من استعادة النسخة الاحتياطية؛ بخلاف ذلك عليك تعليق قسم SSL من تهيئة nginx الخاصة بك أثناء التهيئة؛ هذا يعمل فقط إذا حافظت على النسخ الاحتياطية حديثة لأن الشهادات لها صلاحية قصيرة)/etc/systemd/system/backup-uploads.service(لعمل نسخ احتياطية للصور إلى S3)/usr/local/bin/mc(minio-client كأداة نسخ احتياطي للصور، إذا اخترت استخدامه)/root/.mc(تهيئة للنسخ الاحتياطي للصور مع minio-client)/root/.ssh(مصادقة جلسات SSH الواردة)
بعض هذه الملفات قد تنسخها احتياطيًا عن طريق التحقق منها في Git ودفعها إلى مكان ما خارج الموقع. إذا كانت الملفات التي تتحقق منها في Git تحتوي على أسرار (مثل كلمات مرور قاعدة البيانات)، فلا تدفعها بالتأكيد إلى مستودع عام. بدلاً من ذلك، يمكنك برمجة نسخها خارج النظام والتحقق منها في Git على نظام إشرافي تتحكم فيه. برمج هذا بكثرة كافية لإبقاء نسخك الاحتياطية من /etc/ssl حديثة.
الهدف هو وجود نسخ احتياطية في حالة الكوارث ولوجود سجل للتغييرات في حالة الخطأ.
بديل أفضل لمعظم هذه الملفات هو إبقاء النسخ القياسية في مكان آخر، واستخدام أداة مثل Ansible للحفاظ على التهيئة على النظام، مما يجعله سهل التحديث بعد النسخة الاحتياطية. لكن إذا كنت ستفعل ذلك، فأنت على الأرجح قد اكتشفت ذلك بدون أن أخبرك!
تهيئة Discourse للنسخ الاحتياطي
-
انسخ الصور المصغرة احتياطيًا مع
include_thumbnails_in_backups. الاستعادة بدون صور مصغرة يستغرق وقتًا طويلاً لإعادة توليدها. إذا لم يكن لديك الكثير من الرسومات في موقعك، فإن الصور المصغرة تأخذ مساحة ضئيلة. إذا كان موقعك غنيًا بالرسومات، إعادة توليد الصور المصغرة قد يستغرق أيامًا. بينما يتم إعادة توليد الصور المصغرة، سيتم تعطيل إشعارات البريد الإلكتروني. في كلتا الحالتين، لا معنى لإهمال الصور المصغرة من النسخ الاحتياطية. -
لا تشمل الصور في النسخ الاحتياطية إذا كان لديك الكثير من الصور. هذا سيجعل النسخ الاحتياطية بطيئة وغير عملية. انسخها احتياطيًا بشكل منفصل. إذا قمت بنسخ الصور احتياطيًا بعد نسخة قاعدة البيانات الاحتياطية، ستكون نسخك الاحتياطية متسقة.
-
رتب لإرسال النسخ الاحتياطية إلى مكان ما خارج الموقع.
هذه الصفحة تظهر كيفية إعداد نسخ احتياطية لقاعدة البيانات إلى S3 أو شيء مثل S3:
النسخ الاحتياطي مع restic
قم بتكوين discourse لعمل نسخ احتياطية إلى نظام الملفات، ثم انسخ من نظام الملفات إلى هدف نسخ احتياطي بعيد مع restic. إليك وصفة عينة.
# dnf install restic
# mkdir /var/restic
# mkdir /opt/backup
# cd /opt/backup
# cat > backup <<EOF
#!/usr/bin/bash
set -e
. /opt/backup/backup-config
restic --cache-dir=/var/restic \
backup \
/etc \
/root \
/var/discourse \
/opt/backup \
--exclude /var/discourse/shared/data/postgres_data
restic --cache-dir=/var/restic forget \
--prune --keep-hourly 24 --keep-daily 7 --keep-monthly 3
EOF
# chmod +x backup
ستختلف هذه التفاصيل اعتمادًا على مستودع restic المستهدف. لا تستخدم جميعها متغيرات البيئة الخاصة بـ AWS، لذا يرجى قراءة وثائق restic.
# cat > backup-config <<EOF
### تعتمد هذه التفاصيل على مستودع restic الذي تقوم بإعداده، لذا قم بتغييرها
export AWS_ACCESS_KEY_ID=yours-here
export AWS_SECRET_ACCESS_KEY=same
export RESTIC_PASSWORD_FILE=/root/restic-password
export RESTIC_REPOSITORY=see-the-restic-documentation
EOF
# {$EDITOR:-nano} /root/restic-password
ستحتاج إلى تخزين نسخة مما تضعه في /root/restic-password وإلا لن تتمكن من قراءة النسخ الاحتياطية! استخدم خزانة كلمات المرور الخاصة بك.
أخيرًا، أنشئ بعض الخدمات، قم بتهيئة مستودع restic، واعدد مؤقتًا لبدء عمليات النسخ الاحتياطي.
# cat > /etc/systemd/system/backup.service <<EOF
[Unit]
Description=Back up to remote target
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
StandardOutput=file:/var/log/backup.out
StandardError=file:/var/log/backup.err
WorkingDirectory=/var/discourse
ExecStart=/opt/backup/backup
[Install]
WantedBy=multi-user.target
EOF
# cat > /etc/systemd/system/backup.timer <<EOF
[Unit]
Description=Regular system backups
[Timer]
Persistent=true
OnCalendar=00/4:30:00
Unit=backup.service
[Install]
WantedBy=timers.target
EOF
# systemctl daemon-reload
# . /opt/backup/backup-config
# restic init
# /opt/backup/backup
# systemctl enable backup.timer
بعد هذه العملية، يجب أن تتمكن من رؤية أنك قمت بإنشاء النسخة الاحتياطية الأولية.
# restic snapshots
لقد استخدمت بنجاح نسخًا احتياطية من restic تم إنشاؤها بهذه الطريقة لنقل خادم Discourse من نظام إلى آخر باستخدام أمر restic restore.
النسخ الاحتياطي المتدفق لصور minio
كبديل لـ Restic، بينما يمكن تخزين نسخ قواعد البيانات الاحتياطية في S3، لا يوجد نسخ احتياطي للصور في S3 منفصل عن تقديم الصور من S3. بديل آخر هو استخدام minio-client لنسخ الصور إلى أي تخزين يشبه S3. يمكن أن تكون هذه العديد من الأهداف المشابهة لـ S3، بما في ذلك S3 و minio، ولكن ليس DigitalOcean Spaces لأنه مبنٍ على نظام ملفات Ceph الذي لا يطبق واجهة برمجة التطبيقات ListObjectsV2 بنفس الطريقة التي يفعلها S3.
في S3، أنشئ دلوًا (bucket) يحجب الوصول العام (الإذونات → حجب الوصول العام هي الطريقة السهلة للقيام بذلك بشكل صحيح في AWS).
قم بتثبيت minio-client (mc) بطريقة ما. إليك إحدى الطرق.
curl https://dl.min.io/client/mc/release/linux-amd64/mc > /usr/local/bin/mc && chmod +x /usr/local/bin/mc
قم بإعداد minio-client مع مستعرة (alias) تسمى backup باستخدام أمر يشبه هذا:
# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4
# mc mirror /var/discourse/shared/standalone/uploads backup/UPLOADS-BACKUP-BUCKET
ثم أنشئ خدمة /etc/systemd/system/backup-uploads.service على هذا النحو
[Unit]
Description=Neartime remote backup sync of discourse uploads
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=600
User=root
ExecStart=/usr/local/bin/mc mirror --overwrite -a --watch /var/discourse/shared/app/uploads backup/UPLOADS-BACKUP-BUCKET
[Install]
WantedBy=multi-user.target
لاحظ أن UPLOADS-BACKUP-BUCKET هنا يجب أن يكون دلوًا مختلفًا عن s3_backup_bucket الذي تقوم بإعداد Discourse لرفع نسخ احتياطية لقاعدة البيانات فيه. أيضًا، لاحظ أن المسار سيكون /var/discourse/shared/web_only/uploads إذا كنت تستخدم النشر متعدد الحاويات القياسي.
# systemctl enable backup-uploads
# systemctl start backup-uploads
# journalctl -fu backup-uploads
ارفع صورة اختبارية وتأكد من رؤية أسطر تشير إلى نجاح النسخ الاحتياطي للصور الأصلية والمُحسّنة. سيؤدي الضغط على Control-C إلى الخروج من وضع المتابعة في journalctl.
الاستعادة
لم أكن مضطرًا أبدًا لاختبار هذا الخطة حتى تاريخ كتابة هذا المقال. قد يغفل هذا الملخص عن شيء ما.
- استعادة جميع الملفات المحفوظة بشكل عام
- ابدأ nginx (الآن ستظهر صفحة الصيانة الخاصة بك)
- قم بنشر Discourse بشكل طبيعي باستخدام الملفات المستعادة في /var/discourse/containers
- قم بتثبيت minio-client في /usr/local/bin/mc إذا لم تقم باستعادته من النسخ الاحتياطية
- إذا لم تقم بحفظ
/root/mc، قم بإعداد مستعرة النسخ الاحتياطي# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4 # mc cp backup/UPLOADS-BACKUP-BUCKET /var/discourse/shared/app/uploads- استعد أحدث نسخة احتياطية لقاعدة البيانات؛ أنصحك بـ Restore a backup from the command line
- فقط بعد تأكيد أن الموقع يعمل، أعد إعداد النسخ الاحتياطي للرفع إلى S3 كما هو موثق أعلاه.
النسخ الاحتياطي المتدفق لـ postgresql
في المستقبل، قد أقوم بإنشاء واختبار وتقديم تكوين لتمكين استخدام الأرشفة المستمرة لـ WAL لنسخ احتياطية فورية تقريبًا لـ Postgres باستخدام minio-client عبر archive-command في postgresql، مشابهًا للنسخ الاحتياطي المتدفق للرفع.
مراقبة الأداء
هناك نهجان على الأقل لمراقبة الأداء.
حاوية Prometheus
قم بإعداد prometheus، وضع سجلات prometheus في /var/discourse/shared/prometheus إذا كنت تشغله على نفس النظام. يمكن أن تكبر ملفات Prometheus بشكل كبير، ولا تريد أن تمتلئ نظام الملفات الجذر؛ كما أنك على الأرجح تريد إحضارها معك إذا انتقلت إلى نظام مضيف جديد (إما الترقية إلى آلة افتراضية أكبر أو آلة افتراضية بنسخة أحدث من نظام التشغيل).
إذا قمت بنشر prometheus على نظام discourse (أو أي مكان آخر على الإنترنت العام)، قم بإعداد الأمان أمامه. عند التثبيت بهذه الطريقة، ستكون إحدى الخيارات هي تكوين nginx على هذا النحو:
location /prometheus/ {
auth_basic "Prometheus";
auth_basic_user_file /etc/nginx/prometheus-htpasswd;
proxy_pass http://localhost:9090/;
}
Sysstat
إذا كان Prometheus كثيرًا جدًا، فكر في استخدام sysstat بدلاً من ذلك.
dnf install sysstat(أوapt install sysstatعلى debian والمشتقات)systemctl enable --now sysstatsystemctl enable --now sysstat-collect.timersystemctl enable --now sysstat-summary.timersystemctl edit sysstat-collect.timerوقم بتغييرOnCalendar=*:00/10إلىOnCalendar=*:00/2- إذا كان /etc/default/sysstat موجودًا، قم بتغيير
falseإلىtrue
بعد ذلك، يمكن لأمر sar أن يخبرك عما إذا كنت تنفد من الموارد من حين لآخر.
موارد أخرى
إليك نقاشًا مكملًا (وأكثر إحكامًا) حول استخدام Discourse داخليًا كشكل أساسي من أشكال الاتصالات الداخلية.
لقد قمت بتغيير الإعدادات قبل إضافة Prometheus (التي تستخدم ذاكرة أكثر)، لذا قبل تغيير ذلك، سأقوم على الأرجح بنقل Prometheus بعيدًا عن هذا الخادم.
