مشاكل في تسجيل الدخول إلى Patreon، فرض HTTPS، ومشكلات S3 CDN (ثلاثة)

تثبيت
1

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

قبل بضعة أيام، استخدمت هذا البرنامج التعليمي (How to Scale a Discourse Deployment with a Load Balancer and Managed Database Cluster | DigitalOcean) تقريبًا كلمة بكلمة وقمت بترحيل خادم Discourse المستقل الخاص بي على Digital Ocean إلى خادمين داخل موازن تحميل، حتى الآن كل شيء على ما يرام.

ثم اتبعت هذا البرنامج التعليمي (Configure an S3 compatible object storage provider for uploads)، ولكن بعد إعادة بناء Discourse من سطر الأوامر، كان موقع Discourse الخاص بي يعرض شاشة فارغة فقط. نظرت في Inspector في المتصفح لأجد أن المتصفح كان يمنع كل المحتوى الخاص بي لأنه كان يتم تقديمه من HTTP وليس HTTPS. هذا ربما لأن موازن التحميل ينهي SSL، لذا فإن كل شيء خارجي هو HTTPS، ولكن الخوادم نفسها تعمل على HTTP.

في هذه المرحلة، قمت بتعطيل خوادمي تمامًا مرة أخرى، محاولًا جعلها تعمل مع HTTPS داخل موازن التحميل، لكن ذلك لم يكن ممكنًا ببساطة. لم أتمكن من جعل Digital Ocean Space/CDN يعمل مع S3/CDN وفقًا لهذا البرنامج التعليمي (Configure an S3 compatible object storage provider for uploads). لقد مررت به بدقة وفحصت كل جانب عدة مرات، لكنه لم يعمل. الطريقة الوحيدة التي تمكنت بها من إعادة بناء Discourse كانت إزالة المعلمة DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com من app.yml، ولكن بعد ذلك، حتى لو تم بناؤه، لم أتمكن من جعل الخادم يستجيب. حصلت إما على خطأ 503 server not responding أو خطأ عادي في المتصفح server not responding أو server disconnected. لقد اختلف ذلك بناءً على إعدادات موازن التحميل و DO Space/CDN التي كنت أجربها. لقد جربت كل تركيبة ممكنة من الإعدادات ولم يُمكّنني أي منها من تقديم صفحة.

عندما تركت المعلمة DISCOURSE_S3_ENDPOINT في مكانها، حصلت على الخطأ التالي أثناء إعادة بناء Discourse، ولكنه اختفى عند التعليق على معلمة S3_ENDPOINT.
Aws::S3::Errors::InvalidAccessKeyId: Aws::S3::Errors::InvalidAccessKeyId

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

اليوم، استسلمت لمحاولة جعل المحاولة السابقة تعمل، واستعدت نسخة احتياطية من خوادمي التي كانت فقط موازنة تحميل مع HTTP فقط، وأخيرًا تمكنت من جعلها تعمل مرة أخرى عن طريق القيام بهذا البرنامج التعليمي (Set up file and image uploads to S3) ولكن هذه المرة قمت بتحرير إعدادات S3 عبر لوحة تحكم Discourse Admin بدلاً من تحرير app.yml بالإعدادات في البرنامج التعليمي الموصى به. لقد نجحت أخيرًا، ولكن الاختلاف المهم هو أنني تركت إعدادات S3 CDN عمدًا. لقد أكدت أن الصور التي تم تحميلها إلى المشاركات يتم تخزينها على S3 ويمكنني عمل نسخة احتياطية من Discourse مباشرة إلى S3، وهذا كل ما أريده حقًا، ولكن لدي الآن ثلاث مشكلات تطاردني، واحدة حرجة، واثنتان يمكن تجاهلهما، على الرغم من أنني أود التأكد من ذلك هنا إذا أمكن.

