Wie kann ich SoX-Binärdateien mit MP3-Unterstützung für eine NodeJS AWS Lambda-Funktion mit Einschränkungen von AWS Linux AMI kombinieren?

Question

Ich habe in den letzten 3 Monaten an diesem Problem gearbeitet und bin völlig festgefahren.

Ich versuche, meine NodeJS AWS Lambda-Funktion, die SoX und seine Abhängigkeiten zu Audiodateien in MP3 konvertieren wird. Ich kann meinen Code dazu bringen, den benutzerdefinierten Speicherort der SoX-Binärdatei zu erkennen, indem ich den Anweisungen here und here folge. Ich habe diesen Code am Anfang meines Lambda-Funktionsaufrufs hinzugefügt, um die Variable process.env PATH so zu aktualisieren, dass sie den Pfad zur benutzerdefinierten Binärdatei enthält.

process.env['PATH'] = process.env['PATH'] + ':' 
+ path.join(process.env['LAMBDA_TASK_ROOT'], 'binaries'); 

Dies führt zu meiner process.env PATH Aktualisierung wie folgt aussehen:

/usr/local/lib64/node-v4.3.x/bin:/usr/local/bin:/usr/bin/:/bin:/var/task/binaries 

Welche korrekt aussieht, binaries ist das Verzeichnis, das die SOx-Binär-I enthält, zusammengestellt.

Da ich NodeJS bin mit, hatte ich das sox-audio NPM-Modul zu ändern, so dass es die aktualisierte process.env Variable für die child_process exec und spawn Anrufe verwendet. Dadurch kann der Code die Binärdatei finden, aber während der Ausführung wird immer noch ein Fehler angezeigt.

Sox process exited with code 127 and signal null 

Ich verstehe, dass, obwohl es die SoX binäre finden kann ich eingeschlossen, nicht in der Lage ist ein Befehl mit SoX zu finden, aber ohne weitere Informationen kann ich nicht sagen, was es ist. Ich dachte, es liegt daran, dass ich nicht sicher bin, ob alle Dateien für die Binärdatei enthalten sind.

In einem Versuch, einen sauberen kompilierten Build von SoX mit MP3-Unterstützung zu machen, erstellte ich eine neue EC2-Linux-Instanz und folgte dann den Anweisungen here.

Ich ging Zeile für Zeile, um sicherzustellen, dass ich es funktionierte, und nach der Installation ein paar Abhängigkeiten zum Compilieren aktivieren (wie developer tools), und durch den Export des Build PATH mit export PATH=$PATH:/usr/local/bin konnte ich einen vollständigen Build mit installiert bekommen MP3-Unterstützung. Ich habe es getestet und es funktioniert genau so, wie ich es brauche.

Da AWS Lambda-Funktionen auf der gleichen abgespeckten Version von Linux (Amazon Linux AMI) wie AWS EC2-Instanzen laufen, könnte ich theoretisch, wenn ich den SoX-Build exportieren und in mein Lambda-Paket aufnehmen könnte Mach es zur Arbeit.

Das ist, wo ich Probleme habe. Was macht das gebaute selbst aus? Es gibt eine ausführbare SoX-Linux-Datei in /usr/local/bin, die eine einzelne Datei ist, aber es gibt auch eine Tonne mehr Dateien, die alle damit verbunden sind, SoX und seine Abhängigkeiten funktionieren zu lassen. Hier ist eine Liste von Dateien innerhalb /usr/local/bin auf dem Arbeitsbuild, das ich habe.

Ich habe versucht, all diese Dateien per FTP zu exportieren und sie dann in einer anderen saubere EC2-Instanz importieren, aber auch nach export PATH=$PATH:/usr/local/bin SoX laufen würde scheitern, weil ein Abhängigkeitsproblem laufen. Es ist klar, dass das einfache Exportieren dieser Dateien nicht ausreicht.

• Wie exportiere ich und was exportiere ich meine Arbeits Build von SoX mit MP3-Unterstützung aus der EC2-Instanz und umfassen nehmen es in meiner AWS Lambda-Funktion zu arbeiten?
• Ist die lange Liste der installierten Abhängigkeiten, damit MP3 funktioniert, unmöglich?
• Gibt es Dateien in mehr als nur dem /usr/local/bin Verzeichnis, das ich aufnehmen muss?

