Allow for specification of custom code path

[LoneRifle]

In specific scenarios, a user may wish to override the code property used when instantiating the SingletonFunction for this Construct. ECRDeploymentProps should hence be changed to allow this.

Background

CloudFormation templates can be synthesized from CDK equivalents, though this synthesis is lossy. Specifically, since CloudFormation is purely declarative, we are unable to invoke an action unlike CDK.

As a result, a CDK deployment may be able to build the code needed for a Lambda, but this cannot be done in the synthesized CloudFormation equivalent. A workaround might be to reference the code as a Docker image in a private ECR, but the image has to be made available pre-deploy. Lambda also cannot refer to public ECR images, even with the use of pull-through caches.

This is problematic for a maintainer of a CloudFormation template intended for non-technical audiences, who may only be familiar with interacting with AWS through the console.

Proposal

As a workaround, the maintainer may wish to provide the Lambda code for cdk-ecr-deployment on a public S3 bucket, so that the construct is usable even in a synthesized CloudFormation template. This would need a change to the construct to accept an optional code property, which can be used to override the equivalent property in SingletonFunction.

[mrgrain]

Once you are overwriting the code prop, what benefits does this package even provide to you?

This is problematic for a maintainer of a CloudFormation template intended for non-technical audiences, who may only be familiar with interacting with AWS through the console.

I don't think this is a use case this package set out to support originally. Its main purpose is to publish images that have just been build using CDK to a well-known location. Can you describe more how the scenario you describe would work in practice? What images are copied from where to where? Where is the source image coming from and how is it build?

[LoneRifle]

Once you are overwriting the code prop, what benefits does this package even provide to you?

Allowing code to be specified allows me to host the bootstrap code found in this package within lambda/ somewhere else, specifically in a location supported by CloudFormation.

In the context of using synthesized CloudFormation, a maintainer would continue to benefit from the constructs in the package, that declares the lambda containing the relevant bootstrap code (only this time provided through public S3 bucket), as well as the custom resource that invokes it.

I don't think this is a use case this package set out to support originally. Its main purpose is to publish images that have just been build using CDK to a well-known location.

This is understood; the issue proposes making a change so that even if the CDK templates are synthesized, there is a path to allowing this to function.

I am happy to fork this repo with our own changes so that it serves our own intended purpose.

Can you describe more how the scenario you describe would work in practice? What images are copied from where to where? Where is the source image coming from and how is it build?

Our main use case is - through CloudFormation synthesized from CDK for reasons described earlier - to deploy a Lambda which uses a Docker image for its code.

The code for the Lambda has to be a Docker image as it requires additional binaries not usually found in the default Lambda environment. In turn, CloudFormation cannot build images, and requires Lambda docker images to be hosted on private ECR.

The source Docker image is to be found on Docker Hub, prebuilt for the CloudFormation template. Destination would be a private ECR declared in the template.

An alternate approach of building the image from source using CodeBuild (because we are severely limited by CloudFormation and hence cannot build directly) was considered, but rejected, since we wish to keep deploy times and moving parts to a minimum.