لذلك، المشكلة الحرجة هي أن المستخدمين لم يعودوا قادرين على تسجيل الدخول باستخدام زر تسجيل الدخول إلى Patreon على صفحة تسجيل الدخول إلى Discourse. يتم عرض هذه الرسالة:
Sorry, there was an error authorizing your account. Please try again.

عنوان URL هو هذا:
https://mbp.community/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fmbp.community%2Flogin&strategy=patreon

سأكون ممتنًا جدًا لبعض النصائح حول ما يمكنني تجربته لجعل هذا يعمل، ولكن مرة أخرى، أتساءل عما إذا كان هذا بسبب أن الخوادم داخليًا لا تعمل بنظام HTTPS. كما ترى من عنوان URL، خارجيًا هي تعمل بنظام HTTPS، لذا من الصعب التأكد. أعتقد أنني آمل أن يكون لدى شخص ما هنا خبرة في موازنة التحميل من Digital Ocean وما إلى ذلك مع Discourse.

المشكلتان الأخريان يتم الإشارة إليهما الآن في لوحة تحكم المسؤول على النحو التالي:

بعض النصائح بناءً على إعدادات موقعك الحالية

لذلك، لا أمانع في محاولة تشغيل force_https، ولكني قلق من أنه سيمنعني من الوصول إلى خادمي لأن الخوادم الداخلية التي يتم موازنة تحميلها لا تعمل بنظام HTTPS وبسبب المشاكل التي واجهتها بالأمس، أنا متردد في قضاء اثنتي عشرة ساعة أخرى أضرب رأسي في الحائط وأشاهد عمليات إعادة بناء لا حصر لها مدتها 15 دقيقة لـ Discourse دون جدوى. مرة أخرى، إذا عرف أي شخص أنه من الآمن تشغيل force_https مع تكويناتك، فيرجى إخباري.

والقضية الثانية، مرة أخرى، لم تسر بشكل جيد عبر المعلمات المضافة إلى ملف app.yml، لذلك أنا متردد في محاولة هذا مرة أخرى أيضًا. هل يمكنك تأكيد أن هذا سيفعل نفس الشيء مثل المعلمات المضافة إلى ملف app.yml؟ إذا كان الأمر كذلك، فسأتجاهل هذه الرسالة الثانية فقط. على العكس من ذلك، إذا كان من الآمن تجربته لسبب ما، فأخبرني وسأقوم بعمل نسخة احتياطية وأجربها.

آسف على المنشور الطويل. آمل أن تتمكن من معرفة ما أحاول الحصول على مشورة بشأنه.

إعجاب واحد (1)
2

إذًا، أنت بحاجة حقًا إلى المساعدة هناك لأن كل ما يتم دعمه هنا هو تثبيت قياسي.

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

أولاً، هل قمت بإعداد Redis خارجي كما هو موضح في الخطوة 5؟ إذا لم يكن الأمر كذلك، أتوقع أن تكون الأمور معطلة قليلاً على الأقل. هم يلمحون إلى أن استخدام “sticky” سيؤدي إلى “إصلاح” ذلك، ولكنه لن يصلحه حقًا. لذا يمكنك توقع أخطاء عشوائية يصعب تشخيصها. وهم لا يحددون طريقة للتأكد من أن جميع مثيلاتك تعمل بنفس الإصدار بالضبط من Discourse، وهذا أيضًا من المرجح أن يجعل الأمور معطلة.

كنت ترغب حقًا في فعل ذلك أولاً، وإلا، في الواقع، لا يمكن أن يعمل هذا الإعداد، لأن بعض التحميلات ستكون على خادم واحد وبعضها على خادم آخر، وهذه التعليمات لا تذكر كلمة “upload”، لذلك أتوقع أنه إذا كنت تستخدم هذا لأكثر من الاختبار، فقد تكون لديك فوضى في يديك وستحتاج إلى مزامنة التحميلات بين خوادمك المتعددة.

يذكر على وجه التحديد أن شبكة توصيل المحتوى (CDN) الخاصة بـ Digital Ocean لا تعمل مع Discourse.

