# Invoke Local and Layers

**URL:** <https://forum.serverless.com/t/invoke-local-and-layers/7963>\
**Category:** Serverless Framework\
**Created:** [April 11, 2019, 1:37pm UTC](https://forum.serverless.com/t/invoke-local-and-layers/7963 "2019-04-11T13:37:39Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mhaley-miovision](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/mhaley-miovision/32/4068_2.png) [@mhaley-miovision](https://forum.serverless.com/u/mhaley-miovision)\
**Post date:** [April 11, 2019, 1:37pm UTC](https://forum.serverless.com/t/invoke-local-and-layers/7963/1 "2019-04-11T13:37:39Z")

</div>

I have a very basic python project with a single layer. When running `serverless invoke local --function hello` or `serverless invoke local --docker --function hello` I get `ModuleNotFoundError: No module named 'scipy'`. Does serverless support layers with invoke local? I have seen some evidence that it does not, but there is no active github issue and all I have seen is

> [@Lambda Layers & Node & require the layer code & sls invoke local](http://forum.serverless.com/t/lambda-layers-node-require-the-layer-code-sls-invoke-local/6673/8):
>
> Yeah, invoke local is tricky. We’re still figuring out how best to make layers work with that.

and this claims to have implemented it using docker in v1.39.0 (I am on v1.40.0)

> <https://github.com/serverless/serverless/pull/5863>
>
> This is a work in progress for implementing docker based invoke local support. 
> …
> 
> \*\*Feedback greatly appreciated\*\*
> 
> \## What did you implement:
> Closes #5848 by using docker with the \[docker-lambda images from lambci\](https://github.com/lambci/docker-lambda).
> Closes #3456
> 
> The main benefits are:
> \* More runtimes supported, even \`provided\`!
> \* Layers support
> \* runtime environments more closely resemble real lambda env
> \* logging environment
> \* paths (your handler is actually run at \`/var/task\`)
> \* linux (as opposed to host OS)
> 
> The feature is currently implemented by default for previously unsupported runtimes, and can be enabled for python/javascript/java/ruby with the the \`--docker\` flag.
> \<!--
> Briefly describe the feature if no issue exists for this PR
> \--\>
> 
> \## How did you implement it:
> \* local layers are resolved by traversing the \`Ref\` and arn based layers are downloaded and extracted into \`.serverless/invokeLocal/layers/\<layername\>\`.
> \* generate \`.serverless/invokeLocal/Dockerfile\` with a \`FROM\` that bases it on \`lambci/lambda:${runtime}\` and then \`ADD\`s each layer to \`/opt\`
> \* build said \`Dockerfile\`
> \* run the image with working dir mounted as \`/var/task\` and passing the lambda and event as the arguments
> 
> \<!--
> If this is a nontrivial change please briefly describe your implementation so its easy for us to understand and review your code.
> \--\>
> 
> \## How can we verify it:
> \* install with \`npm i -g serverless/serverless#invoke-local-docker\`
> \* create an aws project
> \* \`sls invoke local -f hello --docker\`
> \* add a layer and try to use it again!
> \<!--
> Add any applicable config, commands, screenshots or other resources
> to make it easy for us to verify this works. The easier you make it for us
> to review a PR, the faster we can review and merge it.
> 
> Examples:
> \* serverless.yml - Fully functioning to easily deploy changes
> \* Screenshots - Showing the difference between your output and the master
> \* Cloud Configuration - List cloud resources and show that the correct configuration is in place (e.g. AWS CLI commands)
> \* Other - Anything else that comes to mind to help us evaluate
> \--\>
> 
> \## Todos:
> 
> \- \[x\] Write tests
> \- \[x\] Write documentation
> \- \[x\] Fix linting errors
> \- \[x\] Make sure code coverage hasn't dropped
> \- \[x\] Provide verification config / commands / resources
> \- \[x\] Enable "Allow edits from maintainers" for this PR
> \- \[x\] Update the messages below
> 
> \*\*\*Is this ready for review?:\*\*\* NO
> \*\*\*Is it a breaking change?:\*\*\* NO

My serverless.yml looks like

> ```
> service: my-service
> 
> provider:
> name: aws
> runtime: python3.7
> 
> functions:
> hello:
> handler: handler.hello
> layers:
> - arn:aws:lambda:us-east-1:XXXXXXX:layer:AWSLambda-Python36-SciPy1x:2
> 
> ```

And the handler looks like

> ```
> import json
> import scipy
> 
> def hello(event, context):
> body = {
> "message": "Go Serverless v1.0! Your function executed successfully!",
> "input": event
> }
> 
> response = {
> "statusCode": 200,
> "body": json.dumps(body)
> }
> 
> return response
> 
> # Use this code if you don't use the http event with the LAMBDA-PROXY
> # integration
> """
> return {
> "message": "Go Serverless v1.0! Your function executed successfully!",
> "event": event
> }
> """
> 
> ```

---

<div class="post-metadata">

**Author:** ![mhaley-miovision](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/mhaley-miovision/32/4068_2.png) [@mhaley-miovision](https://forum.serverless.com/u/mhaley-miovision)\
**Post date:** [April 29, 2019, 1:13pm UTC](https://forum.serverless.com/t/invoke-local-and-layers/7963/2 "2019-04-29T13:13:48Z")

</div>

Does no one have any experience using using layers? I have ended up using [AWS SAM](https://github.com/awslabs/serverless-application-model) for my application. It’s a very light wrapper around cloudformation and lambda and is easy to understand what it is doing. There were a couple small gotchas with it (building your own layers is not fully supported by the tool), but overall seems to work a lot nicer in the AWS ecosystem, and **does** support running layers locally right out of the box.

---

<div class="post-metadata">

**Author:** ![ltomes](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/ltomes/32/4067_2.png) [@ltomes](https://forum.serverless.com/u/ltomes)\
**Post date:** [March 20, 2020, 1:48pm UTC](https://forum.serverless.com/t/invoke-local-and-layers/7963/3 "2020-03-20T13:48:51Z")

</div>

So you ditched serverless to go with AWS SAM?  
11 Months later are you happy with your local development ecosystem? Would you recommend going with SAM over serverless?

---

<div class="post-metadata">

**Author:** ![mhaley-miovision](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/mhaley-miovision/32/4068_2.png) [@mhaley-miovision](https://forum.serverless.com/u/mhaley-miovision)\
**Post date:** [March 20, 2020, 2:13pm UTC](https://forum.serverless.com/t/invoke-local-and-layers/7963/4 "2020-03-20T14:13:08Z")

</div>

Hi @ltomes,

11 months later and, no we are still not entirely happy with our serverless setup. To be honest we have not put that much time and effort behind it, but the main blocker for us is that all of these tools (serverless + aws sam) use cloudformation to manage the functions at the end of the day, which makes it very difficult for us to standup lambdas when all of our other infrastructure is defined in terraform scripts. To get around this right now we are using paramater store and secrets manager to pass values from terraform such as database names or kinesis stream names into our sam templates. It works, but it is very clunky and easy to mess up.

My latest thinking on the matter has been to just standup “blank” functions using terraform, with all the associated environment variables and lambda config/permissions in place and then use a CD tool to drop our code in place. Yeah we miss some of the nice things that we get from SAM, but at the end of the day it is just cloud formation, so we could easily still take advantage of the macros/templates that SAM has added to cloudformation by setting up a stack ourselves in terraform.

Hope that helps give you some more context on the matter.

---

<div class="post-metadata">

**Author:** ![otaviopires](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/otaviopires/32/5521_2.png) [@otaviopires](https://forum.serverless.com/u/otaviopires)\
**Post date:** [April 8, 2021, 8:48pm UTC](https://forum.serverless.com/t/invoke-local-and-layers/7963/5 "2021-04-08T20:48:31Z")

</div>

Hey there! Having a similar issue here.  
Trying to user chrome-aws-lambda layer to run a nodejs puppeteer function locally using docker:

```auto
# serverless invoke local --docker -f server --path lib/ace.json
Serverless: Deprecation warning: Resolution of lambda version hashes was improved with better algorithm, which will be used in next major release.
            Switch to it now by setting "provider.lambdaHashingVersion" to "20201221"
            More Info: https://www.serverless.com/framework/docs/deprecations/#LAMBDA_HASHING_VERSION_V2
Serverless: Packaging service...
Serverless: Excluding development dependencies...
START RequestId: 48c647e8-b4de-118d-f1f6-1e1223bbcced Version: $LATEST
2021-04-08T20:43:40.289Z 48c647e8-b4de-118d-f1f6-1e1223bbcced INFO Error setting browser: Error: Could not find browser revision 800071. Run "PUPPETEER_PRODUCT=firefox npm install" or "PUPPETEER_PRODUCT=firefox yarn install" to download a supported Firefox browser binary.
    at ChromeLauncher.launch (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/node/Launcher.js:86:23)
    at Puppeteer.launch (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Puppeteer.js:97:31)
    at PuppeteerExtra.launch (/var/task/node_modules/puppeteer-extra/dist/index.cjs.js:129:41)
END RequestId: 48c647e8-b4de-118d-f1f6-1e1223bbcced
REPORT RequestId: 48c647e8-b4de-118d-f1f6-1e1223bbcced Init Duration: 361.59 ms Duration: 54.86 ms Billed Duration: 55 ms Memory Size: 10240 MB Max Memory Used: 73 MB

{"statusCode":400,"headers":{"x-powered-by":"Express","content-type":"application/json; charset=utf-8","content-length":"57","etag":"W/\"39-waPTIQOAeRulfrozS5mP5YjHz8M\""},"isBase64Encoded":false,"body":"{\"message\":\"Cannot read property 'newPage' of undefined\"}"}

```