2015-12-10 3 views
6

ich auf einem Lambda arbeite, die Verwendung von Modulen (async, Anfrage, etc.)Kann nicht mit AWS Lambdas alle 3rd-Party-Modul verwenden

Unable to import module 'index': Error 
at Function.Module._resolveFilename (module.js:338:15) 
at Function.Module._load (module.js:280:25) 
at Module.require (module.js:364:17) 
at require (module.js:380:17) 
at Object.<anonymous> (/var/task/index.js:1:63) 
at Module._compile (module.js:456:26) 
at Object.Module._extensions..js (module.js:474:10) 
at Module.load (module.js:356:32) 
at Function.Module._load (module.js:312:12) 
at Module.require (module.js:364:17) 

Beispielcode macht:

var 
    AWS = require('aws-sdk'), 
    util = require('util'), 
    request = require('request'); 

exports.handler = function(event, context) { 
    console.log('test'); 
    context.done(); 
}; 

Es funktioniert fein (Drucktest) solange keine 3rd-Party-Module (außer aws-sdk) benötigt werden. Sobald ich nur eine Zeile wie zB hinzufügen:

require('request') // or async, config and so on 

Es schlägt mit dem obigen Fehler. Ich habe versucht, diese Module auch direkt aufzurufen, indem ich den vollständigen Pfad ohne Glück angegeben habe. Es ist so, als wenn man das falsche Verzeichnis anschaut, wenn man require anruft.

Dumping process.env in der Konsole ergibt:

PATH: '/usr/local/bin:/usr/bin:/bin', 
LAMBDA_TASK_ROOT: '/var/task', 
LAMBDA_RUNTIME_DIR: '/var/runtime', 
AWS_REGION: 'us-west-2', 
AWS_DEFAULT_REGION: 'us-west-2', 
AWS_LAMBDA_LOG_GROUP_NAME: '/aws/lambda/Thumbnailer', 
AWS_LAMBDA_LOG_STREAM_NAME: '2015/12/10/[$LATEST]3f8ef236195448c88f206634bde6301b', 
AWS_LAMBDA_FUNCTION_NAME: 'Thumbnailer', 
AWS_LAMBDA_FUNCTION_MEMORY_SIZE: '512', 
AWS_LAMBDA_FUNCTION_VERSION: '$LATEST', 
NODE_PATH: '/var/runtime:/var/task:/var/runtime/node_modules', 

Hier ist die module ich arbeitete aus - offenbar dies irgendwann zu arbeiten verwendet hat, aber nicht für mich.

Ideen? Ich habe das Gefühl, dass mir hier eine Konfiguration fehlt, die einzigartig für Lambdas ist.

+0

Können Sie Ihr Lambda-Bereitstellungspaket beschreiben? – James

+0

@James - Ich zip die Dateien (nicht den Ordner). Lambda scheint gut zu laufen, kann das Modul einfach nicht benutzen. – cyberwombat

+0

Nun - ich sollte sagen, es wirft keine Fehler, aber nichts passiert, da es nur der Rückruf ist, also vielleicht ein anderes Problem. – cyberwombat

Antwort

9

omg das war schmerzhaft ... Stellt sich heraus, dass OSX macht den node_modules Ordner nur vom Benutzer lesbar und AWS kann es nicht lesen. Machen Sie die node_modules Ordner und Inhalte für die Welt lesbar und es funktioniert. Ich bin mir nicht sicher, ob alle OSX-Setups gleich reagieren. Ich verwende nvm, was der Schuldige sein kann.

Aktualisieren. Ich habe alle Dateien auf 0666 gesetzt, aber lief auf Probleme mit ausführbaren Dateien. Hier ist ein kleines Skript, das die Dinge richtig anspricht. Es wird alle Dateien auf 0666 gesetzt, es sei denn, ausführbare Dateien oder ein Verzeichnis in diesem Fall 0777. Führen Sie diese aus dem Projektordner (seien Sie vorsichtig über die Auswirkungen der nicht zu tun!):

Hier ist ein Skript aus einem question I posted:

#!/bin/bash 
find . \ 
'(' -perm -0700 -exec chmod 0777 '{}' + ')' -o \ 
'(' -perm -0600 -exec chmod 0666 '{}' + ')' 
+1

Ich habe gerade dieses Problem erlebt, aber Berechtigungen waren bereits weltweit lesbar. Irgendwelche anderen Ideen auf Ursache oder Reparatur? – ken

+2

@ken siehe den Kommentar von James - stellen Sie sicher, dass Sie nicht einen Ordner, sondern einzelne Dateien zippen. – cyberwombat

+0

Ich schaute nur auf den Knoten-Lambda-Code und es scheint, dass es durch jede Datei im Code-Verzeichnis iteriert und fügt sie in eine einzige Zip. Eigentlich für Nicht-Windows schießt es auf native Zipping aber das gleiche Ergebnis. Es scheint keine Konfigurationsoption zu geben, aber eigentlich hätte ich gedacht, dass dies das richtige Verhalten ist. Ist es nicht? – ken