هل استخدمت شبكة توصيل محتوى (CDN) مختلفة كما يوصي؟ Bunny.net سهلة وبسيطة جدًا في الإعداد.

إعجابَين (2)
3

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

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

نصيحتي لـ @Martin_Bailey هي ألا تتبع أي شيء هناك. سيؤدي ذلك فقط إلى تثبيت معطل، كما اكتشفت.

يرجى اتباع دليل التثبيت الرسمي الخاص بنا إذا كنت تريد تثبيتًا سريعًا وسليمًا لـ Discourse. الخروج عن هذا المسار يمكن أن يصبح بسرعة عملاً بدوام كامل.

3 إعجابات
4

مضحك. تركت تعليقًا هناك يوضح بعض المشكلات ويربط بمنشور رافائيل، لكن تم حذفه.

3 إعجابات
5

رائع! حسنًا، لقد اعتقدت أن الأمور سارت على ما يرام على الرغم من وجود بعض الأشياء التي لاحظت أنها غير صحيحة، ولكن لدي الآن تثبيت متوازن التحميل. بالطبع، أول شيء وجدته هو أن تحميل الصور كان معطلاً، ولهذا السبب استخدمت S3 لتخزين الصور.

كما هو الحال الآن، سيتطلب الأمر حمولة شاحنة أخرى من العمل للعودة إلى خادم واحد، فهل هناك أي شيء يمكنني فعله بشأن مشكلة تسجيل الدخول إلى Patreon؟ سأتجاهل المشكلتين الأخريين.

شكرًا لمساعدتكم على أي حال. أنتم تقومون بعمل رائع هنا.

6

مرحباً جاي، شكراً لمساعدتك. رداً على أسئلتك…

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

الشيء الآخر الذي اضطررت إلى اكتشافه، والذي أعاقني لفترة طويلة، هو أنني احتجت أيضًا إلى إضافة المعلمة أدناه إلى app.yml، وإلا فإن إعادة البناء استمرت في الفشل لأنها كانت تحاول الاتصال بـ Postgres على المنفذ الافتراضي، على الرغم من وجود المنفذ الفعلي في المعلمة DISCOURSE_DB.

DISCOURSE_DB_BACKUP_PORT: 25060

لم أفكر في التحميلات حتى بعد أن نجحت في كل شيء بناءً على البرنامج التعليمي الأول، وفي البداية أفسد كل شيء عندما حاولت إعداد S3، ولكن ذلك كان لأن إعدادات CDN الخاصة بـ DO Space التي تقدمونها هنا لا تعمل.

ينص صراحة على أن CDN الخاص بـ Digital Ocean لا يعمل مع Discourse.

أعلم، ولكن بعد ذلك يطلب منا البرنامج التعليمي إضافة هذا:
DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com

وهو يأتي من DO Space، أليس كذلك؟ ليس لدي أي فكرة بناءً على كل ما قرأته في هذه البرامج التعليمية عن كيفية العمل مع CDN مختلف، ولكنني لست قلقًا في هذه المرحلة، حيث سأتناول ذلك بعد قليل.

لا، لم أستخدم CDN مختلف. أنا في الواقع بخير مع عدم استخدام CDN. سأترك إعدادات CDN فارغة. كتحديث إضافي، بناءً على النصيحة التي قدمتموها لي بلطف حتى الآن، كنت سأعود ببساطة إلى نسختي الاحتياطية من الأسبوع الماضي، ولكنني قررت أن أجرب تمكين خيار force_https أولاً، وتمكين ذلك أصلح مشكلة تسجيل الدخول إلى Patreon، كما كنت أعتقد. لم يتم تغيير أي شيء على الخادم (الخوادم)، لذا ربما كانت مشكلة تسجيل الدخول إلى Patreon ناتجة عن بعض المنطق الداخلي لـ Discourse، على الرغم من أنني أدرك مرة أخرى (الآن) أنني أفعل شيئًا لا توصون به أو تدعمونه.

