تكوين موفر تخزين كائنات متوافق مع S3 للتحميلات

[Discourse]

يغطي هذا الموضوع كيفية تكوين بعض موفري تخزين الكائنات المتوافقين مع S3 الشائعين (نسخ S3). راجع Set up file and image uploads to S3 للحصول على تفاصيل أكثر حول تكوين Amazon AWS S3، والذي يُدعم رسميًا ويُستخدم داخليًا من قبل Discourse لخدمات الاستضافة الخاصة بنا.

المزود	اسم الخدمة	يعمل مع Discourse؟
Amazon AWS	S3	نعم
Digital Ocean	Spaces	نعم
Linode	تخزين الكائنات	نعم
Google Cloud	التخزين	نعم
Scaleway	تخزين الكائنات	نعم
Vultr	تخزين الكائنات	نعم
BackBlaze	التخزين السحابي	نعم*
مُستضاف ذاتيًا	MinIO	نعم
Azure Blob Storage	Flexify.IO	نعم
Oracle Cloud	تخزين الكائنات	لا [1]
Wasabi	تخزين الكائنات	ربما
Cloudflare	R2	لا
Contabo	تخزين الكائنات	لا

إذا نجحت في تشغيل خدمة مختلفة، يرجى إضافتها إلى هذه الموسوعة.

التكوين

لتخزين أصول Discourse الثابتة في تخزين الكائنات الخاص بك، أضف هذا التكوين في ملف app.yml الخاص بك تحت قسم hooks:

  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

عند استخدام تخزين الكائنات، ستحتاج أيضًا إلى شبكة توصيل محتوى (CDN) لتقديم ما يتم تخزينه في الدلو. استخدمت CDN من StackPath في اختباراتي، وبصرف النظر عن الحاجة إلى تعيين Dynamic Caching By Header: Accept-Encoding في تكوينهم، يعمل بشكل جيد.

DISCOURSE_CDN_URL هي شبكة توصيل محتوى تشير إلى اسم مضيف Discourse الخاص بك وتخزن الطلبات مؤقتًا. ستُستخدم بشكل أساسي للأصول القابلة للسحب: ملفات CSS وأصول السمات الأخرى.

DISCOURSE_S3_CDN_URL هي شبكة توصيل محتوى تشير إلى دلو تخزين الكائنات الخاص بك وتخزن الطلبات مؤقتًا. ستُستخدم بشكل أساسي للأصول القابلة للدفع: ملفات JS والصور وتحميلات المستخدمين.

نوصي بأن تكون هذه مختلفة وأن يقوم المشرفون بتعيينها جميعًا.

عدم استخدام شبكة توصيل محتوى (أو إدخال عنوان URL للدلو كعنوان URL لشبكة التوصيل) من المرجح أن يسبب مشاكل ولا يُدعم.

في الأمثلة التالية، https://falcoland-files-cdn.falco.dev هي شبكة توصيل محتوى مُعدة لتقديم الملفات تحت الدلو. تم تعيين اسم الدلو إلى falcoland-files في أمثلتي.

يُوصى بتكوين هذه الإعدادات في متغيرات البيئة في ملف app.yml الخاص بك لأن هذا هو الطريقة التي تفعلها CDCK في بنيتها التحتية، لذا فهي مُختبرة جيدًا. أيضًا، تحدث مهمة تحميل الأصول بعد تجميع الأصول، وهو ما يحدث أثناء إعادة البناء. إذا كنت ترغب في تشغيل Discourse يعمل بشكل صحيح مع تخزين الكائنات منذ البداية، فيجب عليك تعيين متغيرات البيئة بحيث يتم تحميل الأصول قبل بدء الموقع.

اختر مزود الخدمة من القائمة أدناه وأضف هذه الإعدادات إلى قسم env في ملف app.yml الخاص بك، مع تعديل القيم وفقًا لذلك:

AWS S3

