containers-roadmap
containers-roadmap copied to clipboard
aws
[ECR] [request]: support custom domains, or alternate URIs for repositories
Tell us about your request
Currently a repository URI looks like this: <account_id>.dkr.ecr.<region>.amazonaws.com/<repository>. Account ID and region might be movable parts which has negative effects for the following scenarios described. It would be helpful to be able to define an alternate URI for ECR repositories.
Which service(s) is this request for? ECR, (.. and maybe other container services?)
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Our team provides a docker image for ~12 other teams that acts as a build tool for frontend resources within their pipelines. We identified different disaster recovery scenarios where the current ECR URI is a disadvantage:
(1) Unavailability of ECR within the specified region
- For this case all teams would have to change the URI of our repository or won`t be able to deploy frontend resources instead, until ECR is reachable again.
(2) Disaster recovery for the ECR account
- When the account which contains the ECR repository is (e.g.) compromised or we have to do a complete disaster recovery for other reasons, then all teams would have to change the URI of our repository. This is a dependency we could prevent..
An alternate repository URI could be a fixed interface for other consumers. Changes for account ID or region behind this part would not affect them anymore.
Are you currently working around this issue? One way we had seen to "solve" this, is to use an nginx as reverse proxy for the ECR, but this is an effort we don`t want to practice.
Additional context This topic from January 2016 also describes some pain points with this.
Attachments
- none
all my docker images have an ARG for the account id, so i can and do easily replace it to point to different accounts
all my docker images have an ARG for the account id, so i can and do easily replace it to point to different accounts
This is fine if you are the only consumer - but with dependencies to around 12 other teams, you would always have to share this, even this could be solved more easily.
This is a great idea, and it's something we've planned for as we made other networking changes such as VPC Endpoint support. We see a bunch of additional benefits. For example, your developers will be able to use a friendly URI like "repo.mycompany.com" instead of having to remember an AWS account number. Also, if you run your own registry today, and you want to switch to ECR so that you don't have to manage (upgrade, monitor, scale, etc.) it, then DNS might help with the transition.
We are interested in hearing more about how customers would like to manage SSL certificates and DNS. Would you use AWS Certificate Manager (ACM) for certs? Would you create a Route 53 hosted zone for the subdomain?
@jtoberon
if you run your own registry today, and you want to switch to ECR ...., then DNS might help with the transition.
^ This is exactly the scenario we are in. If ECR supported custom DNS the switch would be relatively painless. Without custom DNS, there are a number of pain points:
- We will need to open up a ton of PRs to change Dockerfile FROM values.
- We will have to decide if we want to rewrite GIT history so older images can be built (rewriting GIT history is very cringy but so is having a repo history filled with Dockerfiles that won't be able to build)
- We could circumvent the problem above by running our older registry in parallel to ECR but that ... also sucks.
And all of that is on top of the wacky authentication requirements for ECR. Y'all are not helping folks with established (but standard) authentication workflows or existing registries. The pain level goes up with the scale of the established operation. But those big registry users also seem like they would be the juicier targets for y'all, right?
@okor Currently, we're tentatively planning to work on this after cross region replication. What established authentication workflows do you have in mind?
When is the work going to start on this? Interested to contribute to make this live. ✋
Have to dog pile on this one.
I too have wanted this to be officially supported for awhile.
It is possible with an NGinx proxy.
- https://itnext.io/enable-aws-elastic-container-registry-custom-domain-and-anonymous-access-over-private-network-123d07663709
Or API gateway + lambda
- https://github.com/monken/aws-ecr-public
NOTE: you can't use the standard docker credential helper however, it has a regex that expects the default repo URIs
- https://github.com/awslabs/amazon-ecr-credential-helper
It looks like this was already requested back in early 2016 here: https://forums.aws.amazon.com/thread.jspa?threadID=223934&start=25&tstart=0
But unfortunately, the team at Amazon have been very quiet about when we can expect a fix for this.
+1. We'd like to use ACM for the cert, but probably not route53 for DNS and instead cloudflare (simply because that's what we already do for the domain).
+1
This would definitely be very useful and would save our repositories and documentations from getting cluttered with a long ECR URL that has an account number in it.
+1
(Purposefully not leaving a reaction, as I want to get notified when this is updated.)
You can subscribe to the issue to receive notifications instead of commenting.
Putting a CloudFront distribution in front of ECR should work fine, right?
Progress in your life or mine?
2021년 6월 29일 (화) 오후 8:03, Jim Brännlund @.***>님이 작성:
Almost 2 years have passed. Is there any progress being made?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/aws/containers-roadmap/issues/299#issuecomment-870497053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIJ4YQEOHK27MONER47L64DTVGSB5ANCNFSM4HN7TGDA .
-- [image: photo] Charlie Park Founder, Komachine A Yongin City, Gyeonggido, South Korea (17015) O +82-31-335-9901 <+82-31-335-9901> M +82-10-8218-7270 <+82-10-8218-7270> E @.*** @.***> W www.komachine.com
I'll ask again: What's the issue with using cloudfront using ECR as an origin?
I'll ask again: What's the issue with using cloudfront using ECR as an origin?
Spinning up a non-trivial piece of infrastructure to use 5% of its functionality is not an answer.
Spinning up a non-trivial piece of infrastructure to use 5% of its functionality is not an answer.
There's nothing to spin-up, cloudfront is a hosted service. And one of its main features is exactly what's being asked here.
If AWS added support for custom-domains for ECR registries, I can't image it'd be much less work than configuring cloudfront anyway -- you'd still have to address things like provisioning ACM certificates and creating Route53 records. There's not much more than 30-60 minutes of work here.
I'm not sure what you're expecting: it sound like all the tools are right there and what you actually need is someone to set them up for you.
There's nothing to spin-up, cloudfront is a hosted service. And one of its main features is exactly what's being asked here.
If you want caching and geo-distribution sure. But if all you want is a domain, you're spinning up service with non-trivial deployment times and non-zero costs just to get a domain.
you'd still have to address things like provisioning ACM certificates and creating Route53 records
Sure, but that's fine and probably something I'm already doing if I'm asking for custom domains. Cloudfront is not as a given.
It's also worth calling out the OP, which says "One way we had seen to "solve" this, is to use an nginx as reverse proxy for the ECR, but this is an effort we don't want to practice." so you're proposing one moving part for an (albiet much easier to manage) other moving part.
Has anyone actually managed to get CloudFront working in-front of ECR? It's mostly working for me in that I can login using an ecr login password and I can pull images, but when trying to push images it seems as though it gets half-way and then fails with a message saying unauthorized: authentication required, even though I can successfully pull an image straight after.
Haven't tried with CF no.. We are using a pattern, as suggested above, with a private registry behind a Nginx proxy/forwarder running as a Fargate service fronted by an HTTPS ALB
This allows us custom fqdn for our ECR which seems to be working great so far for docker auth/pull/push ops etc.
It is actually pretty neat and tidy to orchestrate and deploy and obviously if one desires to really go all out we could tie the fargate task to some cw metrics/alarms and targets with an ASG to control load demand, but for now we are happy to set the container replica count statically...
Anyway.. apologies, I know I haven't really answered your CF question but I wondered if you were keen on exploring an alternative
@julienbonastre seeing as how you have done this in NGINX, are you able to tag, push, and pull using the custom domain name?
For example:
docker build -t ecr.mydomain.com/my-project/my-image:latest
docker push ecr.mydomain.com/my-project/my-image:latest
docker pull ecr.mydomain.com/my-project/my-image:latest
I guess I'm just asking whether ECR will play nicely if the domain doesn't match the long ECR domain.
