مساعدة في تحويل SMF2 ونقل Rake إلى S3

لقد بحثت، لكن لم أتمكن من العثور على نظرة عامة أساسية حول كيفية نقل ملفاتي من DigitalOcean إلى S3. لقد قمت بإعداد S3 بنجاح للرفعات الجديدة والنسخ الاحتياطية قبل بضعة أشهر. وأود الآن إكمال نقل ملفاتي (حوالي 1.4 جيجابايت) إلى S3.

كان هذا تحويلًا من SMF2 منذ البداية. لدينا الآن مجلداان للرفعات، أحدهما في الجذر في smf2 والآخر في /var/discourse. يبلغ حجم دليل SMF2 2.8 جيجابايت. أفترض أنه قد تكون هناك خطوتان هنا؟ هل أحتاج إلى إجراء خطوات منفصلة للنقل من دليل SMF2 ومن دليل /var/discourse؟

لقد صادفت أمر rake to s3، لكنني لم أتمكن من العثور على دليل سوى مجموعة من الأشخاص يتحدثون عن الأخطاء التي واجهوها واقتراحات لتصحيحها. هل هناك دليل متاح؟

يرجى قراءة هذه المقالة، حيث يجب أن توجّهك حول كيفية إعداد المهمة

يجب أن تتحقق من قسم الإعدادات الخاص بـ hooks وتقوم بإعداد الدلو (bucket) باستخدام متغيرات البيئة لتجنب المشكلات التي قرأت عنها بالفعل.

هذا رائع! شكرًا لك!

الشيء الوحيد هناك الذي لا أعرف عنه هو شبكة توصيل المحتوى (CDN). أرى أنه يمكننا استخدام Amazon Cloudfront. أظن أنه لم يتم إعداده عند تنفيذ خطوات إعداد S3 السابقة. سأبحث عن دليل لكيفية إعداده.

يمكنك إعداد CloudFront باستخدام حزمة التحميلات الخاصة بك كمصدر، وبمجرد إعداده، يمكنك تعيينه كرابط CDN لـ S3. هذا كل ما يجب فعله.

شكرًا لك. لقد اتبعت هذا الفيديو لإعداد Cloudfront:

أقوم الآن بتشغيل أمر rake posts:rebake. بما أن هناك 84 ألف منشور، فسيتطلب الأمر بعض الوقت.

أوه أوه… أحاول تشغيله مرة أخرى…

root@discourse-app:/var/www/discourse# rake posts:rebake
إعادة معالجة تنسيق Markdown للمشاركات لـ ‘default’
10027 / 83358 ( 12.0%)/usr/local/bin/rake: line 2: 959 Killed RAILS_ENV=production sudo -H -E -u discourse bundle exec bin/rake “$@”

حدث مرة أخرى… هل لديك أي اقتراحات؟

root@discourse-app:/var/www/discourse# rake posts:rebake
إعادة بناء تنسيق Markdown للمشاركات لـ ‘default’
12901 / 83359 ( 15.5%)/usr/local/bin/rake: line 2: 2569 Killed RAILS_ENV=production sudo -H -E -u discourse bundle exec bin/rake “$@”

تسحب بعض المشاركات المحتوى الآن من Cloudfront، لذا على الأقل هذا يعمل بشكل ما.

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

حسنًا، تم إعادة بناء الموقع وتم اتباع خطوات إعداد S3.

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

من الواضح أنني ارتكبت خطأً ما. أستخدم الآن مساحة تخزين أكبر مما كنت أستخدمه من قبل.

يجب أن يتم التحميل إلى S3 أثناء إعادة البناء. يجب أن تتمكن من تصفح أصول الموقع في مجموعات S3، ويجب أن يتم تحميل جميع أصول الموقع من رابط S3 أو CDN المُزوَّد. إذا لم يكن الأمر يعمل، فهناك بالتأكيد خطأ في طريقة إعدادك له. هل تظهر لك أي أخطاء؟

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

تحرير:
كانت جميع عمليات الرفع منذ عدة أشهر تُوجَّه بالفعل إلى S3. أود نقل البيانات القديمة التي سبقت الانتقال إلى S3.

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

بدلاً من ذلك، يمكنك تشغيل ./discourse-doctor لتوليد سجل للمراجعة.

ها هو مخرج السكربت:

الشيء الوحيد الذي ألاحظه هو ما تم تمييزه بخط عريض في قسم DNS.

