ECR repository/S3 Bucket of assets needs clean up

[DerkSchooltink]

Please +1 Garbage Collection RFC

Original title: (was Lifecycle support for DockerImageAssets)

It would be helpful to apply lifecycle rules for the ECR to which DockerImageAsset's are pushed to.

Use Case

Right now CDK automatically defines the repository and keeps all previous images stored in there. Because of rapid prototyping this causes a lot of images to build up. In order to save cost on storing these images and to declutter the interface from old unused images it would be neat to be able to define a lifecycle for these images.

Proposed Solution

Ideally it would be possible to define lifecycle rules for the DockerImageAsset itself, but exposing the Repository construct through DockerImageAsset#repository instead of the generic IRepository interface would also work:

import {DockerImageAsset} from "@aws-cdk/aws-ecr-assets";

const image = new DockerImageAsset(this, "Image", {
  directory: "path/to/dockerfile"
});

image.repository.addLifecycleRule({maxImageCount: 30})

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

---

This is a 🚀 Feature Request

[MrArnoldPalmer]

@rix0rrr @eladb, how does this fit into the "single repository : n images" strategy? Can we add a method that lets you add lifecycle rules at the image level (by targetting specific tags based on the assets unique ID perhaps?) in addition to exposing at the repository level?

[DerkSchooltink]

@rix0rrr @eladb, how does this fit into the "single repository : n images" strategy? Can we add a method that lets you add lifecycle rules at the image level (by targetting specific tags based on the assets unique ID perhaps?) in addition to exposing at the repository level?

What about exposing a field on DockerImageAsset that allows for defining a repository yourself? That allows us to create an ECR separately (with the lifecycle rules) and would not mess with the single repository setup.

Example:

const repository = new Repository(this, 'Repository');
repository.addLifecycleRule({maxImageCount: 5});

const image = new DockerImageAsset(this, "Image", {
    directory: "path/to/dockerfile",
    repository: repository
});

[MartinLoeper]

What about exposing a field on DockerImageAsset that allows for defining a repository yourself? That allows us to create an ECR separately (with the lifecycle rules) and would not mess with the single repository setup.

That sounds reasonable. We want to change the "scanOnPush" property and add lifecycle rules to the repository. I do not see how this is currently configurable.

[luxaritas]

Concurred - would also like to enable scanOnPush in addition to the lifecycle policy - retention policy too even! (Edit: looks like scan on push is automatically enabled for the cdk repository)

[peterjuras]

Any update on this?

[eladb]

The current way image assets work in the CDK implies that a single ECR repository is used for all asset images. You can use cdk-ecr-deployment in order to deploy image assets to a specific ECR repository in your control.

As for garbage collecting images from the assets ECR repository, this is something we plan to add at some point as part of a broader garbage collection capability (applies to buckets as well).

Please +1 this RFC if you want to see this prioritized: aws/aws-cdk-rfcs#64

[zacyang]

At least could we have the ScanOnPush configuration exposed?

[blimmer]

With the new dockerTagPrefix behavior (see https://github.com/aws/aws-cdk/pull/17028/files), you can kind of manually start to do this. For instance, you can tag your image with some recognizable prefix and then manually create a lifecycle rule. I agree that this should be built-in and "just work" per the RFC.

[jonathan-kosgei]

@rix0rrr is there any workaround for this? Our AWS bill is up significantly due to ECR storage.

[blimmer]

@jonathan-kosgei You might give https://github.com/jogold/cloudstructs/blob/master/src/toolkit-cleaner/README.md a try (see the linked RFC above for where I found this: aws/aws-cdk-rfcs#64 (comment)). That construct has worked well for me.

[joao-moonward]

Hello everyone! This issue seems quiet. Any feedback?

[MrArnoldPalmer]

No updates currently but there is a third party construct to help enable this for those that need something in the interim https://constructs.dev/packages/cloudstructs/v/0.6.18/api/ToolkitCleaner?lang=typescript

For tracking a built in solution aws/aws-cdk-rfcs#64 is the place to watch.

[arminnajafi]

I've been needing this feature too.

[evgenyka]

Closing in favor of aws/aws-cdk-rfcs#64

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[peterjuras]

@evgenyka is the implementation planned on the roadmap and is there an ETA? Closing in favor of an RFC does not inspire a lot of confidence that this feature will be prioritised.