ما ندعمه رسميًا ونستخدمه داخليًا. عرضهم لشبكة التوصيل Cloudfront يعمل أيضًا لتقديم ملفات الدلو. راجع Set up file and image uploads to S3 لمعرفة كيفية تعيين الأذونات بشكل صحيح.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-west-1
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Digital Ocean Spaces

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

تكوين مثال:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false 

Linode Object Storage

مطلوب معامل تكوين إضافي، HTTP_CONTINUE_TIMEOUT، لـ Linode.

تكوين مثال:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://us-east-1.linodeobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Google Cloud Platform Storage

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

بما أنه لا يمكنك سرد الملفات، فلن تتمكن من سرد النسخ الاحتياطية، وستفشل النسخ الاحتياطية التلقائية، لذا لا نوصي باستخدامها للنسخ الاحتياطية. ومع ذلك، يقترح البعض أنه إذا قمت بتغيير الدور من Storage Legacy Object Owner إلى Storage Legacy Bucket Owner، فإن النسخ الاحتياطية تعمل بشكل صحيح. راجع هذا الموضوع لمناقشة خاصة بـ Google Cloud.

هناك إضافة من طرف ثالث لتحسين التكامل على Discourse GCS Helper.

تكوين مثال:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east1
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  FORCE_S3_UPLOADS: 1
  DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  #DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  #DISCOURSE_BACKUP_LOCATION: s3

Scaleway Object Storage

عرض Scaleway جيد جدًا أيضًا، ويعمل كل شيء بشكل جيد في الغالب.

تدعم عمليات التحميل متعددة الأجزاء من Scaleway حدًا أقصى لـ 1,000 جزء. هذا لا يتطابق مع Amazon S3، الذي يدعم حدًا أقصى لـ 10,000 جزء. بالنسبة للمثيلات الأكبر، سيسبب هذا فشل نسخ Discourse الاحتياطية على Scaleway، وقد تحتاج إلى حذف يدوي للتحميل غير المكتمل قبل إجراء المزيد من المحاولات. بالنسبة للمثيلات الصغيرة، لا توجد مشكلة. يبدو أن Scaleway منفتحة جدًا على التعليقات، لذا إذا كنت تريد تغيير هذا الحد، فيجب عليك الاتصال بهم.

لاحظ أنه بالنسبة لمعامل DISCOURSE_S3_ENDPOINT، يستخدم Discourse نقطة نهاية المنطقة بأكملها: https://s3.{region}.scw.cloud. تأتي «نقطة نهاية الدلو» الموجودة في لوحة تحكم Scaleway الخاصة بك على شكل https://{bucketName}.s3.{region}.scw.cloud. حذف نطاق الدلو الفرعي لمنع أخطاء الاتصال.

تكوين مثال:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: fr-par
  DISCOURSE_S3_ENDPOINT: https://s3.fr-par.scw.cloud
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Vultr Object Storage

مطلوب معامل تكوين إضافي، HTTP_CONTINUE_TIMEOUT، لـ Vultr.

تكوين مثال:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://ewr1.vultrobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Backblaze B2 Cloud Storage

تحتاج إلى تخطي CORS وتكوينه يدويًا.

هناك تقارير بأن «تنظيف التحميلات اليتيمة» لا يعمل بشكل صحيح مع BackBlaze. يجب عليك تغيير قواعد دورة الحياة لدلو الخاص بك لكي يعمل تنظيف اليتيمة.

تكوين مثال:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: "us-west-002"
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY: false
  DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

ملاحظة: أثناء الهجرة الأولية إلى B2، قد تصل إلى حد المعاملات المجانية اليومية من الفئة C البالغ 2500. ستحتاج إلى إضافة طريقة دفع لإزالة القيود.

MinIO Storage Server

هناك بعض التحذيرات والمتطلبات التي يجب عليك التأكد من استيفائها قبل استخدام خادم تخزين MinIO كبديل لـ S3:

1. لديك خادم MinIO مُعد بالكامل
2. لديك دعم النطاقات مُمكّن في تكوين MinIO، لعناوين URL للدلاء القائمة على النطاقات. هذا شرط إعداد إلزامي لـ MinIO و Discourse، حيث لا يزال MinIO يدعم أنماط S3 «المسار» القديمة التي لم تعد مدعومة في Discourse.
3. لديك تكوين DNS مُعد بشكل صحيح لـ MinIO بحيث يتم حل نطاقات الدلاء الفرعية بشكل صحيح إلى خادم MinIO، ويتم تكوين خادم MinIO بنطاق أساسي (في هذه الحالة، minio.example.com)
4. الدلو discourse-data موجود على خادم MinIO ويتم تعيين سياسة «عامة» عليه
5. عنوان URL لشبكة التوصيل S3 الخاص بك يشير إلى شبكة توصيل محتوى مُعدة بشكل صحيح تشير إلى الدلو وتخزن الطلبات مؤقتًا، كما هو مذكور سابقًا في هذه الوثيقة.
6. تم تكوين شبكات التوصيل الخاصة بك لاستخدام فعليًا رأس «المضيف» لعنوان URL الأساسي لـ S3 - على سبيل المثال، discourse-data.minio.example.com عند جلب البيانات - وإلا فقد يسبب مشاكل CORB.

بافتراض استيفاء التحذيرات والمتطلبات المذكورة أعلاه، سيكون تكوين مثال شيئًا مثل هذا:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: anything
  DISCOURSE_S3_ENDPOINT: https://minio.example.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://discourse-data-cdn.example.com
  DISCOURSE_S3_BUCKET: discourse-data
  DISCOURSE_S3_BACKUP_BUCKET: discourse-backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false

سيظل CORS مُمكّنًا على MinIO حتى لو لم يتم تثبيت القاعدة بواسطة إعادة بناء التطبيق - على ما يبدو افتراضيًا، يتم تمكين CORS على جميع أفعال HTTP في MinIO، ولا يدعم MinIO BucketCORS (واجهة برمجة تطبيقات S3) نتيجة لذلك.

Azure Blob Storage مع Flexify.IO

Azure Blob Storage ليس خدمة متوافقة مع S3، لذا لا يمكن استخدامه مع Discourse. هناك إضافة، لكنها معطلة.

أسهل طريقة لعرض واجهة متوافقة مع S3 لـ Azure Blob Storage هي إضافة خادم Flexify.IO الذي يترجم بروتوكول تخزين Azure إلى S3.

حتى وقت كتابة هذه السطور، الخدمة مجانية على Azure، وتحتاج فقط إلى مستوى آلة افتراضية أساسي (رخيص) للبدء في تشغيلها. ومع ذلك، يتطلب ذلك بعض الإعداد.

1. في بوابة Azure، أنشئ موردًا جديدًا من Flexify.IO - Amazon S3 API for Azure Blob Storage.
2. للاستخدام الخفيف، يبدو أن تكوين VM الأدنى يعمل بشكل جيد. يمكنك قبول معظم تكوين الافتراضي. تذكر حفظ ملف مفتاح PEM عند إنشاء VM.
3. تصفح إلى رابط VM Flexify.IO، وأدخل النظام. اتبع التعليمات عن طريق إعداد مزود بيانات تخزين Azure Blob ونقطة نهاية S3 المُنشأة. تأكد من أن إعداد نقطة النهاية الوصول العام للقراءة إلى جميع الكائنات في الدلاء الافتراضية صحيح. انسخ عنوان URL ونقاط نهاية S3 والمفاتيح.
4. اضغط على New Virtual Bucket وأنشئ دلوًا افتراضيًا. يمكن أن يكون له نفس اسم حاوية Azure Blob Storage الخاصة بك، أو يمكن أن يكون اسمًا مختلفًا. قم بربط أي حاويات لدمجها في هذا الدلو الافتراضي. يُستخدم هذا الدلو الافتراضي لعرض دلو قابل للقراءة للعامة عبر S3.
5. افتراضيًا، يقوم Flexify.IO بتثبيت شهادة SSL موقعة ذاتيًا، بينما تتطلب نقطة نهاية S3 HTTPS. قم بتسجيل الدخول SSH إلى VM باستخدام ملف المفتاح (اسم المستخدم هو افتراضيًا azureuser)، واستبدل الملفات التالية بالملفات الصحيحة:

