لقد قمت بتغيير الاسم لأنني لا أستطيع إيقاف الخادم الأصلي لعدة ساعات، حتى أختبر أن كل شيء يعمل بشكل صحيح وأقوم بتبديل الخوادم.
لا تحتاج إلى ذلك. إذا كان لديك شهادة برمز نطاقي واسع (wildcard)، فيمكنك ببساطة إجراء تغييرات DNS محلية عبر ملف Hosts لتكوين كل شيء واستعادة النسخة الاحتياطية نفسها.
ثم تقوم فقط بتحويل DNS علنًا.
لا أفهم ما تقصده.
يجب أن أبقى a.domain.com قيد التشغيل أثناء إجراء الاختبارات.
وأحتاج إلى الوصول إلى واجهة Discourse للنسخة التي أقوم باستعادتها للتأكد من أن كل شيء على ما يرام.
لذا أحتاج إلى عنوان URL آخر للوصول إلى النسخة على الخادم الآخر.
لذلك أقوم ببساطة بتغيير اسم المضيف في Discourse و nginx بعد الاستعادة.
عندما يكون كل شيء على ما يرام، أقوم بتغيير الاسم في الخادم الجديد إلى a.domain.com، وأغلق الخادم القديم، وأوجه سجل DNS لـ a.domain.com إلى الخادم الجديد.
ما ورد أعلاه غير صحيح. يمكنك إجبار جهازك المحلي على الاتصال بالخادم الجديد باستخدام نفس اسم DNS، إما عن طريق تعديل ملف HOSTS على جهازك المحلي، أو بتعيين إدخال ثابت في DNS المحلي الخاص بك.
ليس لدي جهاز محلي.
كلا الخادمين موجودان على الإنترنت أو على خوادم سحابية.
أستخدم SSH من جهاز ويندوز.
ربما يمكنني أخذ اسم المضيف المحلي لضبط عنوان IP للجهاز، لكن هذا أكثر تعقيدًا من تغيير الاسم في الخوادم.
هل تعتقد أن تغيير اسم المضيف قد يكون هو المشكلة؟
لا ينبغي أن يكون ذلك مشكلة…
نعم، بدأنا نلاحظ مشكلة الصورة الرمزية المخصصة مرة أخرى بعد فترة طويلة من إتاحة وقت لعملية sidekiq لإعادة بناء أي صورة رمزية مرفقة وصور الملف الشخصي، ولكن فقط في التكوين الذي يستخدم nginx كوكيل عكسي إلى منفذ يونكس.
الصور الرمزية الصغيرة تعمل بشكل جيد؛ لكنها لا تعمل في بطاقة الملف الشخصي أو في صفحات الملف الشخصي (إلا إذا كانت مخزنة مؤقتًا مسبقًا ولم تنتهِ صلاحية التخزين المؤقت).
بمجرد القيام بما يلي:
nginx -s stop; ./launcher start web-only
تختفي مشكلة صور الرموز المخصصة (في الصور التي لم يتم عرضها مسبقًا / تخزينها مؤقتًا في المتصفح).
وبمجرد القيام بما يلي بعد ذلك:
./launcher stop web-only; nginx
تعود مشكلة صور الرموز المخصصة للصور التي لم يتم عرضها بعد / تخزينها مؤقتًا.
لا توجد أخطاء تتعلق بـ HTTPS، وهذا بالتأكيد ليس بسبب force_https (غير مرتبط تمامًا):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
لقد تأكدنا من هذه المشكلة على الأجهزة المحمولة (iOS، الإصدار الأحدث)، وعلى سطح المكتب، في Chrome (الأحدث)، وSafari (الأحدث)، إلخ.
هناك شيء غريب يحدث عند استخدام nginx كوكيل عكسي إلى منفذ يونكس، مما يؤثر على صور الرموز المخصصة.
حتى الآن، ونعتذر عن إخبارك يا @ariznaf، لم نتمكن من عزل المشكلة ولا نملك حلاً لها.
يبدو “كأن” التكوين الذي يستخدم nginx كوكيل عكسي إلى منفذ يونكس لا تقوم فيه تطبيق discourse (الحاوية) بإعادة بناء صور الرموز المخصصة هذه كما تفعل في التكوين الذي لا يستخدم nginx كوكيل عكسي إلى منفذ يونكس.
ربما لا يعجب sidekiq تكوين nginx كوكيل عكسي إلى منفذ يونكس ويرفض جدولة أو تشغيل عملية إعادة البناء هذه، LOL؟ @riking؟
غريب.
إليك متابعة:
في إعدادات وكيل العكس (reverse proxy) باستخدام منافذ يونكس (unix sockets) التي نناقشها:
ومع ذلك، عند التحقق من force_https:
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
وبالطبع، كما هو متوقع، لا توجد أخطاء في شهادة المتصفح (متصفح كروم يعمل بسلاسة):
لذلك، تخميني غير المتخصص هو أن إعداد force_https أو طريقتة تفتقر إلى هذه الصور في هذا التكوين؛ لأن كل شيء آخر سليم باستثناء هذه الصور الرمزية المخصصة (وصورة صفحة الملف الشخصي).
هذا هو تخميني الذي يفوق درجتي الوظيفية فيما يتعلق بـ discourse.
تحديث:
بعد مزيد من البحث، اتضح أن جميع إعداداتنا لـ nginx reverse proxy to unix socket كانت تفتقر إلى جزء كبير من ملفات /shared/uploads. كانت هذه الخطوة مفقودة من الدروس التوجيهية والوثائق التعليمية المختلفة التي قرأتها حول هذا الموضوع، لذا في المرة القادمة التي أرى فيها ويكيًا حول هذا الموضوع على meta، سأقوم بتحديث الدليل التوجيهي / الويكي / الدليل التعليمي ليشمل هذه الخطوة.
المشكلة الصغيرة المتبقية الوحيدة هي مشكلة تتعلق بأيقونة الموقع (favicon):
إذا كان لدى أي شخص طريقة موصى بها لحل هذه المشكلة، فسيكون ذلك رائعًا. شكرًا!
أعد رفعها. هذا هو الحل الأسرع.
ينسى الناس عند استخدامهم لـ socket أنهم قاموا بتعطيل قالب HTTPS، لذا لا يعرف Discourse أنه خلف SSL ما لم يتم تمكين force_https يدويًا، ومن هنا جاء اقتراحي بالأمس.
بمجرد تمكين force_https، يمكنك إعادة رفع الأصول لتصحيح مساراتها.
لم أرد على أي من هذا لأنني افترضت أن نوعًا ما من نقل بيانات الخادم المعطوب (بدون استخدام ميزة النسخ الاحتياطي المدمجة) قد استبعد مجلد /uploads/ بالكامل، ولم يكن لدي أي فكرة عن كيفية شرح ذلك بطريقة تفهمها.
نعم… لقد اتبعنا هذا الدليل لإعداد عكسي للبروكسي باستخدام nginx، لكن هذا كان للإعداد المستقل ولم يذكر مجلد الـ uploads لأنه لم يكن ضروريًا للنقل في وضع الاستقلال:
كما اتبعنا هذا الدليل للحاويتين، والذي لم يذكر أيضًا استعادة قاعدة البيانات أو نقل أي مجلد تحميلات:
أعتقد أننا نستطيع فهم الأمور بسهولة. إليك التلميح الذي كنت تفتقده لمساعدتك في الشرح، للمرجع:
الدروس الرئيسية حول هذا الإعداد تغفل حقيقة أنه يجب عليك إما استعادة قاعدة البيانات، أو نقل ملفات الـ uploads يدويًا إلى الحاوية الجديدة لأننا لم ندرج ذلك.
وبالطبع، أصبح الأمر منطقيًا الآن بعد أن اكتشفناه بنسبة 100% بأنفسنا (مرة أخرى!) لأنه غير مذكور في الدروس. LOL
كل شيء سهل بعد أن تعرف على المشكلة.
ملاحظة جانبية: في الختام، شكرًا لكل من كتب مختلف الدروس. لقد كانت ذات فائدة كبيرة! نقدر ذلك كثيرًا. من جانبنا، اكتمل هذا الإعداد ولن نستخدم أي إعداد مستقل في أي مواقع Discourse في المستقبل. “الافتراضي” المعتاد لدينا سيكون حاويتين مع عكسي للبروكسي إلى منفذ Unix. هذا يعمل بشكل أفضل لتحديثات التبديل بين الحاويات في الوقت الفعلي مع وقت توقف شبه معدوم. أشياء رائعة!!
Discourse رائع!!
أحسنت يا Jeff @codinghorror وسام @sam! براهو!
من السهل نسبيًا جعل هذا يعمل، ولكن كما ذكرت سابقًا، لا نستخدم S3 وخدمات التخزين السحابي الأخرى؛ ونفضل إبقاء الأمور “بسيطة”، لذا فإن نسخنا الاحتياطية تُنقل فقط عبر rsync إلى تخزين خارجي. نحن نفضل هذا الأسلوب… فهو يقلل من شيء واحد آخر نحتاج إلى تصحيحه ويمكننا “العيش” بدون S3،
لا أعرف ما إذا كان هذا مفيدًا أم لا. لكن تحسين الصور يميل إلى الفشل إذا لم يتمكن المهمة التي تقوم بالتحسين من الوصول إلى خادمك عبر اسم نطاق الإنترنت الخاص به.
قد يفسر ذلك سبب عدم عمل هذا كما هو متوقع في إعداد وكيل عكسي أكثر تعقيدًا.
شكرًا لك، كين.
كنت أحاول (كما تعرف على الأرجح) بدائل أخرى لطريقة النسخ الاحتياطي القياسية عبر واجهة المستخدم في discourse.
وذلك لأنني واجهت مشاكل في كل مرة حاولت فيها استعادة نسخة احتياطية باستخدام الطريقة القياسية، مع الالتزام دائمًا بالإرشادات المقدمة في الدروس الرسمية على هذا الموقع.
على أي حال، لقد ذكرت في البداية أنني أقوم بهذه الاستعادة من نسخة احتياطية تم إنشاؤها باستخدام واجهة المستخدم والإجراء القياسي للنسخ الاحتياطي والإجراء الموصى به للاستعادة.
الفرق الوحيد مع التثبيت القياسي لـ discourse المستقل هو أننا نستخدم nginx كوكيل عكسي، متصل بـ discourse عبر منفذ (socket).
المشكلة الرئيسية التي واجهناها كانت تتعلق بالصور الرمزية (avatars)، التي بدت وكأنها فقدت واستُبدلت بصورة الملف الشخصي الافتراضية.
أخبرتني أنه يجب إعادة بنائها من خلال مهمة Sidekiq. لكن هذه المهمة تبدو وكأنها تنتهي فورًا عند تشغيلها بنجاح (حالة OK)، بينما تظل الصور الرمزية كما هي.
بما أن النسخ الاحتياطية مهمة جدًا بالنسبة لنا (من يمكنه تجاهلها؟)، سأقوم بإجراء المزيد من الاختبارات، مع الحرص الشديد على اتباع التعليمات ومحاولة تجربة أفكار أخرى طُرحت هنا.
نحن سعداء بـ discourse، ونعجب به كثيرًا. نحن فقط نحاول التأكد من أن لدينا إجراء استعادة قويًا، في حالة تعرضنا لهجوم من نوع ما (لقد تعرضنا لواحد مؤخرًا) أو لفشل في الخادم.
إذا أردت منا إجراء بعض الاختبارات لمحاولة حل هذه المشكلة أو تقديم بعض المعلومات، فسأكون سعيدًا ببذل قصارى جهدي وتوفير تلك المعلومات.
يبدو أن النظام لا يستطيع الوصول إلى صور الرموز المصغرة، وهذا مؤكد.
لكن بقية المنتدى يعمل بشكل صحيح، المسارات و SSL وكل شيء مُعدّ بشكل صحيح حسب ما أستطيع رؤيته.
لو كان هناك أي نوع من سوء التكوين، لما استطعت الوصول إلى منتدى Discourse ورؤية بقية المحتوى، بل كنت ستحصل على أخطاء 502 أو ما شابه.
@neounix
نستخدم S3 لأنها الطريقة الأبسط من واجهة المستخدم لعمل نسخ احتياطية خارج الموقع.
ربما لا تكون S3 الخيار الأفضل، لا أدري، وإلا فإن مكان حفظ النسخ الاحتياطية لا علاقة له بالمشكلة، إذ أن المشكلة ليست في عدم القدرة على الوصول إليها وإجراء الاستعادة.
عملية الاستعادة تتم بشكل صحيح.
@stephan
في ملف app.yml قمت بإسقاط قالب SSL وقالب Let’s Encrypt، وقسم expose مع المنافذ.
جزء SSL يتم عبر nginx، لذا لا أحتاج إلى تشفير المقبس، أليس كذلك؟
هل هذا غير صحيح؟ هل يجب أن أستخدم قالب SSL على أي حال؟
أفترض أنه لو كانت هذه هي المشكلة، لما استطعت رؤية أي جزء من المنتدى بعد الاستعادة، وليس فقط الرموز، لكن من يدري…
سأجري المزيد من الاختبارات. شكرًا لكم جميعًا على مساعدتكم.
@ariznaf … مرحبًا!
الطريقة التي حللت بها هذه المشكلة على خادومين مختلفين كانت بنسخ مجلد /shared/uploads يدويًا من الإعداد الأصلي إلى إعدادات socket-only، وبعد ذلك اختفت هذه المشكلة.
الطريقة التي تمكنت من خلالها بسرعة من التحقق كانت بمقارنة أحجام مجلد uploads، ببساطة كما يلي (بافتراض أنك في المجلد المشترك):
du -sh uploads
عندما قمت بالمقارنة، عندها اكتشفت ما كانت المشكلة
ربما يمكنك التحقق أيضًا؟ آمل أن يساعدك هذا في عزل مشكلتك.
ملاحظة: لست ضد S3. لكلٍ ما يناسبه كما يقول المثل…
دعني أتحقق مما إذا كنت أفهمك بشكل صحيح.
عند إجراء النسخ الاحتياطية، قمت بالتحقق من حفظ ملفات التحميل أيضًا (ليس الصور المصغرة، لكنني جربت حفظ الصور المصغرة أيضًا، والآن أحفظ الصور المصغرة حتى لا تضطر للانتظار لإعادة المعالجة).
بعد الاستعادة، يتم استعادة ملفات التحميل أيضًا.
هل تقصد أن استعادة ملفات التحميل غير صحيحة ويجب عليك القيام بذلك يدويًا؟
كيف تستعيد ملفات التحميل يدويًا؟
هل قمت بتنزيل النسخ الاحتياطي، وفك ضغط مجلد uploads المشترك/المستقل؟
إذا كان الأمر كذلك (سأجرب)، يبدو لي واضحًا أن هناك نوعًا من الخطأ في مهمة الاستعادة.
شكرًا لك.
أبحث عن بدائل لإجراء النسخ الاحتياطية وتخزينها، لكن فريق discourse يصرون على أن الطريقة الصحيحة الوحيدة للقيام بذلك هي استخدام النسخة الاحتياطية القياسية.
مرحبًا @ariznaf،
نحن لا نستعيد البيانات من واجهة الإدارة (نحن نقوم فقط بنسخ احتياطي من واجهة الويب، ولا نستعيد). بدلاً من ذلك، نقوم بنقل الملف عبر sftp إلى الحاوية (بما في ذلك الملفات المرفقة) ثم نستعيدها بهذه الطريقة:
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
ومع ذلك، عندما قمت بإنشاء تكوين جديد لـ nginx reverse proxy إلى unix socket في اليوم الآخر، لم أقم باستعادة قاعدة البيانات لأن قاعدة البيانات كانت موجودة بالفعل في حاوية data (كما ذكرت مواضيع الشروحات).
لهذا السبب كان عليّ نسخ الملفات المرفقة يدويًا إلى الحاوية الجديدة.
يبدو أن وضعك يختلف عن وضعنا.
أتمنى أن يكون هذا مفيدًا.
شكرًا لك.
يبدو أنك تقوم بنفس الإجراء عبر سطر الأوامر الذي نقوم به عبر الواجهة: تفعيل الاستعادة والاستعادة من ملفات tgz التي تحتوي على قاعدة البيانات وملفات التحميل.
ولكنك تقول بعد ذلك أنه من أجل جعل الصور الرمزية تعمل (باستخدام المقابس وعكس الوكيل nginx)، تحتاج إلى استعادة ثانية لملفات التحميل فقط، أليس كذلك؟
مرحبًا @ariznaf … ليس تمامًا…
في البداية، كان لدينا تطبيق مستقل. قمت بفصل هذا التطبيق إلى حاويتين مختلفتين (واحدة للبيانات والأخرى للويب فقط)، ثم قمت بإجراء استعادة من ملف النسخ الاحتياطي الكبير الذي يحتوي على ملفات التحميل.
كل ذلك سار على ما يرام…
ثم، أنشأت حاوية جديدة، socket-only وقمت بتكوينها لاستخدام وكيل عكسي.
لم أقم بإجراء استعادة في حاوية socket-only الجديدة (لأن حاوية البيانات كانت تحتوي بالفعل على بيانات قاعدة البيانات سليمة)، لكنني فشلت في نسخ ملفات التحميل يدويًا (كان هذا خطئي). لو كنت قد قمت بعملية استعادة عادية، لما كان ذلك ضروريًا.
لكن لا يوجد سبب لإجراء استعادة يدوية لقاعدة البيانات مرة أخرى في الحاوية الجديدة، لأن هذا هو السبب في وجود البيانات في حاويتها الخاصة اللطيفة. لذا، في هذا الوضع، يجب نسخ ملفات التحميل إلى الحاوية الجديدة. في الواقع، تم ذلك بشكل أنيق.
هل هذا يساعد؟
ليس ما قلته. لقد قلت إن الواجهة الخلفية لا يمكنها الوصول إلى نفسها عبر nginx الأمامي. ما تقوله هو العكس.
من أجل تحسين عملية التحميل، تستدعي مهمة Sidekiq الملف باستخدام http(s).
لا، يمكنك تعطيل قالب SSL، لكن ستحتاج إلى تمكين force_https يدويًا.