S3バケットをEC2インスタンスにマウントしてPHPで書き込むにはどうしたらいいですか？

Question

私は、Amazon Web Servicesでホストされているプロジェクトに取り組んでいます。サーバー設定は、2つのEC2インスタンス（1つのElastic Load BalancerとWebアプリケーションが存在する余分なElastic Block Store）で構成されています。このプロジェクトはであり、ユーザがアップロードするファイルの格納にS3を使用すると仮定した場合、となります。この質問のために、私は、s3fs（https://code.google.com/p/s3fs/wiki/FuseOverAmazon）を使用してRioFS（https://github.com/skoobe/riofs）とs3ql（https://code.google.com/p/s3ql/）を試してみましたS3バケットstatic.example.com

を呼ぶことにします。 s3fsはファイルシステムをマウントしますが、バケツに書き込むことはできません（私はこの問題について質問しました.SUSEをFUSEを使用して適切な権限でマウントするにはどうすればよいですか）。 RioFSはファイルシステムをマウントし、シェルからバケットに書き込むことができますが、PHPを使用して保存されたファイルはバケットに表示されません（GitHubのプロジェクトで問題が発生しました）。 s3qlはバケットをマウントしますが、すでにバケットに入っているファイルはファイルシステムには表示されません。

s3fs static.example.com -ouse_cache=/tmp,allow_other /mnt/static.example.com 
riofs -o allow_other http://s3.amazonaws.com static.example.com /mnt/static.example.com 
s3ql mount.s3ql s3://static.example.com /mnt/static.example.com 

私も、このS3クラスを使用して試してみた：https://github.com/tpyo/amazon-s3-php-class/このFuelPHP特定S3パッケージ：https://github.com/tomschlick/fuel-s3

これらは、マウントが、私が使用するコマンドです。私は利用可能なバケットとファイルを一覧表示するためにFuelPHPパッケージを入手することができましたが、ファイルをバケットに保存することはできませんでした（しかし、エラーはありませんでした）。

ローカルのLinuxファイルシステムにS3バケットをマウントし、PHPを使用してファイルをバケットに正常に書き込んだことはありますか？どのツールを使用しましたか？上記のいずれかのツールを使用した場合、どのバージョンを使用しましたか？

EDIT 私はGitHubの上RioFSで開かれた問題が解決されたことが通知されています。ボリュームとしてバケットをマウントしようとするのではなく、S3 REST APIを使用することに決めましたが、最近はRioFSが実行可能なオプションになる可能性があります。

Answer 1

ローカルのLinuxファイルシステムにS3バケットをマウントしたことがありますか？

いいえテストするのは楽しいですが、私はプロダクションシステムの近くに置くことはできません。 S3と通信するにはライブラリを使用する方がはるかに優れています。理由は次のとおりです。

1. エラーを隠すことはありません。ファイルシステムには、問題を示すためにあなたに送ることができるいくつかのエラーコードしかありません。 S3ライブラリはAmazonの正確なエラーメッセージを提供するので、何が起こっているのかを理解し、ログに記録し、コーナーケースなどを処理します。
2. ライブラリのメモリ使用量は少なくなります。ファイルシステムのレイヤーでは、多くのランダムなものをキャッシュします。ライブラリは、キャッシュするものとキャッシュしないものを決定するために制御します。
3. 拡張。 （ファイルにACLを設定し、署名付きリンクを生成し、バージョン管理、ライフサイクルを変更し、耐久性を変更するなど）何かをする必要がある場合は、ファイルシステムの抽象化をダンプし、とにかくライブラリを使用する必要があります。
4. タイミングとリトライ。要求の一部がランダムにエラーになり、再試行できます。時には多くのことをやり直したいことがあります。時には間違いなく迅速にエラーを出すこともあります。ファイルシステムは細かい制御はしませんが、ライブラリはできます。

最終行はFUSEのS3がleaky abstractionであることです。 S3にはディレクトリがありません（または必要です）。ファイルシステムは何十億ものファイルに対して構築されていませんでした。それらのアクセス許可モデルは互換性がありません。あなたはS3のパワーを、ファイルシステムにshoehornしようとして無駄にしています。 S3に話しため

2つのランダムなPHPライブラリ：

https://github.com/KnpLabs/Gaufrette

https://aws.amazon.com/sdkforphp/ - あなただけのS3を使用して超えて展開する場合は、この1が有用であるか、上記の空想の要求のいずれかを実行する必要がある場合。

Answer 2

多くの場合、EBSボリュームにファイルを書き込んだ後、CloudFront CDNを経由してファイルへのパブリック要求を強制するのが有効です。

このように、アプリケーションがファイルへの変換を行う必要がある場合は、ローカルドライブ&システムで実行する方がずっと簡単です。変換されたファイルのリクエストが強制的にCloudFront経由で元に戻されます。

ユーザーがアバター用の画像をアップロードしていて、アバター画像がサイズが&の数回反復する必要がある場合、アプリケーションはローカルボリューム上にこれらの画像を作成できますが、ファイルに対するパブリックリクエストはすべて、 。このようにして、元のファイル（または最適化されたバージョンのファイル）を保持するための最大限の柔軟性が得られます。その後のユーザーリクエストは、クラウドのフロントエッジから既存のバージョンを取得するか、クラウドフロントがリクエストをアプリに戻します必要な反復を作成します。

上記の基本的な例は、オリジナルを保持することに加えて（ファイルサイズの制限および/またはプラグインの変換に加えて）アップロードされたグラフィックイメージの複数のサイズ変更/クロップバージョンを作成するWordPressです。 W3 Total CacheなどのCDN対応のWordPressプラグインは、CDNをプルするリクエストを書き直すので、一意の最初のリクエストの繰り返しを作成するだけです。ブラウザキャッシングURLバージョン管理（http://domain.tld/file.php?x123）を追加すると、CDN機能がさらに洗練され、活用されます。

EBSボリュームファイルサイズまたはinodeの急速な拡張が懸念される場合は、要求の少ないファイルまたは古いファイルのプルーニングプロセスを自動化できます。