• /etc/flexify/ssl/cert.pem - استبدل بملف الشهادة (ترميز PEM)

• /etc/flexify/ssl/key.pem - استبدل بملف المفتاح الخاص (ترميز PKCS#8 PEM، وهو الذي يبدأ بـ BEGIN PRIVATE KEY وليس BEGIN RSA PRIVATE KEY الذي هو PKCS#1)

  هذه الملفات هي للجذر، لذا ستحتاج إلى sudo لاستبدالها. من الأفضل التأكد من أن ملفات الاستبدال لها نفس الملكية والصلاحيات مثل الملفات الأصلية، مما يعني root:root وصلاحيات 600.

6. افتراضيًا، ينشئ Flexify.IO خدمة S3 على مستوى الجذر مع دلاء متعددة. يتطلب Discourse دعم النطاقات الفرعية للدلاء. انتقل إلى: <your Flexify.IO VM IP>/flexify-io/manage/admin/engines/configs/1 والذي سيفتح صفحة تكوين مخفية!
7. حدد نطاق S3 الأساسي (قل إنه s3.mydomain.com) في حقل اسم المضيف لنقطة النهاية، والذي يجب أن يكون فارغًا افتراضيًا. اضغط على Save لحفظ الإعداد.
8. أعد تشغيل VM Flexify.IO في بوابة Azure.
9. في DNS الخاص بك، قم برسم s3.mydomain.com و *.s3.mydomain.com إلى عنوان IP الخاص بـ Flexify.IO VM.
10. في Discourse، قم بتعيين ما يلي في صفحة المسؤول (نعم، لا حاجة للإعدادات في app.yml):

use s3: true
s3 region: anything
s3 endpoint: https://s3.mydomain.com
s3 access key: myaccesskey
s3 secret assess key: mysecret key
s3 cdn url: https://<azure-blob-account>.blob.core.windows.net/<container>
s3 bucket: <virtual bucket>
s3 backup bucket: <backup bucket>  (أي حاوية ستفي بالغرض، حيث لا تتطلب وصول قراءة عامة وسيكشف Flexify.IO عنها تلقائيًا)
backup location: s3

لا يُنصح باستخدام نفس الدلو للإنتاج والاختبار. إذا قمت بذلك على أي حال، فاتخذ تدابير للتأكد من أن موقع الاختبار الخاص بك لا يحذف أصول الإنتاج (قم بتعيين s3 disable cleanup كحد أدنى، وانتبه لحذفه لنسخ الإنتاج الاحتياطية).

Wasabi

@pfaffman جرب Wasabi للنسخ الاحتياطية، لكنه بدا يفشل بين الحين والآخر بصمت، تاركًا النسخ الاحتياطية على القرص الصلب وملء القرص في النهاية. لم يكن لدى Wasabi ولا meta أي أدلة، لذا لا أنصح به، على الرغم من أن نتائجك قد تختلف. @pfaffman متأكد الآن إلى حد كبير أن هذه المشكلة كانت بسبب النسخ الاحتياطية وإعادة التشغيل التلقائية المجدولة في نفس الوقت بطريقة ما؛ كان يُستخدم فقط للنسخ الاحتياطية، لكنه بدا يعمل بشكل جيد. إذا أراد شخص ما تجربته والإبلاغ هنا، يجب أن يعمل، على الأقل للنسخ الاحتياطية.

Oracle Cloud

لا يدعم Oracle Cloud الوصول إلى الدلاء بأسلوب المضيف الافتراضي ولن يعمل

Cloudflare

عرض Cloudflare غير متوافق. في الاختبارات، قدم @fearlessfrog تذكرة إلى Cloudflare وفي ديسمبر 2022 قالوا:

الملفات التي تضغطها بـ gzip لا يتم التعامل معها بشكل صحيح حاليًا بواسطة R2. يجب عليك تحميل ملفات غير مضغوطة. لدى Cloudflare ضغط شفاف، يختارون الهوية، gzip، أو Brotli بناءً على ما يمكن للعميل التعامل معه. هذا فرق عن S3.

Contabo

حاول @tuxed جعل تخزين الكائنات من Contabo يعمل لتحميلات متوافقة مع S3. يبدو أنه عند التحميل، يتم إضافة بادئة لاسم المستودع في عنوان URL ولم يتمكن من جعله يعمل.

التحميلات الآمنة

التحميلات الآمنة مدعومة فقط لـ AWS S3. إذا فشل rake uploads:migrate_to_s3 الخاص بك، فيجب عليك إدخال هذه الأوامر أولاً للعد ثم تحديد تلك التحميلات على أنها غير آمنة، بافتراض أنك تعرف أنها لا تحتاج إلى أن تكون آمنة، وفي هذه الحالة، ستحتاج إلى استخدام AWS S3.

./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)

