Я работаю над этой проблемой в течение последних 3 месяцев и полностью застрял.Как упаковать SoX-бинарник с поддержкой MP3 для функции NodeJS AWS Lambda с ограничениями AMI AWS?
Я пытаюсь упаковать свою функцию NodeJS AWS Lambda, которая будет использовать SoX и ее зависимости для преобразования аудиофайлов в MP3. Я могу получить свой код для распознавания пользовательского местоположения двоичного файла SoX, следуя инструкциям here и here. Я закончил тем, что добавил этот код в начало моего вызова функции Lambda, чтобы обновить переменную process.env PATH, чтобы включить путь к пользовательскому двоичному файлу.
process.env['PATH'] = process.env['PATH'] + ':'
+ path.join(process.env['LAMBDA_TASK_ROOT'], 'binaries');
Это приводит к моему process.env PATH обновление, чтобы выглядеть следующим образом:
/usr/local/lib64/node-v4.3.x/bin:/usr/local/bin:/usr/bin/:/bin:/var/task/binaries
Что выглядит правильно, binaries каталог, который содержит Сокс Бинарный скомпилированный.
Поскольку я использую NodeJS, я должен был изменить НПМ модуль sox-audio поэтому использовал обновленную переменную process.env для child_process exec и spawn вызовов. Это позволяет коду находить двоичный файл, но я все равно получаю сообщение об ошибке во время выполнения.
Sox process exited with code 127 and signal null
Я понимаю, что, хотя он может найти двоичный Сокс я включал, он не может найти команду, используемую с SoX, но без дополнительной информации, которую я не могу сказать, что это такое. Я думал, что это потому, что я не уверен, есть ли у меня все файлы, включенные для работы двоичного файла.
В попытке сделать чистую скомпилированную сборку SoX с поддержкой MP3 я создал новый экземпляр Linux EC2, а затем выполнил приведенные инструкции here.
Я пошел по очереди, чтобы убедиться, что я смогу заставить его работать, и после установки нескольких зависимостей, чтобы включить компиляцию (например, developer tools), и экспортируя сборку PATH с помощью export PATH=$PATH:/usr/local/bin, я смог получить полную сборку, установленную с помощью Поддержка MP3. Я тестировал его, и он работает точно так же, как мне это нужно.
Поскольку функции AWS Lambda функционируют на одной и той же урезанной версии Linux (Amazon Linux AMI) как экземпляры AWS EC2, теоретически, если я смогу экспортировать сборку SoX и включить ее в свой пакет Lambda, тогда я должен иметь возможность заставить его работать.
Вот где у меня проблемы. Что составляет само построение? Существует исполняемый файл SoX linux в /usr/local/bin, который является одним файлом, но там также есть еще больше файлов, которые, похоже, все связаны с созданием SoX и его зависимостей. Вот список файлов в /usr/local/bin на рабочей сборке, которую у меня есть.
Я пытался экспортировать все эти файлы через FTP, а затем импортировать их в другой экземпляр EC2 чистой, но даже после того, как работает export PATH=$PATH:/usr/local/bin Сокс бы не работать из-за вопроса зависимости. Понятно, что просто экспортировать эти файлы недостаточно.
- Как экспортировать и что мне экспортировать, чтобы взять мою рабочую сборку SoX с поддержкой MP3 из экземпляра EC2 и включить ее в работу в моей функции AWS Lambda?
- Является ли длинный список установленных зависимостей, чтобы заставить MP3 работать, чтобы сделать это невозможным?
- Есть ли файлы более чем в
/usr/local/binкаталоге, которые мне нужно включить?
Я действительно не знаю, где еще пойти с этим. Пожалуйста, помогите :(