Come posso montare un bucket S3 su un'istanza EC2 e scriverlo con PHP?

Question

Sto lavorando a un progetto ospitato su Amazon Web Services. La configurazione del server consiste di due istanze EC2, un Elastic Load Balancer e un extra Elastic Block Store su cui risiede l'applicazione web. Il progetto è supposto per utilizzare S3 per l'archiviazione dei file che gli utenti caricano. Per il bene di questa domanda, io chiamerò il secchio S3 static.example.com

Ho provato con s3fs (https://code.google.com/p/s3fs/wiki/FuseOverAmazon), RioFS (https://github.com/skoobe/riofs) e s3ql (https://code.google.com/p/s3ql/). s3fs monterà il filesystem ma non mi permetterà di scrivere sul bucket (ho fatto questa domanda su SO: come posso montare un volume S3 con le autorizzazioni appropriate usando FUSE). RioFS monterà il filesystem e mi consentirà di scrivere sul bucket dalla shell, ma i file che vengono salvati con PHP non appaiono nel bucket (ho aperto un problema con il progetto su GitHub). s3ql monterà il bucket, ma nessuno dei file che sono già nel bucket apparirà nel filesystem.

Questi sono i comandi di montaggio che ho usato:

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 

Ho anche provato ad utilizzare questa classe S3: https://github.com/tpyo/amazon-s3-php-class/ e questo FuelPHP pacchetto specifico S3: https://github.com/tomschlick/fuel-s3. Sono stato in grado di ottenere il pacchetto FuelPHP per elencare i bucket e i file disponibili, ma il salvataggio dei file nel bucket non è riuscito (ma non ha funzionato).

Avete mai montato un bucket S3 su un file system Linux locale e utilizzato PHP per scrivere correttamente un file nel bucket? Che tipo di strumenti hai usato? Se hai utilizzato uno degli strumenti sopra menzionati, quale versione hai usato?

EDIT Sono stato informato che il problema ho aperto con RioFS su GitHub è stato risolto. Sebbene abbia deciso di utilizzare S3 REST API anziché tentare di montare un bucket come volume, sembra che RioFS possa essere un'opzione valida in questi giorni.

Answer 1

Avete mai montato un bucket S3 su un file system Linux locale?

No. È divertente per i test, ma non lo lascerei vicino a un sistema di produzione. È molto meglio usare una libreria per comunicare con S3. Ecco perché:

1. Non nasconde gli errori. Un filesystem ha solo alcuni codici di errore che può inviarti per indicare un problema. Una libreria S3 ti fornirà l'esatto messaggio di errore da Amazon per capire cosa sta succedendo, registrarlo, gestire casi d'angolo, ecc.
2. Una libreria utilizzerà meno memoria. I livelli di Filesystem nascondono molte cose casuali che molti non usano mai più. Una libreria ti mette in controllo per decidere cosa memorizzare nella cache e non memorizzare nella cache.
3. Espansione. Se hai bisogno di fare qualcosa di stravagante (imposta un ACL su un file, genera un link firmato, il controllo delle versioni, il ciclo di vita, cambia la durata, ecc.), Dovrai quindi scaricare l'astrazione del filesystem e usare comunque una libreria.
4. Tempi e tentativi. Qualche frazione di richieste casualmente sbaglia e può essere ritentata. A volte potresti voler riprovare molto, a volte preferiresti un errore in fretta. Un filesystem non ti dà un controllo granulare, ma una libreria lo farà.

La linea di fondo è che S3 sotto FUSE è un leaky abstraction. S3 non ha (o ha bisogno) directory. I file system non sono stati creati per miliardi di file. I loro modelli di permessi sono incompatibili. Stai sprecando gran parte della potenza di S3 provando a caricarlo su un filesystem.

Due librerie PHP casuali per parlare con S3:

https://github.com/KnpLabs/Gaufrette

https://aws.amazon.com/sdkforphp/ - questo è utile se si espande oltre la semplice utilizzando S3, o se avete bisogno di fare alcuna delle richieste di fantasia di cui sopra.

Answer 2

Molto spesso, è vantaggioso scrivere i file sul volume EBS, quindi imporre le richieste pubbliche successive per i file da instradare attraverso CloudFront CDN.

In questo modo, se l'applicazione deve eseguire trasformazioni sul file, è molto più semplice da eseguire sul sistema locale &, quindi imporre le richieste di trasferimento dei file trasformati dall'origine tramite CloudFront.

ad es. se l'utente sta caricando un'immagine per un avatar e l'immagine dell'avatar ha bisogno di diverse iterazioni per il ritaglio &, l'app può crearle sul volume locale, ma tutte le richieste pubbliche per il file avverranno tramite una richiesta di origine-pull di cloudfront . In questo modo, hai la massima flessibilità per mantenere il file originale (o una versione ottimizzata del file), e qualsiasi successiva richiesta dell'utente può estrarre una versione esistente dal bordo anteriore del cloud, oppure il cloud front instraderà la richiesta all'app e creare tutte le iterazioni necessarie.

Un esempio elementare di quanto sopra sarebbe WordPress, che crea versioni multiple/ritagliate di qualsiasi immagine grafica caricata, oltre a mantenere l'originale (soggetto a restrizioni sulle dimensioni del file e/o trasformazioni di plugin). Plugin WordPress compatibili con CDN come W3 Total Cache riscrivono le richieste per passare attraverso CDN, quindi l'applicazione deve solo creare iterazioni di prima richiesta uniche. L'aggiunta della versione di URL per la memorizzazione nella cache del browser (http://domain.tld/file.php?x123) perfeziona ulteriormente e sfrutta la funzionalità CDN.

Se si è preoccupati di una rapida espansione delle dimensioni o degli inode del file di volume EBS, è possibile automatizzare un processo di eliminazione per file raramente richiesti o file invecchiati.