AWS CDK update lambda function code when code is referenced by ECR image

1
votes

I have a Lambda stack that sits in a repo separate from the Lambda code itself. The Lambda code is packaged and deployed to ECR as a docker image, then the separate Lambda stack references the code as a DockerImageFunction using the aws_lambda.DockerImageCode.from_ecr() method. This seemed to have deployed the initial function correctly, but after publishing a new image of the Lambda code to ECR and then running cdk deploy from the repo with the Lambda stack, it just says that no differences were found. How do I reference my Lambda code in a way that when the constructs are deployed it sees that the code has changed and updates the Lambda function code (like a aws lambda update-function-code cli call would do)? I've done it before using a code Asset referencing the code local to the Lambda stack (as in, in the same repository), but how does one get a stack to recognize changes in Lambda code when the code isn't referenced as a local Asset?

I realize there is some debate over whether to organize stacks in mono repos or in separate repos with any application code they are responsible for deploying, but for the sake of this discussion I'm more interested in how one would accomplish the updating of Lambda functions when the stack is separate from the code.

1
amazon-web-servicesaws-lambdaaws-cdk

1 Answers

2
votes

Probably you are landing in the infamous Docker "latest" tag issue.

See:

Meaning that if you don't specify a "tag" for your Docker image explicitly, all of your infrastructures, by default, will assume that you are trying to deploy a Lambda that uses the your-image-name:latest image name. Given that this reference (as a string) does never change, regardless of the fact that you push a new image to the ECR, your Lambda deployment will never understand that something changed inside the "latest" tag.

What I would suggest is, instead of pushing on top of the "latest" tag, whenever you change the codebase, push it always to a brand new and immutable tag (e.g. the current timestamp). Then, push the tag as a reference to predictably-named Parameter Store entry (e.g. /myproduct/lambdaNameHere/tagName). Later you can "read" that tag in your Lambda infrastructure, which will now see that there are changes (previous Lambda version was referring to one image+tag combination, but now is referring to a different image+tag combination).