استخدام تخزين كائنات متوافق مع S3 من Scaleway

مرحباً،

أحاول إعداد Discourse لاستخدام تخزين الكائنات المتوافق مع S3 من Scaleway، لكنني لا أستطيع جعله يعمل ولا أعرف أين تكمن المشكلة.

لقد تحققت من أن كلا الخزانين يعملان باستخدام aws-cli، وأن إعدادات CORS مضبوطة بشكل صحيح باتباع الوثائق الرسمية من Scaleway، لذا لا أعتقد أن المشكلة في الخزانين نفسيهما.

إليك إعدادات S3 الخاصة بـ Discourse (تم حذف جزء من اسم الخزان):

عند فتح علامة التبويب “النسخ الاحتياطي”، أرى الرسالة: “فشل في سرد النسخ الاحتياطية من S3: Aws::S3::Errors::BadRequest”.
وعند محاولة رفع صورة، أرى في السجل: “استثناء في المهمة: فشل في فتح اتصال TCP إلى [مخفي]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: الاسم أو الخدمة غير معروف)”.

أستخدم أحدث إصدار من Discourse - 2.4.0.beta10 (14ae574bc5).

أظن أنهم أقل توافقًا مع S3 مما يعتقدون؟

يبدو أن إعداد منطقة S3 يؤثر على الأمور هنا أيضًا.

هذا ممكن، لكن الرابط لا ينبغي أن يحتوي على amazonaws.com إذا قمت بإدخال نقطة النهاية - أليس كذلك؟

بالضبط، هذا غريب. ربما بسبب نطاق المستوى الأعلى العصري؟ دعني ألقي نظرة.

@dino حاول إزالة https:// من نقطة نهاية S3

التحقق لن يسمح لي بذلك: ‘s3_endpoint: القيمة لا تتطابق مع التنسيق المطلوب.’

نعم، كان ذلك تخمينًا خاطئًا.

لا أستطيع إيجاد طريقة لإنهاء الرابط بـ URL مثل الرابط الخاص بك من خلال قراءة الكود المسؤول عن ذلك:

هل يؤثر هذا فقط على النسخ الاحتياطية؟ هل تعمل عمليات الرفع؟

حسنًا، هذا يختلف عن المشكلة التي واجهتها مع سلات GCP، لكن قد ترغب في الاطلاع على Trouble with Google Bucket for backup - #4 by pfaffman.

تمكنت من تحديد أي ترقية لمكتبة aws-sdk-s3 تسببت في عدم عمل سلات GCP، رغم أن الحل الذي اختاره عميلي كان الانتقال إلى سلة AWS.

@Falco نعم، أنا محير أيضاً.
الخطأ مع عنوان URL الذي يحتوي على amazonaws خاص برفع الملفات، وليس بالنسخ الاحتياطية. بالنسبة للنسخ الاحتياطية، أحصل فقط على الخطأ العام، لذا أعتقد أن كليهما معطل بسبب مشكلة عنوان URL.

هل يمكنك التفكير في أي شيء آخر؟

@pfaffman شكراً للنصيحة - سأرى ما إذا كان تغيير إصدار الـ gem يساعد.

مرحبًا @dino، هل ساعد ذلك في النهاية؟ أعاني من نفس المشكلة هنا وأنا على وشك الاستسلام والتحول إلى Amazon S3.

مرحبًا @FroggyC،
في الواقع، لم يتبق لي وقت كافٍ لتصحيح هذا الخطأ، لذا لم أجرب تغيير إصدارات الجيم (gem) في النهاية. لقد انتقلت إلى استخدام Amazon S3 بناءً على الوثائق الرسمية، وعملت الأمور على الفور.
آسف لأن الأخبار ليست أفضل…

شكرًا لك. أظن أننا سنضطر إلى فعل الشيء نفسه. شكرًا لك!

نواجه نفس المشكلة. هل هناك أي شيء يمكننا فعله للمساعدة في استكشاف الخطأ وإصلاحه؟

على سبيل المثال، الوصول إلى الدلو عبر سطر الأوامر (CLI) وإرسال ملفات السجلات؟

هل يتم تجاهل s3_region، أليس كذلك؟ لأن Scaleway تستخدم قيمًا مختلفة مقارنة بـ AWS.

قد تحاول سؤال Scaleway — فعبء التوافق يقع على عاتقهم. إذا لم يكونوا متوافقين تمامًا مع AWS S3، فيجب عليهم إصلاح ذلك.

أنت توحي بأن الخطأ يقع على عاتقهم، ومع ذلك حتى الآن كنت تتجاهل تعليق @dino:

طالما أن عنوان URL لـ s3_endpoint (غير المُعدَّل) لا يُستخدم كما هو، فسيكون من الصعب إقناع Scaleway بأن الخطأ من جانبهم. خاصةً أن عملاء S3 الآخرين قادرين على الاتصال.

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

بالتأكيد، هذا ما كنت أعنيه بـ

إذن، كيف يمكنني إخبار discourse بتسجيل محاولات الاتصال بـ S3؟ بمجرد أن نعرف بالتأكيد العنوان URL الذي يريد الاتصال به، يمكنني اعتراض حركة المرور ومشاركة النتائج.

السبب في عدم عمل تحميل/نسخ احتياطي S3 هو المنطقة التي يجب تعيينها إلى fr-par (أو nl-ams)، وهو ما يمكن فعله فقط بتجاوز تحقق إعدادات الموقع في Discourse:

(عبر ./launcher enter app ثم rails c)

SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')

بعد هذا التغيير، تعمل عمليات التحميل والنسخ الاحتياطي على تخزين كائنات Scaleway.

وثائق Scaleway حول تخزين الكائنات

بطبيعة الحال، هذا حل مؤقت، وبمجرد إعادة تعيين أو تغيير إعداد الموقع هذا عبر لوحة المسؤول على الويب، لا يمكنك إعادته إلى حالة عمل (إلا باستخدام وحدة تحكم Rails مرة أخرى).

أظن أن عميل AWS/S3 يسمح جميعه بتعيين سلسلة منطقة صراحةً (عكس الحالة الحالية في لوحة المسؤول على الويب).

كما أن الأمر مضلل نوعًا ما في حالة قيمة القائمة المنسدلة “EU (Paris)” في Discourse، لأن هذا يشير إلى مخطط تسمية AWS eu-west-3 (أو ما شابه ذلك) وليس القيمة المتوقعة لـ Scaleway.

أهلاً. هل نحتاج إلى حقل إعدادات موقع خاص بـ “منطقة متوافقة مع S3” @falco؟ هذا سيسمح للمستخدمين بإدخال مناطق عشوائية تماماً (وبالتالي “مُخترعة” من منظور أمازون).

لا حاجة لذلك.

يجب على المستخدمين في نسخ S3 المستنسخة تعيين متغير البيئة S3 Endpoint، والذي يحل محل منطقة S3.

لدي دليل كامل يشرح ذلك باستخدام Digital Ocean S3 Clone، لكنني أنتظر حتى تقوم Digital Ocean بإصلاح خلل في CDN الخاص بـ S3 قبل نشره.

إذا كانت Scaleway في حالة أفضل من Digital Ocean، أعتقد أنني سأجربها وسأحاول بناء دليلي بناءً عليها.

صحيح، لكن كيف يعلمون أن عليهم فعل ذلك؟ هل يذكر وصف إعداد الموقع الحالي هذا؟ أعتقد أنه يجب أن يذكره. هل يمكنك جعل ذلك ممكنًا؟