Я столкнулся с этой проблемой, я хочу разрешить пользователям загружать свои файлы прямо в мою корзину на Amazon S3. Этот шаг можно легко выполнить, как описано Вот.
Но что, если мне нужно отредактировать каждый файл с помощью FFMPEG?
Например.
shell_exec('ffmpeg -i /sample.wav -acodec libmp3lame /sample.mp3');
В настоящее время я сначала храню файлы на своем сервере, запускаю команды оболочки, затем использую putObject отправить их на S3, но есть ли лучший способ сделать это, оставив мой сервер в покое?
Мои характеристики:
Мое понимание вашего решения заставляет меня думать, что вы хотите использовать тот же сервер ubuntu, который у вас уже есть, чтобы также выполнить перекодирование ваших загруженных медиафайлов.
Проблема в том, что объекты, хранящиеся в S3, недоступны, как файлы в обычной файловой системе, вы можете загрузить файл из S3 и обработать его на экземпляре веб-сервера, однако это будет сложной и потенциально неэффективной настройкой.
Было бы лучше отделить процесс перекодирования от вашего сервера ubuntu и позволить ему происходить в истинном облачном стиле. Лучшее решение для этого - события S3 и Lambda.
Итак, исходя из моего понимания вашего варианта использования, я бы порекомендовал вам следующее:
Что касается UserData экземпляра, вот шаги, которые вы, возможно, захотите предпринять:
Возможно, вам лучше создать AMI, в котором уже установлен ffmpeg, но вам нужно будет решить, дешевле ли потратить 5 минут на подготовку каждого экземпляра или заплатить за AMI, чтобы он всегда был под рукой. Я бы сказал, однако, что если ваша обработка не занимает больше часа или ваш вариант использования не требует, чтобы файл возвращался как можно скорее, вам будет лучше устанавливать ffmpeg каждый раз, поскольку AWS выставляет счет за полные часы, даже если вы используете только 15 минут.
Рекомендации по такому подходу:
Скорее всего, вы захотите предпринять дальнейшие действия при создании вновь обработанного файла, так почему бы не использовать события s3 для запуска другого процесса Lambda? :)
Также, чтобы сохранить чистоту, если ваше решение позволяет это, попробуйте загрузить созданные вами файлы в s3 под другим ключевым путем к тому месту, где вы размещаете загруженные файлы.
Альтернативный вариант: использовать эластичный транскодер
Альтернативный вариант - использовать сервис AWS Elastic Transcoder. Таким же образом вы отправляете задания на транскодер, вызывая лямбда-выражение при обновлении сегмента S3 и заставляя его обрабатывать файлы в этом сегменте. Затем Elastic Transcoder может уведомить очередь SNS, которая затем может инициировать электронное письмо или другой лямбда-запрос для работы с созданным файлом.
Эластичный транскодер был бы более крутым и, вероятно, лучшим подходом, но он потребует немного больше работы.
Elastic Transcoder требует, чтобы вы создали конвейер, а затем создали задание, используя этот конвейер. Я свяжу вам SDK JavaScript для каждого.
CreatePipline http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/ElasticTranscoder.html#createPipeline-property
CreateJob http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/ElasticTranscoder.html#createJob-property
Альтернативное альтернативное решение: используйте Amazon SQS
Если вы хотите, чтобы обработка выполнялась в экземпляре ubuntu, а не запускала другой экземпляр из Lambda, вы можете использовать события S3 для запуска лямбда-выражения для публикации задания в Amazon SQS.
Amazon SQS позволит вашему собственному агенту опросить Amazon SQS на предмет вакансий, что позволит вам ссылаться на файл в s3, требующий перекодирования. Однако это довольно сложно, и я включаю его только для полноты, и если вам действительно не нужно выполнять эту работу с экземпляром ubuntu, который у вас уже есть.