Sam Package/Deploy --image-repository Behavior

[metaskills]

Many of the process I put in place for both open source and in company deploy pipelines take advantage of SAM CLI and the AWS CLI using conventions like AWS_PROFILE. I've been very happy that SAM CLI has followed these patterns. Today when working with the new container features I was surprised by this odd behavior of sam package when using the --image-repository option. Here is an example of my usage where the new image repo was added to my process.

sam package \
  --region ${AWS_DEFAULT_REGION} \
  --template-file ./.aws-sam/build/template.yaml \
  --output-template-file ./.aws-sam/build/packaged.yaml \
  --image-repository  "lambyc-starter" \
  --s3-bucket "${CLOUDFORMATION_BUCKET}" \
  --s3-prefix "lambyc-starter-${RAILS_ENV}"

These commands are run as either the default AWS_PROFILE or with specific ENV overrides. Given this was set and that the --region was set here, my expectation was this command was going to find and publish to the ECR repo within my AWS account. Instead, it tried to push to docker.io and failed with a user password. Digging into some guides and published SAM examples I can see what you expect folks to do is:

sam package \
  --region ${AWS_DEFAULT_REGION} \
  --template-file ./.aws-sam/build/template.yaml \
  --output-template-file ./.aws-sam/build/packaged.yaml \
  --image-repository  "123456789.dkr.ecr.us-east-1.amazonaws.com/lambyc-starter" \
  --s3-bucket "${CLOUDFORMATION_BUCKET}" \
  --s3-prefix "lambyc-starter-${RAILS_ENV}"

This feels like the wrong interface to me and against the grain of how the CLI operates given all my previous experiences. I can work around this if y'all disagree by adding more aws CLI commands to find the account ID and use the AWS_DEFAULT_REGION env and/or look that up as well. But it would cool if SAM did this. Thoughts?

[sriram-mv]

Thanks for reporting this!

For the issue it trying to upload to dockerhub: there is a fix out for that: #2439

One of the things that makes it harder to figure out the full URI with just a name is to construct the neccessary accountid, the way to do that would sts get-caller-identity (or what if you wanted to do cross account), which is additional permissions for users.

We are definitely exploring ways of making this better and a simpler experience! what did you have in mind?

[metaskills]

Thanks! For now I am doing this in my scripts wrapping sam package and deploy.

AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
IMAGE_REPOSITORY="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/myapp"

[stephenbawks]

The thing I was going to add here since I am little confused on the workflow. I was hoping to just create an ECR repository along with my Lambda but I do not see a way I can create that before it tries to upload the container when I do a deploy. So I guess I am just wondering with the way this works, do I need to have ECR created beforehand?

[sriram-mv]

@stephenbawks yes you need to have it created. we are definitely looking at ways of making this better, what did you have in mind? ECR repos per function? or one ECR repo for your entire stack?

[metaskills]

Right, a find/create on the ECR repository would be kind of helpful too.

[stephenbawks]

@sriram-mv We typically do a repo per app. Or in this case I guess I would use Stack or Function interchangeably.

[BR0kEN-]

Right now I found only this workflow operable:

# Create a repo or ignore the fail that it already exists.
aws ecr create-repository --repository-name my/repo || true
docker build -t 123459.dkr.ecr.eu-west-1.amazonaws.com/my/repo:latest .
docker login
docker push 123459.dkr.ecr.eu-west-1.amazonaws.com/my/repo:latest
# For a function defined as a container image, Lambda
# resolves the image tag to an image digest. In Amazon
# ECR, if you update the image tag to a new image, Lambda
# does not automatically update the function.
# See https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lambda.html#Lambda.Client.update_function_code
aws lambda update-image --function-name APP-FUNC-NAME --image-uri 123459.dkr.ecr.eu-west-1.amazonaws.com/my/repo:latest
# Wait for the `LastUpdateStatus` to be `Successful`
sam package
sam deploy

[mndeveci]

New option --image-repositories have been released with v1.14, resolving the issue.

[metaskills]

Thanks @mndeveci but I looked over that work and it seems neat but does not address any of the points I brought up here. Instead it looked to focus on mapping multiple functions to a distinct ECR repository. Perhaps re-open this one?

[metaskills]

I was hoping to just create an ECR repository along with my Lambda but I do not see a way I can create that before it tries to upload the container when I do a deploy.

I'm not sure that will work. I just discovered today that creating an ECR repo takes a few minutes till it can be deployed to.
Correction, mistake on my end. Creating a repo is quick and easy.

That said, my original request still stands... hoping for a short hand version to be supported where it assumes the same account and maybe region. That would satisfy this issues point. Auto create would be cool too.