aws-lambda: rewrite handler name for provided.al2

[rittneje]

Describe the feature

If a Lambda function is using the provided.al2 runtime, and has specified a handler other than "bootstrap", CDK should rename the handler file while creating the zip, unless there is also a file named "bootstrap".

It is acceptable but undesirable if an additional flag is needed to enable this behavior.

Use Case

If a repository houses multiple Go lambdas, naming all the binaries "bootstrap" as the provided.al2 requires is non-trivial. It would be better if CDK could just fix things automatically to work around the runtime's restriction.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.85.0

Environment details (OS name and version, etc.)

Alpine 3.18

[pahud]

Can you share your full CDK code for the lambda function?

I am not sure if it's a good idea to allow CDK to "rename" the user file.

[valerena]

The provided.al2 runtime is not only used for Go, but it can also be used for other custom runtimes (that's its original purpose) where the bootstrap file might be in an external Layer, so it doesn't really make sense to modify the existing files in your deployment package just to fit the Go use case.

I imagine that at most it could be an extra flag or method that needs to be called to have that behavior.

[rittneje]

@valerena for such use cases the handler name would still be “bootstrap” so there is no impact. No extra flag is needed.

[valerena]

@rittneje That's not correct.

It's true that for custom runtimes Lambda always calls an executable called bootstrap initially, but that doesn't mean that the handler property has to be bootstrap.

If you actually use a custom runtime in Lambda (let's say, Bash or PHP), the handler field will actually be used to decide what file/method your custom runtime will execute. Lambda calls a bootstrap file that's part of the runtime, so your own code doesn't need a file called bootstrap either (it will probably be inside a layer).

The fact that in Go your file needs to be bootstrap (and the handler value configured is bootstrap too) is because of the fact that there's no "separate runtime", but in the general case, neither of those need to be called like that.

[rittneje]

@valerena It sounds like you are implying we can resolve this annoyance for by making a "fake" bootstrap script that just execs "${_HANDLER}" (or something like that) and put that in some shared lambda layer. Is that right?

[valerena]

Unfortunately it's not that easy, because the Go executable is actually doing more than just "running" (it's starting a whole process that can handle multiple executions in a row interacting with Lambda Runtime API), it's actually "a custom runtime" but all included in the binary (that functionality coming from github.com/aws/aws-lambda-go/lambda).

(It doesn't seem like a CDK question anymore, so I don't want to extend this too much) I think your initial suggestion is the right way to solve something like this, but you would have to implement it yourself for your use case instead of it being part of CDK.

[rittneje]

For anyone else that hits this issue, we were able to work around this flaw by creating a shell script named bootstrap like so:

#!/bin/sh

set -euo pipefail

exec "${PWD}/${_HANDLER}"

Note that the shell script must be executable.

[FavourOkonta]

this helps alot @rittneje

[chungryan]

Lifesaver @rittneje !