لذلك، في هذه المرحلة، إعدادي هو تقريبًا كما يوصي به البرنامج التعليمي الأول، ولكن الصور والنسخ الاحتياطية كلها تذهب إلى S3، بدون CDN. إنه يعمل بشكل جيد حقًا. أقدر أنك توصيني فقط باستخدام التثبيت المستقل، ولكن تعطيل الموقع لمدة 15 دقيقة في كل مرة يأتي فيها تحديث أمر مؤلم حقًا. بالأمس فقط وجدت إشاراتك إلى data.yml و web_only.yml لإعداد متعدد الخوادم، ولكن لم أتمكن من معرفة ما كان علي فعله، لذلك استسلمت.

سأستمر بما لدي في الوقت الحالي. شكراً لمساعدتك، ولكل ما تفعلونه.

7

حسناً يا رفاق، لقد فزتم. :slight_smile:

بدأت أرى المزيد من المشاكل مع عدم تحميل الصور مرة أخرى لأنها كانت تُشارك أحيانًا عبر http وليس https. أنتم على حق، إنها فوضى.

لقد تراجعت عن معظم هذا، وتركت قاعدة بيانات Postgres في مكانها ولكن عدت إلى خادم واحد فقط، بدون موازن تحميل، والصور/Redis مخزنة محليًا. لقد تركت S3 في مكانه لعمل نسخ احتياطية للموقع على الرغم من ذلك. أحب كيف يعمل ذلك بسلاسة.

لقد عدت إلى فترات انقطاع مدتها 15 دقيقة مع كل ترقية على ما أعتقد، لكنني قضيت ما مجموعه خمسة أيام كاملة على هذا حتى الآن، ولا يمكنني قضاء المزيد من الوقت عليه، لذا أنا سعيد لأنكم جميعًا تمكنتم من تصحيح مساري فيما يتعلق بهذا البرنامج التعليمي الأصلي الذي اتبعته. يبدو الأمر وكأنهم يريدون فقط أن يدفع الناس مقابل المزيد من Droplets. :slight_smile:

شكراً مرة أخرى على مساعدتكم.

8

في الواقع، إذا كان بإمكاني فقط أن أسأل، هل يوجد برنامج تعليمي لمساعدتنا في إعداد Discourse بطريقة تجعل من الممكن تجنب انقطاع الخدمة لمدة 15 دقيقة مع كل تحديث. لقد رأيت الملاحظة حول data.yml و web_only.yml ولكن ليس لدي أدنى فكرة عما أحتاج إلى القيام به لتحقيق ذلك.

9

إن وجود ملفات data و web_only منفصلة هو من إعداد الحاوية المزدوجة:

إعجاب واحد (1)
10

سيؤدي هذا إلى حل بعض المشاكل. وإذا حدث أن تم قفلك لسبب (آخر)، يمكنك دائمًا استخدام launcher enter app للعودة وتبديل إعداد الموقع مرة أخرى من وحدة تحكم Rails.

كما قال الآخرون بالفعل، من الأفضل اتباع دليل مختلف.

إعجاب واحد (1)
11

مرحباً يا رفاق،

لقد كتبت مقال DigitalOcean هذا، ويبدو أنني ارتكبت بعض الأخطاء، عذراً!

أود تحديث المقال لتصحيح المشكلات.

لذا، أود فقط طرح بعض الأسئلة للتأكد من أنني سأقوم بالأمور بشكل صحيح مع النسخة المصححة.

في المقال، ذكرت أنه يمكنك اختياريًا استخدام مثيل Redis مُدار، كان تفكيري في ذلك الوقت هو أن استخدام الجلسات الثابتة (sticky sessions) سيسمح لك باستخدام Redis المدمج في صورة Discourse. هل هذا صحيح؟ ربما هذا ليس كافيًا ويجب أن يكون مثيل Redis خارجي متطلبًا إلزاميًا.

