Feature Request: Set ECR Lifecycle when deploying a lambda with a docker image

[concavegit]

I am followingthis guide to create a SAM template that deploys a lambda based on a Dockerfile. However, each sam deploy creates a new image, which causes me to pay for multiple old registries until I manually delete them. Is there a way to make a policy to retain only the past five containers, or even better the last 30 days of containers?

[gracelu0]

Hi @concavegit , this looks like a SAM CLI related question so I'll transfer this issue to the SAM CLI repo.

[lucashuy]

Thanks for raising this to us. How are your current images being uploaded to ECR? Are they being stored in an ECR repository that you control, or is this with the ECR repository that SAM CLI creates for you? If a custom ECR is being used, then its possible to define lifecycle (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecr-repository.html#cfn-ecr-repository-lifecyclepolicy) to manage older images. This solution may not consider images that are being used by functions, so please be aware.

Doing this automatically with SAM CLI might be out of scope for our tooling (namely requiring additional permissions, and having some kind of persistent background task), and might be better managed with other solutions.

Tagging as close-if-inactive as it seems unlikely for us to accept this.

[concavegit]

My images are being uploaded to ECR to the repository that SAM CLI creates for me. Blocked/close-if-inactive works for me, I just wanted to check if there is already a feature request I could track or if there was a solution I overlooked. I'll manually clean up my containers for now.

I don't think this will require significant additional permissions or any background task sinces ECR already supports a lifecycle policy.

[lucashuy]

Thanks for getting back. I've checked in with the team to see if there are other solutions that you or I have missed in this issue. It might be possible to write some custom logic that lives in a Lambda function to check and delete images based on a couple of conditions (eg. whether or not they are in use, age of image, number of images), but doing this automatically as part of SAM CLI might be out of scope.

I'll leave this issue open for now in case I have other solutions, or other readers have ideas.

[rsinsuranceagent]

Hi @lucashuy, I'm a little surprised by this thread.

SAM CLI already supports sam package bootstrap --create-image-repository and ERC supports lifecycle policies. Is it not a matter of adding another parameter specifying a lifecycle policy upon creation?

And if this is not a widely requested feature, can't @concavegit simply add the policy after bootstrapping (whether manually via the Console, or by editing the aws-sam-cli-managed-* stack template?

[concavegit]

Hello @rsinsuranceagent, ECR supports lifecycle policies, but ideally there is way to manage that rule in code rather than introduce stack drift. Editing the aws-sam-cli-managed is possible, but not automated.

[rsinsuranceagent]

@concavegit, yes, of course. Given that you were following a tutorial, I assumed you only wanted a solution to manually deleting.

If you are concerned about stack drift, edit the aws-sam-cli-managed-* template and execute a changeset.

If you are concerned about automation, use the AWS CLI or SDK to PutLifecyclePolicy.

If you are concerned about both (assuming this feature will not be developed in SAM CLI), create and deploy the ECR resource separately with your preferred lifecycle policy. It could be a separate or nested stack.

• If separate, define the Image Repository name or URI as an Output. Then get the value and reference it as the value in sam deploy --image-repository / --image-repositories (depending on how many functions you are deploying).
• If nested, define the Image Repository URI as a parameter that pass to your nested application, and the pass it to the ImageUri property in your function.

Let me know if this helps or not.

[concavegit]

@rsinsuranceagent Thanks, that helps. If there is a plan to configure the ECR repository in template.yaml, a lifecycle configuration key there will simplify the experience. In the meantime, I will use your suggestions.

[rsinsuranceagent]

@concavegit Given that the ECR repository is usually created separately using sam pipeline, the ideal scenario would be to define the lifecycle policy in this command, not in `template.yaml'. But, I get what you mean: to configure the policy as code, as a supported feature and not a workaround.

Hope it helps.