php - third - s3fs windows

¿Cómo puedo montar un cubo S3 en una instancia EC2 y escribir en él con PHP?

Question

Estoy trabajando en un proyecto alojado en Amazon Web Services. La configuración del servidor consta de dos instancias EC2, un Elastic Load Balancer y un Elastic Block Store extra en el que reside la aplicación web. El proyecto debe usar S3 para el almacenamiento de los archivos que los usuarios cargan. Por el bien de esta pregunta, llamaré a la categoría S3 static.example.com

He intentado usar s3fs ( https://code.google.com/p/s3fs/wiki/FuseOverAmazon ), RioFS ( https://github.com/skoobe/riofs ) y s3ql ( https://code.google.com/p/s3ql/ ). s3fs montará el sistema de archivos, pero no me dejará escribir en el cubo (hice esta pregunta en SO: ¿cómo puedo montar un volumen S3 con los permisos adecuados con FUSE). RioFS montará el sistema de archivos y me permitirá escribir en el depósito desde el shell, pero los archivos que se guardan con PHP no aparecen en el contenedor (abrí un problema con el proyecto en GitHub). s3ql montará el depósito, pero ninguno de los archivos que ya están en el depósito aparecerá en el sistema de archivos.

Estos son los comandos de montaje que utilicé:

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

También intenté usar esta clase S3: https://github.com/tpyo/amazon-s3-php-class/ y este paquete S3 específico de FuelPHP: https://github.com/tomschlick/fuel-s3 . Pude obtener el paquete FuelPHP para enumerar los depósitos y archivos disponibles, pero se produjo un error al guardar los archivos en el depósito (pero no se produjo ningún error).

¿Alguna vez montó un cubo S3 en un sistema de archivos linux local y usó PHP para escribir un archivo en el cubo con éxito? ¿Qué herramientas usaste? Si utilizó una de las herramientas mencionadas anteriormente, ¿qué versión usó?

EDITAR Me han informado que el problema que abrí con RioFS en GitHub se ha resuelto. Aunque decidí usar la API REST de S3 en lugar de intentar montar un depósito como volumen, parece que RioFS puede ser una opción viable en estos días.

Answer 1

¿Alguna vez montó un cubo S3 en un sistema de archivos linux local?

No. Es divertido probarlo, pero no lo dejaría cerca de un sistema de producción. Es mucho mejor usar una biblioteca para comunicarse con S3. Este es el por qué:

1. No ocultará los errores. Un sistema de archivos solo tiene algunos códigos de error que pueden enviarte para indicar un problema. Una biblioteca S3 le dará el mensaje de error exacto de Amazon para que comprenda lo que sucede, lo logre, maneje casos de esquina, etc.
2. Una biblioteca usará menos memoria. Las capas de los sistemas de archivos almacenan en caché muchas cosas aleatorias que nunca volverás a usar. Una biblioteca te permite controlar qué guardar en caché y no almacenar en caché.
3. Expansión. Si alguna vez necesitas hacer algo elegante (establecer una ACL en un archivo, generar un enlace firmado, control de versiones, ciclo de vida, cambiar la durabilidad, etc.), entonces tendrás que volcar la abstracción de tu sistema de archivos y usar una biblioteca de todos modos.
4. Tiempo y reintentos. Algunas fracciones de solicitudes se equivocan aleatoriamente y se pueden volver a intentar. A veces es posible que desee volver a intentar mucho, a veces preferiría un error de salida rápidamente. Un sistema de archivos no le proporciona control granular, pero sí una biblioteca.

La conclusión es que S3 en FUSE es una abstracción con fugas . S3 no tiene (ni necesita) directorios. Los sistemas de archivos no fueron construidos para miles de millones de archivos. Sus modelos de permisos son incompatibles. Está desperdiciando mucho poder de S3 al intentar meterlo en un sistema de archivos.

Dos bibliotecas PHP aleatorias para hablar con S3:

https://github.com/KnpLabs/Gaufrette

https://aws.amazon.com/sdkforphp/ - este es útil si se expande más allá de simplemente usar S3, o si necesita hacer alguna de las solicitudes de lujo mencionadas anteriormente.

Answer 2

Muy a menudo, es ventajoso escribir archivos en el volumen de EBS, luego forzar las solicitudes públicas subsiguientes para que los archivos se encaminen a través de CloudFront CDN.

De esta forma, si la aplicación debe realizar transformaciones en el archivo, es mucho más fácil hacerlo en la unidad local y el sistema, luego fuerce las solicitudes para que los archivos transformados se extraigan del origen a través de CloudFront.

por ejemplo, si su usuario está cargando una imagen para un avatar, y la imagen del avatar necesita varias iteraciones para tamaño y recorte, su aplicación puede crearlas en el volumen local, pero todas las solicitudes públicas del archivo se realizarán a través de un origen frente a la nube solicitud. De esta forma, tiene la máxima flexibilidad para conservar el archivo original (o una versión optimizada del archivo) y cualquier solicitud posterior de un usuario puede extraer una versión existente del borde frontal de la nube, o Cloud Front direccionará la solicitud a la aplicación y crea las iteraciones necesarias.

Un ejemplo elemental de lo anterior sería WordPress, que crea versiones de múltiples tamaños / recortadas de cualquier imagen gráfica cargada, además de mantener el original (sujeto a restricciones de tamaño de archivo y / o transformaciones de complemento). Los complementos de WordPress compatibles con CDN, como W3 Total Cache, reescriben las solicitudes para pasar por CDN, por lo que la aplicación solo necesita crear iteraciones únicas de primera solicitud. La adición del control de versiones de URL del almacenamiento en caché del navegador ( http://domain.tld/file.php?x123 ) refina aún más y aprovecha la funcionalidad de CDN.

Si le preocupa la rápida expansión del tamaño del archivo de volumen de EBS o de los inodos, puede automatizar un proceso de poda para archivos raramente solicitados o archivos antiguos.