---

1. لا يدعم Oracle Cloud الوصول إلى الدلاء بأسلوب المضيف الافتراضي ولن يعمل ↩︎

[Richie (Richie Rich)]

مرحبًا بالجميع،

أستخدم تخزين S3 منذ عدة سنوات الآن بدون شبكة توصيل محتوى (CDN).

اتباعًا للنصيحة التي تلقّيتها في موضوع آخر، قمت اليوم بإعداد شبكة CloudFront CDN.

قبل أن أضيف عنوان URL الخاص بـ CDN إلى لوحة التحكم وأعيد معالجة أكثر من 230,000 منشور فقط لأكتشف أن إعدادًا خاطئًا في CloudFront قد يعطل كل شيء، هل يمكن لأحد تأكيد أن هذا هو السلوك المتوقع بالنسبة لي من فضلك؟

حاليًا، هذا مثال لعنوان URL لصورة قام أحد المستخدمين برفعها:

https://greyarrows.s3.dualstack.eu-west-2.amazonaws.com/original/3X/8/3/8335cab232f512f4a979c7f0c8562e149c01b212.png

والذي يعرض:

اسم النطاق الخاص بـ CloudFront هو: d1q8cepst0v8xp.cloudfront.net

إذا قمت بتعديل عنوان URL أعلاه يدويًا واستبدلت جزء S3 الحالي في اسم النطاق باسم نطاق CloudFront الخاص بي، أحصل على:

https://d1q8cepst0v8xp.cloudfront.net/original/3X/8/3/8335cab232f512f4a979c7f0c8562e149c01b212.png

وبالفعل، تظل الصورة تُحمّل بشكل صحيح:

لذلك، هل صحيح أنني أحتاج فقط إلى إضافة عنوان URL لـ S3 CDN وهو d1q8cepst0v8xp.cloudfront.net إلى لوحة تحكم Discourse، وإعادة معالجة جميع المنشورات، ثم الاسترخاء وانتظار حدوث السحر؟

شكرًا مسبقًا، فشبكة CDN جديدة تمامًا بالنسبة لي ولا أملك بيئة تطوير يمكنني فيها اختبار ذلك بأمان

[Richie (Richie Rich)]

لديّ أيضًا إعداد s3 configure tombstone policy مفعّل:

هل سيُشكّل هذا مشكلة؟ بما أنني أستخدم الآن شبكة توصيل محتوى (CDN) بدلاً من ذلك؟ أم أن العمليات في الخلفية لا تزال تفحص حزمة S3 الأصلية، وليس عنوان URL الخاص بشبكة CDN؟

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

[Richie (Richie Rich)]

@Richie

