لقد قام القائمون على صيانة AWS SDK بكسر التوافق. الأمر متروك لموفر استنساخ S3 الخاص بك لكي يواكب التطورات وينفذ توافقًا أفضل حتى تتمكن من إزالة الحلول البديلة.
4 إعجابات
فقط لتوضيح الأمر، هذا يؤثر فقط على ملفات JS/map/CSS في الأصول، ولن يؤثر على التحميلات، أليس كذلك؟
أعني، هل سيسبب ذلك مشكلة في مسح الملفات المهجورة؟
بالمناسبة، أعتقد أن هذه المشكلة قد تؤثر على تحديث Discourse من خلال لوحة الإدارة.
في الواقع، فشلت عملية التحديث من خلال لوحة الإدارة بالنسبة لي، ولهذا قمت بإعادة البناء.
نعم، إنه للأصول فقط.
مهمة الـ rake هذه؟ لا.
لكن تغيير حزمة AWS SDK بأكملها قد يكون قد كسر ذلك أيضًا للأشخاص الذين لديهم استنساخات غير متوافقة.
إعجاب واحد (1)
{“translation”: “[اقتباس="Yt.w، المنشور: 22، الموضوع: 354217"]
ولن يؤثر على التحميلات، أليس كذلك؟\n[/ اقتباس ]\n
أنا متأكد إلى حد كبير أن هذا خطأ. لذلك ربما نحتاج إلى إيقاف تنظيف التحميلات أيضًا. ذلك سيسبب فقط أخطاء عند تشغيلك، لكنه لن يمنعك من إعادة البناء.\n\n[اقتباس="Falco، المنشور: 23، الموضوع: 354217، اسم المستخدم: Falco"]
لكن تغيير حزمة AWS SDK ربما أوقف ذلك أيضًا للأشخاص على النسخ غير المتوافقة.\n[/ اقتباس ]\n
يبدو ذلك محتملًا. ربما نحتاج إلى إعداد “skip_s3_delete” لحل هذه المشكلة حتى تلحق مقدمو الخدمة الآخرون بالتحديث؟ وربما نضبطها تلقائيًا للمقدّمين الذين نعلم أنهم معطّلون؟\n\nهل تلك المهمة في rake هي الطريقة الوحيدة لإزالة الأصول المنتهية صلاحيتها؟”}
أتساءل فقط، لماذا لا تضيف خيارًا للاحتفاظ بالأصول على خادم Discourse الأساسي (أعني، دون تخزينها على S3)؟
طالما أن ذلك لا يؤثر على التحميلات أو عملية مسح الملفات اليتيمة، يبدو أنه حل قابل للتطبيق.
نعم. ليس الأمر وكأن هذا يمثل مشكلة كبيرة. المواقع العادية التي يتم تحديثها بين الحين والآخر لن ترى فرقًا كبيرًا.
يمكن للأشخاص إعداد قواعد دورة حياتهم الخاصة إذا كانوا يهتمون بهذه الأمور.
أليس إعداد clean up uploads = false هو ذلك بالفعل؟
هاها لا. يدعم Discourse رسميًا S3. بينما بذلت قصارى جهدي لبدء تكوين موفر تخزين كائنات متوافق مع S3 لتحميل الملفات و إضافة بعض التبديلات لزيادة توافق النسخ المتماثلة، ليس لدينا أي خطط لاستثمار المزيد من الوقت في ذلك اليوم.
إذا أراد المجتمع إرسال بضعة طلبات سحب (PRs) تزيد من التوافق وهي معطلة افتراضيًا، فهذا #pr-welcome، ولكن لا تتوقع رؤية دعم رسمي في النواة لكل نسخة متماثلة في أي وقت قريب.
4 إعجابات
على أي حال، يبدو أن Digital Ocean لا تواجه أي مشكلة في حذف النسخ الاحتياطية أو انتهاء صلاحية الأصول المفقودة.
بالنسبة لمقدمي الخدمة المعطلين، سيستغرق الأمر وقتًا طويلاً قبل أن تسبب الأصول غير الضرورية مشكلة كبيرة. قد تكون الاحتفاظ بمجموعة كبيرة من النسخ الاحتياطية، بما في ذلك قاعدة بيانات ضخمة وجميع التحميلات، مشكلة كبيرة إذا كنت تدفع مقابل التخزين.
إعجاب واحد (1)
مرحباً - أنا بات باترسون، كبير مسؤولي التبشير التقني في Backblaze؛ لقد وصلت إلى هذا الموضوع لأن لدي منتدى Discourse مُستضاف ذاتيًا لإثبات المفهوم، وقد صادفت هذه المشكلة بالضبط اليوم أثناء تكوين منتدى الخاص بي لاستخدام Backblaze B2 للنسخ الاحتياطي والتحميلات.
يُعد تعيين AWS_REQUEST_CHECKSUM_CALCULATION و AWS_RESPONSE_CHECKSUM_CALCULATION إلى WHEN_REQUIRED حلاً بديلاً مفيدًا للحالات الأساسية لتحميل وتنزيل الملفات، ولكن من المفيد معرفة أنه لا يغطي عددًا من السيناريوهات، بما في ذلك:
- حذف الملفات - يستخدم Discourse عملية S3
DeleteObjectsلحذف ملفات متعددة في استدعاء API واحد، كما ينبغي. - تحميل الملفات إلى مستودعات تم تمكين قفل الكائنات فيها.
المشكلة هي أن المجموع الاختباري (إما رأس Content-MD5 أو أحد رؤوس المجموع الاختباري الجديدة) مطلوب (بدلاً من مجرد مدعوم) لهذه العمليات، وهذا يتسبب في قيام حزم AWS SDK الحالية بتوفير رأس المجموع الاختباري الجديد. على حد علمي، لا توجد طريقة لتجاوز ذلك وجعل SDK يوفر Content-MD5 كما كان يفعل في السابق.
يعمل مهندسونا على حل كل هذا؛ في هذه الأثناء، أفضل تخفيف هو استخدام الإصدار 1.177.0 أو أقدم من gem aws-sdk-s3.
لقد حاولت تخفيض إصدارات حزمة AWS SDK في نشر PoC الخاص بي عن طريق تحرير Gemfile واستبدال
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
بـ
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false
لكن خبرتي في bundle ليست قوية، ولم أنجح إلا في كسر النشر الخاص بي مع الخطأ:
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)
Sidekiq.logger = Logger.new(nil)
^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...
أعتقد أنني فاتني خطوة حيوية.
دون الرغبة في التقليل من شأن أصدقائنا في DO، فقد فعلوا ذلك عن طريق تحديث خدمتهم لتجاهل رؤوس المجموع الاختباري الجديدة ببساطة بدلاً من رفض استدعاء API بسبب المجموع الاختباري غير المدعوم.
تقرير الحادث الخاص بهم يقول:
لاحظ أن Spaces لا تتحقق حاليًا من مجاميع التحقق من سلامة البيانات التي ترسلها AWS CLI و AWS SDK كجزء من طلبات التحميل
قررنا أن مجرد قبول وتخزين البيانات التي قد لا تتطابق مع المجموع الاختباري الذي قدمه عميل API كان أمرًا سيئًا.
9 إعجابات
شكرا على النشر!
إعجابَين (2)
نعم، ومشرفو AWS SDK يعطوننا التجاهل التام بشأن هذا الأمر
إعجابَين (2)
يسعدني أن فريق B2 قد لاحظ هذه المشكلة أيضًا.
إليك حلي المؤقت:
لقد علقت جميع التكوينات المتعلقة بـ S3 في app.yml وأعدت بناء Discourse بنجاح. هذا لا يؤثر على الوصول إلى الملفات التي تم تحميلها مسبقًا على موقعي، وسيتم تخزين أي مرفقات تم تحميلها خلال هذه الفترة محليًا دون التسبب في أي مشاكل.
بالمناسبة، ما زلت أتساءل، لماذا لا تضيف خيارًا للاحتفاظ بالأصول على خادم Discourse الأساسي (أعني، دون تخزينها على S3؟
؟؟؟
هذه هي طريقة عمل Discourse بشكل افتراضي، تحتاج إلى الاشتراك صراحةً في شحن الأصول إلى خدمة تخزين الكائنات.
أعني، قد يكون من الجيد أن يكون لديك خيار للاحتفاظ بأصول Discourse الأساسية (JS، CSS، إلخ) على الخادم المحلي. في الوقت نفسه، سيتم تخزين الملفات التي تم تحميلها بواسطة المستخدم فقط في S3.
إعجاب واحد (1)
يمكنك القيام بذلك عن طريق عدم تمكين “use_s3”، ولكنها صغيرة، سأقوم فقط بدفعها وعدم القلق بشأن المساحة الضائعة.
إعجاب واحد (1)
من فضلك ساعدني على الفهم بشكل صحيح.
هل تقصد تعيين DISCOURSE_USE_S3: false في app.yml؟
أود القيام بذلك لأن خادم Discourse الخاص بي موجود في آسيا، و B2 لديه خوادم في الولايات المتحدة فقط.
أيضًا، هذه المرة، تتعلق مشكلة AWS SDK بإدارة الأصول، أليس كذلك؟
لذا إذا قمت بتخزين الأصول على الخادم المحلي، فقد تتجنب المشكلة (إذا فهمت الموقف بشكل صحيح).
تتعلق المشكلة بـ إزالة الأصول من S3. إذا قمت بإزالة السطر الذي يحاول إزالة الأصول غير المستخدمة فقط، فسيعمل الأمر حاليًا. ويبدو أن المشكلة سيتم حلها قريبًا. هذا هو الحل الأسهل. هذا ما أوصي به. هذه أفضل إجابة مجانية لدي.
إعجاب واحد (1)
شكراً لك، هذا مفيد جداً لي!
إعجاب واحد (1)
هذا لأنه، في تعريف S3 API، فإن عملية DeleteObjects لديها httpChecksum.requestChecksumRequired مضبوطة على true، على عكس، على سبيل المثال، PutObject، والتي تضبطها على false. لذلك فإن SDK يلتزم بـ WHEN_REQUIRED، لأن المجموع الاختباري مطلوب.
يتم الآن إنشاء جميع SDKs الخاصة بـ AWS من تعريف API، مع الحد الأدنى من التعليمات البرمجية الإضافية لتغطية المواقف الحافة. ترى التعليمات البرمجية أن DeleteObjects تتطلب مجموعًا اختباريًا، والطريقة للقيام بذلك الآن هي استخدام أحد المجموعات الاختبارية الجديدة، بدلاً من Content-MD5.
للأسف، لم تر AWS ما يكفي من الأسباب لتوفير تكوين “استخدام Content-MD5 كما كنت تفعل من قبل”. إنهم لا يأخذون في الاعتبار نظام تخزين الكائنات الخارجي عند إجراء تغييرات كهذه، لأنهم لا يحتاجون حقًا إلى ذلك. الوقت الوحيد الذي يتم فيه إصلاح مثل هذه الأمور هو عندما تتسبب عن طريق الخطأ في إلحاق الضرر بأحد خدماتهم الخاصة في بعض الحالات الهامشية.
3 إعجابات
ليس من المفيد بشكل خاص إذا كنت في آسيا، ولكن للتسجيل، لدينا أيضًا مراكز بيانات في أوروبا (أمستردام، هولندا) ومنذ بداية هذا العام، كندا (تورنتو).
لا يمكنني تقديم أي وعود، لكننا بالتأكيد ننظر في موقع في آسيا.
أيضًا، إذا كنت تستخدم شبكة توصيل المحتوى (CDN)، فلا يهم كثيرًا مكان وجود الخادم الأصلي.
3 إعجابات
أنت على حق!
Backblaze لا يدعم x-amz-checksum-crc32، وقد يكون إصدار SDK الأحدث من Discourse قد مكّن هذا افتراضيًا.
لذلك ذهبت إلى التطبيق:
> ./launcher enter app
وقمت بإلغاء تثبيت الإصدار الحالي من AWS SDK:
> gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
وقمت بتثبيت الإصدار الذي قال موظف Backblaze إنه سيعمل:
> gem install aws-sdk-core -v "~> 3.215.1"
> gem install aws-sdk-kms -v "~> 1.96.0"
> gem install aws-sdk-s3 -v "~> 1.177.0"
ثم قمت بإعادة بناء التطبيق وعمل بشكل جيد!
إعجابَين (2)