Allowing provided runtime to work.

[atrope]

This should fix #570

How to test:

YML:

service: localTest # NOTE: update this with your service name
plugins:
  - serverless-offline
provider:
  name: aws
  runtime: provided
functions:
  hello:
    handler: index.php
    layers:
      - arn:aws:lambda:us-east-1:209497400698:layer:php-72-fpm:6
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

index.php:

Can be anything for example:
Hello <?php echo $_GET['name'] ?? "World";?>

sls offline will work now.

This is a first approach.
I see lots of ways to improve like reusing the same container and not having to rebuild each and every request.
Comments and tests with another layers are always welcome.

[mnapoli]

That works so well, thank you @atrope!

Here is an example:

$ serverless offline
Serverless: Starting Offline: dev/us-east-1.

Serverless: Routes for website:
Serverless: ANY /
Serverless: ANY /{proxy*}
Serverless: POST /{apiVersion}/functions/bref-demo-laravel-dev-website/invocations

Serverless: Offline listening on http://localhost:3000

Serverless: ANY / (λ: website)
Serverless: Downloading layer arn:aws:lambda:us-east-1:209497400698:layer:php-73-fpm:6...

Serverless: Building Docker image...

START RequestId: 52fdfc07-2182-154f-163f-5f0f9a621d72 Version: $LATEST

END RequestId: 52fdfc07-2182-154f-163f-5f0f9a621d72
REPORT RequestId: 52fdfc07-2182-154f-163f-5f0f9a621d72	Init Duration: 354.30 ms	Duration: 2566.91 ms	Billed Duration: 2600 ms	Memory Size: 1536 MB	Max Memory Used: 50 MB

This change is quite small, hopefully it should be safe to merge :) @atrope there is however a small conflict to fix for the PR to be mergeable.

Folks at https://github.com/brefphp/bref are eager to migrate from SAM to Serverless and this plugin is the last missing piece.

[atrope]

@mnapoli updated the PR and all checks passed. @dherault can you take a look?

[dnalborczyk]

hey @atrope sorry for not having followed up on this. if I remember correctly, the problem is that the "provided" option already (kind of) works (or, at least, it's being ignored and uses whatever runtime is specified in a separate custom parameter: providedRuntime) that would probably break that functionality with the current PR.

I wonder if we should introduce a custom parameter, and have it not tied to provided runtimes? since it's mainly used to invoke that proxy handler, which I assume was meant for python and ruby, and those are determined by the provider.runtime option, for which docker wouldn't be a valid value (as far as AWS is concerned).

thinking about it, what we could do maybe is to add docker as a providedRuntime option?

e.g.

providedRuntime: docker

that would give us also an escape route for a possible future "provided runtime" implementation (which is not tied to docker, or any container technology).

@dherault @atrope thoughts?

[mnapoli]

@dnalborczyk maybe I understand things wrong, but with what you suggest we would have to set an extra option to make it work?

What is the need behind those not-actually-provided runtimes? I've tried reading the code and the discussions but I can't get my head around it.

[dnalborczyk]

hey @mnapoli no problem. let me explain (keep in mind I don't know Python or Ruby, so everything below is from the point of view of a node.js user):

before provided runtimes (and custom layers) were a thing, serverless and serverless offline would do the following, e.g.:

# serverless.yml
provider:
  runtime: nodejs8.10 # or: python3.7 / ruby2.5 etc.

serverless uses this value for deployments (cloudformation), or executing locally, and serverless-offline would use it to determine on how to run the lambda handler. either with node.js "natively" (the host of the plugin), or to spin up another process for python or ruby.

now enter provided runtimes:

# serverless.yml
provider:
  runtime: provided

serverless-offline didn't know about provided, and didn't know what to do, and rejected it (at that time). so I came up with the idea of letting serverless-offline indirectly know what to do, with a custom (plugin) parameter, which @dherault implemented as providedRuntime, e.g.:

# serverless.yml
provider:
  runtime: provided

custom:
  serverless-offline:
    providedRuntime: nodejs

in that case serverless deployments would still work, and serverless-offline knew how to run the handler as well.

if we merge the PR as is, providedRuntime would be ignored. so people would be forced to go with the docker container approach.

to circumvent this problem, and still give people to run a custom docker container, I thought instead of adding yet another additional custom parameter, we re-use the providedRuntime parameter for this purpose, e.g.:

# serverless.yml
provider:
  runtime: provided

custom:
  serverless-offline:
    providedRuntime: docker

in that case, serverless-offline would know what to do again, or better, it wouldn't even care, since it's a docker container, one could run anything on it (Rust, C, Bash, PHP).

does that clear it up a bit? @mnapoli

[dnalborczyk]

What is the need behind those not-actually-provided runtimes?

from a node.js developer perspective: I can keep using the current setup: "native" node. easier development, debugging, etc.

why then use provided in the first place you might ask? AWS is usually behind in the support of their runtimes. e.g. recently they started supporting v10, not too long ago it was v8 -- but the latest is v12 (better performance, newer JavaScript syntax, memory consumption, API changes, etc.)

I heard also rumors that provided runtimes will be the way to go and aws supported runtimes will eventually be phased out. but if that will ever happen I guess time will tell.

[dnalborczyk]

on a different note, since I read through your issue: brefphp/bref#320

it might as well be possible to add PHP support to this plugin, similar to Python and Ruby, but I have no idea what that would need to entail. @dherault might have some ideas.

that is not to say we shouldn't pull in this PR, which would still support essentially anything running on docker (not only PHP).

[dherault]

Or you could implement the PHP runtime for serverless-offline, similar to Python and Ruby.

[mnapoli]

@dnalborczyk thank you very much for all the explanation, that makes much more sense now!

serverless invoke has the --docker option to use Docker. Maybe it would make sense to reuse the same flag here? That way it is consistent, and we avoid a custom parameter that people have to learn.

Do you think it would solve the problem here?

Or you could implement the PHP runtime for serverless-offline, similar to Python and Ruby.

Python and Ruby and runtimes officially supported by serverless invoke local (because they are official runtimes). PHP is not an official runtime for Lambda, so we can't just "add support for PHP" as there is no such runtime. Instead we use layers, and there's an infinite number of layers. Provided runtimes are supported via the --docker flag because the Docker implementation supports layers.

[dnalborczyk]

@atrope @mnapoli I removed the --providedRuntime option in v6, more info here: #768

with this change we could bring back the docker runtime option. (this PR)

[dherault]

Closing because 1yo now.

[hayd]

Really sad to see this not make it in. Would be a great feature.

[AlbertMarashi]

This fixed my problem

provider:
  name: aws
  runtime: provided

custom:
  serverless-offline:
    useDocker: true #this enables the use of docker and downloads your layers
  
functions:
  web:
    handler: handler.hello
    events:
        - http:
            path: /{any+} # this matches any path, the token 'any' doesn't mean anything special
            method: ANY

    layers:
      - arn:aws:lambda:ap-southeast-2:239930134035:layer:node-14-runtime:9 #add your custom layer here