إذن، هل صحيح أنني بحاجة فقط إلى إضافة عنوان URL الخاص بـ S3 CDN وهو d1q8cepst0v8xp.cloudfront.net` إلى لوحة تحكم Discourse، وإعادة خبز جميع المنشورات، ثم الجلوس والانتظار حتى يحدث السحر؟

الإجابة هي نعم.

ولاختبار هذه الفرضية، قبل إعادة خبز مئات الآلاف من المنشورات، قمت بالتحققات المنطقية التالية:

• قمت برفع صورة
• غيّرت إعداد عنوان URL الخاص بـ S3 CDN
• أعيد بناء HTML في منشوري الاختباري (عبر واجهة المستخدم)
• حدّثت الصفحة في المتصفح
• تحققت من تبويب الشبكة في وحدة تحكم المتصفح للتأكد من أن الصورة يتم جلبها عبر Cloudfront
• قمت برفع صورة اختبارية جديدة إلى منشور جديد
• تحققت من تبويب الشبكة في وحدة تحكم المتصفح للتأكد من أن الصورة يتم جلبها عبر Cloudfront

أنا الآن أقوم بإعادة خبز جميع المنشورات في هذه اللحظة

[scottfsmith (Scott Smith)]

شكرًا لك على التقرير يا ريتشي. لقد كان لدي تخزين صور AWS S3 يعمل منذ عدة سنوات، ووصلت إلى هذا المنشور عبر رسالة وحدة التحكم. لكن الوصف في الأعلى لا يقول شيئًا عن الحالة التي يكون فيها لديك S3 بالفعل وتحتاج فقط إلى CDN.

للتوضيح، إليك ما قمت به:

1. ذهبت إلى وحدة تحكم AWS، وفي قسم الشبكة وتوصيل المحتوى، اخترت Cloudfront.
2. نقرت على زر إنشاء توزيع (Create distribution).
3. ملأت النموذج الواضح إلى حد كبير، والشيء الوحيد الذي تحتاج حقًا إلى فعله فيه هو اختيار حاوية AWS S3 الخاصة بك حيث توجد الصور من القائمة المنسدلة.
4. انتظرت قليلًا حتى ينتهي تكوين Cloudfront.
5. ظهر نطاق <gibberish>.cloudfront.net في عمود “اسم النطاق” في قائمة توزيعات Cloudfront.
6. قمت بنسخ ولصق ذلك النطاق في حقل s3 cdn url في إعدادات الملفات الخاصة بمسؤول موقعي.
7. أجريت بعض الاختبارات:
   أ. قمت بإنشاء منشور جديد مع رفع صورة، وكان موجودًا بالفعل على Cloudfront.
   ب. ضغطت على إعادة بناء HTML لبعض منشورات الصور الموجودة عشوائيًا ورأيت أنها أعيد بناؤها أيضًا بصور cloudfront.net.
8. بما أن كل شيء بدا جيدًا، دخلت ونفذت عملية إعادة خبز (rebake)، والتي استغرقت عدة ساعات لأن لدي الآن حوالي نصف مليون منشور:

./launcher enter app
# rake posts:rebake

9. يبدو أن كل شيء يعمل بشكل جيد. لقد وضع عددًا هائلاً من الوظائف في قائمة Sidekiq، واحدة لكل منشور على ما يبدو، والتي ستستغرق بضعة أيام لتنظيفها، لكنها تعمل حاليًا على معالجتها على دفعات.

[Falco]

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

[Falco]

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

[Falco]

هل من الممكن أن تكون قد فعّلت secure_uploads في إعدادات الموقع؟

يبدو أيضًا أن هذه المشكلة قد تم الإبلاغ عنها وإصلاحها اليوم بسبب توافقها مع Discourse:

Regression: dummy PutObjectACL now throwing 501 Not Implemented

fix: muxing order for rejected APIs (#12321)

[smlbiobot (SML)]

هل توجد طريقة لإيقاف ظهور هذا التنبيه في لوحة تحكم المسؤول؟

تم إعداد الخادم لرفع الملفات إلى S3، لكن لا يوجد CDN لـ S3 مُعد.

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

[tuanpembual (Estu Fardani)]

مرحباً.

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

كيف نفعل ذلك؟
فعّل الإعداد الافتراضي للنسخ الاحتياطي (أو يمكنك الإعداد من لوحة تحكم المسؤول).

DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
DISCOURSE_BACKUP_LOCATION: s3

ثم اضبط أذونات الدلو (Bucket) على Storage Legacy Object Owner:

1. انتقل إلى مشروعك في وحدة تحكم Google Cloud
2. اختر التخزين (Storage)
3. اختر الدلو (Bucket) الخاص بك
4. انتقل إلى علامة التبويب الأذونات (Permissions)
5. أضف إذنًا جديدًا، وأدخل بريد حساب الخدمة الخاص بك مع حسابك. بالنسبة للأدوار، اختر Storage Legacy Object Owner
6. احفظ وانتهى.

أعتذر عن النشر المزدوج، أردت فقط مشاركة هذا التحديث الجيد.
شكرًا لك

[tenzan (Askar)]

سيكون رائعًا لو أضفت Wasabi أيضًا…

[pfaffman (Jay Pfaffman)]

استخدمت Wasabi للنسخ الاحتياطي لفترة من الوقت. من حيث التكوين، كان “يعمل ببساطة”، لذا يمكنك تجربته إذا أردت.

لكن مع مرور الوقت، فشلت النسخ الاحتياطي بصمت وبقيت على الجهاز المحلي، مما أدى إلى امتلاء القرص. نظرت إلى أخطاء Wasabi و Discourse ولم أجد تفسيرًا يسمح لأي من الطرفين بـ “إصلاح” أي شيء.

لا أنصح به، لأنني لست متأكدًا من أنه “ممتاز”.

[tenzan (Askar)]

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

[pfaffman (Jay Pfaffman)]

كنت أقوم بنسخ احتياطي يومي؛ لا أتذكر كم عدد النسخ التي كنت أحاول الاحتفاظ بها، لكن القرص الصلب المحلي كان يحتوي على مساحة لنسخة أو اثنتين فقط.

[tenzan (Askar)]

أي خدمة تخزين تنصح بها شخصيًا؟
لا أعتقد أن AWS و Azure ميسورة التكلفة للمشاريع الشخصية.
لست متأكدًا بشأن Azure، لكن AWS تبدو مربكة وغير متوقعة…

[pfaffman (Jay Pfaffman)]

أملت أن يكون الـ wasabi جيدًا على الأقل للنسخ الاحتياطي. خدمة Backblaze S3 ميسورة التكلفة. لا أظن أنني استخدمتها للرفع، لكنها تعمل للنسخ الاحتياطي (أعتقد). أعتقد أن المشكلة الوحيدة مع Backblaze هي أنه (عندما اختبرتها آخر مرة) كان يتعين عليك استخدام مفتاح عالمي (لذا لم أستطع استخدامه مع العملاء الذين يمكنهم رؤية المفتاح). أعتقد أن شخصًا ما نشر مؤخرًا حلاً لذلك (شيء يتعلق بـ “قديم” أو ما شابه، في مكان ما). لمشروع شخصي، هذا ما سأجربه بعد ذلك، أعتقد. (وإذا كنت تستخدم Digital Ocean، فإن Spaces خيار جيد، أعتقد.)

[tenzan (Askar)]

أنا أستخدم DigitalOcean، لكن من حيث التكلفة، Blackblaze/Wasabi أرخص.
ما الذي استخدمته للرفع؟

[tenzan (Askar)]

عذراً، لم أستطع الفهم.
لماذا يجب تحديد الإعدادات في app.yml، بينما يمكننا إدخال هذه المعلومات من خلال Discourse → Settings؟

[pfaffman (Jay Pfaffman)]

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

[Zup]

@Falco

معلمة تكوين إضافية، HTTP_CONTINUE_TIMEOUT، مطلوبة لـ Vultr.

أين يجب أن أقوم بتعيين هذا؟ لم أجده في إعدادات إدارة Discourse؟