web-dev-qa-db-ja.com

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

Amazon Web Servicesでホストされているプロジェクトに取り組んでいます。サーバーのセットアップは、2つのEC2インスタンス、1つのElastic Load Balancer、およびWebアプリケーションが存在する追加のElastic Block Storeで構成されています。プロジェクトは、ユーザーがアップロードするファイルの保存にS3を使用することを想定しています。この質問のために、S3バケットをstatic.example.comと呼びます

s3fs（ https://code.google.com/p/s3fs/wiki/FuseOverAmazon ）、RioFS（ https：/ /github.com/skoobe/riofs ）およびs3ql（ https://code.google.com/p/s3ql/ ）。 s3fsはファイルシステムをマウントしますが、バケットへの書き込みを許可しません（SOでこの質問をしました：Fuseを使用して適切な権限でS3ボリュームをマウントするにはどうすればよいですか）。 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-s 。 FuelPHPパッケージを取得して、使用可能なバケットとファイルをリストできましたが、ファイルをバケットに保存できませんでした（エラーは発生しませんでした）。

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

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

phpamazon-s3fuses3fs
54
Ben Harold

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

いいえ。テストするのは楽しいですが、実稼働システムの近くに置いてはいけません。ライブラリを使用してS3と通信することをお勧めします。その理由は次のとおりです。

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

一番下の行は、ヒューズの下のS3が 漏れやすい抽象化 であるということです。 S3にはディレクトリがありません（または必要ありません）。ファイルシステムは、数十億のファイル用に構築されていません。権限モデルには互換性がありません。 S3をファイルシステムにシューホーンすることで、S3の多くのパワーを無駄にしています。

2つのランダムなPHP S3と通信するためのライブラリ：

https://github.com/KnpLabs/Gaufrette

https://aws.Amazon.com/sdkforphp/ -これは、S3の使用を超えて拡張する場合、または上記の空想的な要求のいずれかを行う必要がある場合に役立ちます。

51
BraveNewCurrency

多くの場合、ファイルをEBSボリュームに書き込んでから、ファイルに対する後続のパブリックリクエストをCloudFront CDN経由でルーティングすることが有利です。

そのようにして、アプリがファイルに何らかの変換を行う必要がある場合、ローカルドライブとシステムで行うのがはるかに簡単になり、変換されたファイルのリクエストをCloudFront経由でOriginから強制的に取得します。

例えばユーザーがアバター用の画像をアップロードしており、サイズと切り抜きのためにアバター画像を数回繰り返す必要がある場合、アプリはローカルボリュームでこれらを作成できますが、ファイルに対するすべてのパブリックリクエストは、クラウドフロントのOrigin-pullリクエストによって行われます。そのようにして、元のファイル（または最適化されたバージョンのファイル）を保持する最大限の柔軟性があり、その後のユーザーリクエストはクラウドフロントエッジから既存のバージョンをプルするか、クラウドフロントがリクエストをアプリにルーティングします必要な反復を作成します。

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

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

2
PlayGod