lambci / docker-lambda

Docker images and test runners that replicate the live AWS Lambda environment
MIT License
5.83k stars 431 forks source link

/var/rapid/init doesn't act the same in node12js.x and build-node12js.x images #310

Closed benze closed 3 years ago

benze commented 3 years ago

Hi,

I just started trying out the lambci/lambda images so might be doing something wrong. However, when I try to run an interactive shell in the two containers, I find that they don't act the same. With nothing mapped to the /var/task folder, I expect an error to be thrown if I try to run the lambda manually from within the container.

lambci/lambda:node12js.x This image is working as expected.

eric@XMEANT ~/dev/Projects/pdf/pdf-encrypt/.serverless/pdfEncrypt $ docker run --rm -it --entrypoint bash lambci/lambda:nodejs12.x
bash-4.2$ /var/rapid/init
2020-09-25T14:04:02.011Z        undefined       ERROR   Uncaught Exception      {"errorType":"Runtime.MalformedHandlerName","errorMessage":"Bad handler","stack":["Runtime.MalformedHandlerName: Bad handler","    at _splitHandlerString (/var/runtime/UserFunction.js:43:11)","    at Object.module.exports.load (/var/runtime/UserFunction.js:138:31)","    at Object.<anonymous> (/var/runtime/index.js:43:30)","    at Module._compile (internal/modules/cjs/loader.js:1137:30)","    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)","    at Module.load (internal/modules/cjs/loader.js:985:32)","    at Function.Module._load (internal/modules/cjs/loader.js:878:14)","    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)","    at internal/main/run_main_module.js:17:47"]}
START RequestId: 39c0aec6-1a39-1dc3-2f0d-5ebf578fcc8f Version: $LATEST
END RequestId: 39c0aec6-1a39-1dc3-2f0d-5ebf578fcc8f
REPORT RequestId: 39c0aec6-1a39-1dc3-2f0d-5ebf578fcc8f  Init Duration: 3827.89 ms       Duration: 5.52 ms       Billed Duration: 100 ms Memory Size: 1536 MB    Max Memory Used: 37 MB

{"errorType":"Runtime.MalformedHandlerName","errorMessage":"Bad handler"}

lambci/lambda:build-node12js.x However, if I try the exact same thing in the lambci/lambda:build-node12js.x image I get the following error message:

FATA[0000] Environment variable is not set               name=AWS_LAMBDA_FUNCTION_NAME

Running as user 994 (sbx_user1051) to ensure that the two containers are running the same. I've also tried running in different user contexts, but have the same result.

If I try to override the env variable, I then get a bad file descriptor error:

eric@XMEANT ~/dev/Projects/pdf/pdf-encrypt/build $ docker run -it --rm -u 994 lambci/lambda:build-nodejs12.x bash
bash-4.2$ /var/rapid/init
FATA[0000] Environment variable is not set               name=AWS_LAMBDA_FUNCTION_NAME
bash-4.2$ export AWS_LAMBDA_FUNCTION_NAME=test
bash-4.2$ /var/rapid/init
Failed to write to log, write a: bad file descriptor
bash-4.2$
bash-4.2$ /var/rapid/init
Failed to write to log, write a: bad file descriptor

I would have expected that both the runtime image and the build image would work the same. Am I doing something wrong, or is there a problem with the build image setup/config?

mhart commented 3 years ago

The build image is not intended for running lambdas, just building them

benze commented 3 years ago

@mhart That would definitely explain why I am running into issues.

With no tooling available by Visual Studio Code to launch as a devcontainer (ex: tar, ssh, gzip, etc), I've been trying to get the build container launched from within Visual Studio Code to run/test out the lambda as it is being built. But clearly that does not seem to work.

I guess the intent is to run the runtime container as a separate process, and only use the build container to build it then.

mhart commented 3 years ago

Yup, that's definitely the intent. Running in a build container would give a false sense of security because it has a lot more libraries and binaries installed on it than a real Lambda does.