検索しましたが、DigitalOcean から S3 へのアップロード移行に関する基本的な概要が見つかりませんでした。数ヶ月前に、新規アップロードとバックアップ用の S3 設定は正常に完了しました。現在、アップロードデータ(約 1.4GB)を S3 へ完全に移行したいと考えています。
これは最初から SMF2 からの移行です。現在、アップロード用フォルダが 2 つあります。1 つはルートディレクトリ内の smf2、もう 1 つは/var/discourse です。SMF2 ディレクトリは 2.8GB あります。おそらく、ここには 2 つのステップが必要なのでしょうか?SMF2 ディレクトリと/var/discourse ディレクトリからそれぞれ別々に移行作業を行う必要があるのでしょうか?
rake to s3 というツールを見つけましたが、遭遇したエラーやその修正方法について語っている人々の議論以外に、ガイドを見つけることができませんでした。何かガイドはありますか?
この記事をお読みください。タスクの設定方法について案内しています。
設定部分のhooksセクションを確認し、既にお読みいただいている問題が発生しないよう、環境変数を使用してバケットを設定してください。
素晴らしいですね!ありがとうございます!
それに関連して私が知らないのはCDNだけです。Amazon CloudFront が使えると分かりました。以前の S3 設定手順では、これは設定されていなかったと推測します。設定方法のガイドを探します。
CloudFrontは、アップロード用バケットをオリジンとして設定し、設定が完了したらS3のCDNリンクとして設定するだけです。やるべきことはそれだけです。
ありがとうございます。CloudFront のセットアップは以下の動画を参考に実施しました:
現在、rake posts:rebake を実行中です。投稿数が 84,000 件あるため、時間がかかります。
また起きてしまいました… 何か案はありますか?
root@discourse-app:/var/www/discourse# rake posts:rebake
‘default’ の投稿 Markdown を再構築中
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 がホットリンクされた画像の取得に忙しく動いています。
OK、サイトの再構築が完了し、S3 のセットアップ手順も実行されました。
これですべてのコンテンツが S3 から読み込まれるはずです。その確認方法はありますか?また、ストレージの空き容量を増やすために、現在の Droplet 上の古いアップロードディレクトリを削除してもよいでしょうか?
明らかに何か間違えました。以前よりもディスク容量を多く使っています。
S3 へのアップロードは再ビルド時に実行されるはずです。S3 バケット内でウェブサイトのアセットを閲覧でき、すべてのサイトアセットが提供された S3 または CDN リンクから読み込まれる必要があります。動作しない場合は、設定方法に明らかな問題があります。エラーは表示されていますか?
何か問題が発生した可能性がありますね。数GBのデータをアップロードするには、私の再構築の時間が短すぎました。
編集:
数ヶ月前までのすべてのアップロードは既に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
これは、DigitalOcean の DNS 設定が間違っていることを示しているのでしょうか?Cloudfront の CNAME を追加しました。
おっと、これは役に立ちませんでした。n を選択しましたね。
公開バージョンを生成していただけますか?リンクをダイレクトメッセージでお知らせいただければ、S3 への移行が正常に完了したか、何らかの理由で失敗したかを確認できるかもしれません。