أتفق مع تعليق @Falco بشأن تخزين الكائنات (Object Storage)، هذا سهو مني. يمكنني تحديث المقال لتضمين تعليمات لاستخدام مساحات DigitalOcean (DigitalOcean Spaces) للتعامل مع تحميلات الصور.

أعتقد أن إزالة كل الحالة من القطرات (Droplets) هي الحل لمشاكل التثبيت، كنت آمل أن يكون استخدام Redis خارجي اختياريًا بسبب الجلسات الثابتة ولكن قد أكون مخطئًا.

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

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

شكراً،
فرانسيس

12

أنا عميل سعيد لـ Digital Ocean ولدي لوحة تحكم يدخل إليها عملاؤي مفاتيح API واسم مضيف ثم يقومون تلقائيًا بإنشاء قطرة، وتكوين Mailgun، والانتظار حتى يتم إعداد سجلات DNS، ثم تثبيت Discourse.

لا يعمل على الإطلاق كما تقترح. اتصلت بـ Digital Ocean في منتداك (لم أتمكن من العثور على طريقة أخرى) لإعلامك وتم حذف رسالتي. ثم، بعد 9 أشهر، ترد هنا.

إن القيام بذلك بشكل صحيح هو مهمة معقدة للغاية، والحالات التي سيكون فيها مفيدًا بعيدة المنال إلى حد ما. لدي موقع به 100 ألف مشاهدة للصفحة يوميًا على قطرة بحجم 8 جيجابايت. من تعتقد أنه الجمهور المستهدف لهذا الدليل؟

نعم، تحتاج إلى Redis خارجي، و PostgreSQL، وحاويات S3 مع شبكة توصيل محتوى (CDN)، وشبكة توصيل المحتوى الخاصة بـ Digital Ocean لا تعمل، لذا سيحتاج دليلك إلى إرشادهم خلال إعداد شبكة توصيل محتوى لشركة أخرى. لا أعتقد أنك تريد القيام بذلك. وهذا فقط لإعداده. إذا أرادوا بعد ذلك إجراء ترقية، فستكون مجموعة أخرى من الإجراءات التي لن يعرف أي شخص آخر على هذا الكوكب كيفية المساعدة فيها.

أفضل شيء يمكنك القيام به هو حذف هذا الدليل تمامًا. إذا كنت تريد أن تكون بطلاً حقيقيًا، يمكنك إصلاح التثبيت بنقرة واحدة بحيث لا يستخدم البرنامج النصي الخاص بك لإعداد البريد الإلكتروني وما إلى ذلك، بحيث يكون تثبيتًا قياسيًا بالفعل. من المربك جدًا الاضطرار إلى الضغط على control-c للوصول إلى حيث يوجد Discourse، وبما أن الأشخاص الذين استخدموا التثبيت بنقرة واحدة لم يستخدموا أدوات Discourse القياسية، فهم لا يعرفون كيفية استخدامها عندما يحين وقت الترقية عبر سطر الأوامر. سيكون من الرائع جدًا جدًا إذا كان بإمكانك القيام بذلك.

هنا يمكنك رؤية الأشخاص الذين استخدموه وكانوا يواجهون مشكلة: Search results for 'digital ocean one-click' - Discourse Meta

إعجاب واحد (1)
13

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

سيؤدي ذلك إلى حل المشكلة، ولكن إضافة Redis مُدار، و PostgreSQL مُدار، وموازن تحميل مُدار، وتخزين الكائنات، وسجل الحاويات سيكون أيضًا أكثر تكلفة من مجرد الدفع مقابل استضافتنا القياسية وأكثر تعقيدًا في الصيانة.

عند تلك النقطة، فإن التقاطع بين الأشخاص الذين يرغبون في دفع مئات الدولارات شهريًا ولا يهتمون إذا تعطلت خدمتهم بسبب نقطة فشل واحدة (SPOF) صغير جدًا، ويصبح الأمر أشبه بإعداد هواة أكثر مما نوصي به لمسؤولي المنتديات.

إعجاب واحد (1)