> root@discourse:/var/discourse# ./discourse-doctor
> DISCOURSE DOCTOR Thu May 14 11:35:17 UTC 2020
> OS: Linux discourse 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> Found containers/app.yml
> 
> ==================== YML SETTINGS ====================
> DISCOURSE_HOSTNAME=
> SMTP_ADDRESS=
> DEVELOPER_EMAILS=
> SMTP_PASSWORD=
> SMTP_PORT=
> SMTP_USER_NAME=
> LETSENCRYPT_ACCOUNT_EMAIL=
> 
> ==================== DOCKER INFO ====================
> DOCKER VERSION: Docker version 18.09.6, build 481bc77
> 
> DOCKER PROCESSES (docker ps -a)
> 
> CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
> db900fc77ebe        local_discourse/app   "/sbin/boot"        15 hours ago        Up 15 hours         0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
> 
> db900fc77ebe        local_discourse/app   "/sbin/boot"        15 hours ago        Up 15 hours         0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
> 
> Discourse container app is running
> 
> 
> ==================== PLUGINS ====================
>             exec: {cd: $home/plugins, cmd: ['git clone https://github.com/discourse/docker_manager.git', 'git clone https://github.com/procourse/procourse-static-pages.git', 'git clone https://github.com/discourse/discourse-bbcode.git', 'git clone https://github.com/discourse/discourse-adplugin.git']}
> 
> No non-official plugins detected.
> 
> See https://github.com/discourse/discourse/blob/master/lib/plugin/metadata.rb for the official list.
> 
> ========================================
> Discourse version at : NOT FOUND
> Discourse version at localhost: Discourse 2.5.0.beta4
**> ==================== DNS PROBLEM ====================**
**> This server reports Discourse 2.5.0.beta4 , but  reports NOT FOUND.**
**> This suggests that you have a DNS problem or that an intermediate proxy is to blame.**
**> If you are using Cloudflare, or a CDN, it may be improperly configured.**
> 
> 
> ==================== MEMORY INFORMATION ====================
> RAM (MB): 1008
> 
>               total        used        free      shared  buff/cache   available
> Mem:            985         636          69         121         279          88
> Swap:          2047         775        1272
> 
> ==================== DISK SPACE CHECK ====================
> ---------- OS Disk Space ----------
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/vda1        25G   20G  4.8G  81% /
> 
> ---------- Container Disk Space ----------
> Filesystem      Size  Used Avail Use% Mounted on
> overlay          25G   20G  4.8G  81% /
> /dev/vda1        25G   20G  4.8G  81% /shared
> /dev/vda1        25G   20G  4.8G  81% /var/log
> 
> ==================== DISK INFORMATION ====================
> Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 02CBFCD2-7495-4A08-A11B-28E7D3872FAA
> 
> Device      Start      End  Sectors  Size Type
> /dev/vda1  227328 52428766 52201439 24.9G Linux filesystem
> /dev/vda14   2048    10239     8192    4M BIOS boot
> /dev/vda15  10240   227327   217088  106M Microsoft basic data
> 
> Partition table entries are not in disk order.
> 
> ==================== END DISK INFORMATION ====================
> 
> ==================== MAIL TEST ====================
> For a robust test, get an address from http://www.mail-tester.com/
> Or just send a test message to yourself.
> Email address for mail test? ('n' to skip) []: n
> Mail test skipped.
> Replacing: SMTP_PASSWORD
> Replacing: LETSENCRYPT_ACCOUNT_EMAIL
> Replacing: DEVELOPER_EMAILS
> Replacing: DISCOURSE_DB_PASSWORD
> Replacing: Sending mail to
> 
> ==================== DONE! ====================
> Would you like to serve a publicly available version of this file? (Y/n)n
> root@discourse:/var/discourse#

ها هو القسم من ملف app.yml:

> 
>     DISCOURSE_USE_S3: true
>     DISCOURSE_S3_REGION: us-east-1
>     DISCOURSE_S3_ACCESS_KEY_ID: <MY KEY>
>     DISCOURSE_S3_SECRET_ACCESS_KEY: <MY SECRET KEY>
>     DISCOURSE_S3_CDN_URL: 'https://d2hneyr8lp58j4.cloudfront.net'
>     DISCOURSE_S3_BUCKET: brcuploads
>     DISCOURSE_S3_BACKUP_BUCKET: bcruploads-backups
>     DISCOURSE_BACKUP_LOCATION: s3

هل هذا يخبرني أن إعدادات DNS على DigitalOcean خاطئة؟ لقد أضفت CNAME من Cloudfront.

واو، هذا لم يكن مفيدًا. لقد اخترت n لـ

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

سأرسل لك الرابط عبر الرسائل الخاصة.