Proposal: docker compose push with AWS context

[riwiki]

This proposal is twofold:

• manage ECR resources within docker compose
• easily tag and push images via docker compose, when in AWS context

Current solution:

• provision ECR resources with external tools, e.g. terraform
• inject the ECR resource URL into the docker-compose.yml to prefix each image name with the ECR's FQDN; or hard code
• run aws ecr get-login prior to docker-compose push

Proposed usage:

x-aws-ecr: "my-app"
services:
  app:
    image: my-app:latest
    ports:
      - 80:80
  external-app:
     image: nginx/nginx

docker context create ecs myecscontext
docker compose build

This creates an image named <accountnumber>.dkr.ecr.<region>.amazonaws.com/my-app:latest

docker compose push

This will push the image to the above registry.

It requires further IAM permissions next to the documented ones: https://docs.docker.com/cloud/ecs-integration/#requirements

Even though ECS and ECR are different services, they are often used in conjunction. Currently, the ECS composer documentation does not name any details on how to publish built images, but silently assumes they are already available somewhere.

There might need to be a mechanism in place to determine which services are targeted towards an ECR, and which are not. Maybe the x-aws-ecr attribute should become a direct service attribute.

[riwiki]

Just noted that docker compose up will create resources, so the first part of the proposal (creating the ECR resource) might not be feasible, as the ECR already needs to exist at build and push time, in order to name and send the image.
Maybe the second part of the proposal is independent of this. Even when the ECR is provisioned externally, we can help in naming/tagging the built image correctly. This requires that docker compose resolves the ECR name to the FQDN given the AWS context. The push operation can be improved by automating the required aws ecr get-login operation.

[ndeloof]

👎 to ensure compose model portability, if your service declares image: my-app:latest then image should not be replaced by an ECR one, so that you can run compose up on local development workstation with the same image.

If you prefer pushing to ECR vs DockerHub, use fully qualified image URL. Tip: to avoid hardcoding your account and region, you can use variables here: image: $AWS_ACCOUNT.dkr.ecr.$AWS_REGION.amazonaws.com/my-app:latest

We also don't want to get more non-portable custom x-aws-* extensions introduced in the compose model (extensions have been define to allow experimenting new features that would eventually become standard by compose spec, not to build a higher-level aws model on top of the compose one, see #1411)

[ndeloof]

closing as rejected