8
votes

The situation is that I have a load of aws lambda functions (using node js 8.10) that all do something very different and they're all deployed using CloudFormation.

They all share a few functions which are very complex.

At the moment, if the common code changes, which is fairly frequent, I replicate the common code between each of the projects (including source control) and then redeploy each of the functions. This has always felt wrong.

Now we have lambda layers - yay! or yay?

Great, so now I can maintain the code in a single repo - tick But the rest of the process is not really any better and possibly worse...

If I put the layer in a CloudFormation template and export the ARN for import into the lambda function templates then the exported ARN is only ever for version 1 of the layer.

I could form the ARN without the version using the Sub function and then add the version in the lamda function CloudFormation templates. But, whenever there's a change to the common code, I'd still need to update all downstream lambda function CloudFormation templates to add the latest version.

I could script it but it's still a massive PITA and doesn't really save much effort. I'd need to get the latest of each lambda function project update the version number, commit back to the repo, pr, merge, blah blah blah.

Is there no other way of always using the latest version of a layer?

2
What language are you using?Noel Llevares
using node js 8.10Russell Keane
You can use mappings in the cloud formation template. It makes things easy to maintain a variable value all over the template. Such as the lambda layer version, you can add the version in the mappings json and use it in multiple lambda functions. If the layer version changes then you just need to update the value in the mappings (one place) and not the whole document.Diksha Tekriwal
Thanks Tekriwal. This definitely makes the template clearer but would this help with the deployment? I.e. if the variable were to be updated to point to a new version of the layer, would cloudformation see it as a change and update the lambda accordingly? Something for me to try I think...Russell Keane

2 Answers

2
votes

Using Serverless to deploy and CloudFormation Outputs can help with this situation.

  1. Define your layer in it's own service. Create an Output resource (but don't create an export name).
resources:
  Outputs:
    MYOUTPUTNAME:
      Value:
        Ref: MYLAYERLambdaLayer # LambdaLayer is a required suffix
  1. Reference the output as the layer for whatever function requires it
functions:
  ...other required function keys in serverless
  layers:
    - ${cf:NAME_OF_STACK.MYOUTPUTNAME}
  1. Anytime you redeploy the layer, you must force redeploy the entire stack of functions that reference the layer (sls deploy --force). Redeploying just the function will not update the output reference.

Note: if you use Output Export Names, you will run into an error redeploying the layer service as the current version is referenced. Therefore, it's better to use a reference to the stack output which doesn't cause this error.

0
votes

You can create along with your lambda layer a parameter in parameter store:

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html

This will follow your ARN along with the version, I created both resources (lambda layer and parameter) in the same stack.