Ich weiß wirklich nicht wo sonst noch zu gehen. Bitte helfen :(

Answer 1

hat mich 3 Monate, um endlich zu veröffentlichen, und ich es heraus am selben Tag aus.

Nach etwas mehr Forschung tun, ich kam zu dem Schluss, dass ich eine statische Aufladung von SOx zu schaffen, um mit die notwendigen Abhängigkeiten MP3 zu konvertieren. ich ein Skript die zusammen~~POS=TRUNC endete eine statische Aufladung zu schaffen, basierend auf this blog post und this blog post.

Der Grund, warum ich ein wenig in Kombination von beiden war, weil ich Amazonen Linux AMI wurde mit, was sehr Also alle Debian- und apt-get-Sachen, die im zweiten Blog erwähnt werden, würden wahrscheinlich nicht funktionieren, aber ich musste sicherstellen, dass ich einen Compiler installiert hatte, damit ich nicht laufen würde in irgendwelche Fehler. Unten ist, was ich am Ende gelaufen bin. Ich habe die ganze Sache als root gemacht, da Privilegien auf EC2 Amazon Linux AMI-Instanzen ziemlich eingeschränkt sind. Das einzige, was als normaler Benutzer ausgeführt werden muss, ist der PATH-Export am Ende.

sudo yum update 
sudo yum install gcc44 gcc-c++ libgcc44 cmake –y 

# now grab sox and its dependencies 
mkdir -p deps 
mkdir -p deps/unpacked 
mkdir -p deps/built 
mkdir -p deps/built/libmad 
mkdir -p deps/built/sox 
mkdir -p deps/built/lame 
wget -O deps/sox-14.4.1.tar.bz2 "http://downloads.sourceforge.net/project/sox/sox/14.4.1/sox-14.4.1.tar.bz2?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fsox%2Ffiles%2Fsox%2F14.4.1%2F&ts=1416316415&use_mirror=heanet" 
wget -O deps/libmad-0.15.1b.tar.gz "http://downloads.sourceforge.net/project/mad/libmad/0.15.1b/libmad-0.15.1b.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fmad%2Ffiles%2Flibmad%2F0.15.1b%2F&ts=1416316482&use_mirror=heanet" 
wget -O deps/lame-3.99.5.tar.gz "http://downloads.sourceforge.net/project/lame/lame/3.99/lame-3.99.5.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Flame%2Ffiles%2Flame%2F3.99%2F&ts=1416316457&use_mirror=kent" 

# unpack the dependencies 
pushd deps/unpacked 
tar xvfpj ../sox-14.4.1.tar.bz2 
tar xvfpz ../libmad-0.15.1b.tar.gz 
tar xvfpz ../lame-3.99.5.tar.gz 
popd 

# build libmad, statically 
pushd deps/unpacked/libmad-0.15.1b 
./configure --disable-shared --enable-static --prefix=$(realpath ../../built/libmad) 
# Patch makefile to remove -fforce-mem 
sed s/-fforce-mem//g <Makefile> Makefile.patched 
cp Makefile.patched Makefile 
make 
make install 
popd 

# build lame, statically 
pushd deps/unpacked/lame-3.99.5 
./configure --disable-shared --enable-static --prefix=$(realpath ../../built/lame) 
make 
make install 
popd 

# build sox, statically 
pushd deps/unpacked/sox-14.4.1 
./configure --disable-shared --enable-static --prefix=$(realpath ../../built/sox) \ 
    LDFLAGS="-L$(realpath ../../built/libmad/lib) -L$(realpath ../../built/lame/lib)" \ 
    CPPFLAGS="-I$(realpath ../../built/libmad/include) -I$(realpath ../../built/lame/include)" \ 
    --with-mad --with-lame --without-oggvorbis --without-oss --without-sndfile --without-flac --without-gomp 
make -s 
make install 
popd 

cp deps/built/sox/bin/sox . 
rm -rf deps/built 
rm -rf deps/unpacked 

Danach lief ich folgendes als meine normale Benutzer

export PATH=$PATH:/home/ec2-user 

Ich konnte dann sox laufen! Geben Sie einfach sox in das Terminal ein, um die Befehlsliste in Ihrem Terminalfenster zu öffnen.

Noch besser, ich konnte dann die einzige ausführbare Sox-Linux-Datei herunterladen und dann auf eine brandneue EC2-Instanz hochladen. Die einzigen Dinge, die ich hatte auf die neue Instanz laufen sie zur Arbeit zu kommen war die folgende:

sudo yum update 
sudo yum install gcc44 gcc-c++ libgcc44 cmake –y 
export PATH=$PATH:/home/ec2-user 

Ich war besorgt, dass ich versuchen müsste und es wieder zu bauen, ohne die yum update oder yum installiert, da Ich möchte dies letztendlich in eine Lambda-Funktion einbauen, aber das war nicht nötig! Als ich es meiner Test-Lambda-Funktion hinzugefügt und hochgeladen habe, funktionierte es laut den Cloud-Logs ohne Probleme. Das muss bedeuten, dass das Amazon Linux AMI, das in Lambda-Containern verwendet wird, bereits die yum-Updates und die richtigen Compiler installiert hat.