Repository options for `--resolve-image-repos`

[mschilde]

Describe your idea/feature/enhancement

I have a lambda function that runs dockerized. I would like to programmatically set up and manage the corresponding ECR repository.

Maybe I'm missing something, but it looks like sam does not allow an AWS::ECR::Repository resource in the same template that defines the lambda function. You have to either create the repository outside or use the --resolve-image-repos flag.

If I create the repository elsewhere I have to manually provide the URI to the sam configuration. If I use the --resolve-image-repos I can't specify any details of the repository (e.g. lifecycle policy).

Proposal

I'd be happy with either solution:

1) allow configuration of additional repository options when using the --resolve-image-repos flag (lifecycle policies etc)

or

2) extend sam to allow inline definitions and reference of an ECR repository, e.g.

Resources:
  LambdaECR:
    Type: AWS::ECR::Repository
[...]

  LambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      PackageType: Image
      Architectures:
        - x86_64
      ImageUri: !GetAtt LambdaECR.RepositoryUri
[...]

[CoshUS]

Thanks for the feature request! We will look into option 1 so that --resolve-image-repos will work with --image-repository or --image-repositories. As for option 2, images must be uploaded to ECR repos before the stack is created which means the ECR repo cannot be reside in the same stack as the function.

[tbenbrahim]

I do not understand why this even has to be specified on the command line, when my template clearly defines the image to use for the lambda. Why is this not necessary with CloudFormation deploy?

[trpubins]

I agree with @tbenbrahim. I already specify the ImageUri in the template so why do I need to specify again on the command line using --image-repository option? The expected behavior would be to only specify this once and ideally inside the template instead of the command line.

[sriram-mv]

Related: https://github.com/aws/aws-sam-cli/issues/3786

[oshaughnessy]

Perhaps another way to think about this is that, fundamentally, SAM needs better lifecycle management for the images it publishes. It has a lot of context available -- it knows the ECR repo they go to, it knows when new images are uploaded, it knows when the Lambdas that reference them are being updated and the old images are being swapped out. Perhaps it can do something intelligent with all of that and set a good default lifecycle policy, or do something more aggressive and offer to do cleanup for images after a deployment.

Removing untagged images would be an easy lifecycle policy, since SAM never uploads them that way (that I've seen), so any that are there are probably abandoned or mistaken uploads. Removing any images other than the newest and the one just replaced (or N last images?) in a Lambda would be a cool feature, and something SAM would have context for, too. It would need an explicit bit of code instead of a lifecycle policy, but a post-deploy cleanup step would keep the managed repo very tidy.

[oshaughnessy]

Just checking in on this to re-register my interest in a solution. Paying attention to Amazon Inspector makes an inability to autoclean obsolete images more of an issue. Ideally, SAM would manage its own repos in a way that encourages relevant reporting from Inspector. When old images are still around, it clutters the reports from Inspector and it's hard to identify when a CVE has been resolved.