julienbonastre
commented
2 years ago Can you share the following?
- Commands you're using for
docker buildand tagging of your images; are you tagging with both the ECR URL and your custom URL?
docker build -t myecr.org.com/imagepath:tag .
- Commands you're using for
docker login: are you using the ECR URL or your custom URL?
aws ecr get-login-password --region <my-region> | docker login -u AWS --password-stdin myecr.org.com
- Commands you're using for
docker push: are you pushing to the ECR URL or your custom URL?
docker push myecr.org.com/imagepath:tag
- Commands you're using for
docker pull: are you pulling from the ECR URL or your custom URL?
docker pull myecr.org.com/imagepath:tag
Also I know you described your NGINX configuration above, but can you give us a little more info as to how all of this is setup? Do you have one or more NGINX nodes running with public IPs, listening for TLS on 443, modifying the
Hostheader, and passing to the upstream? Is that all there is to it?
I am using a Private ECR registry in a hub/central account. A fargate service is running an nginx task which listens on 443 and performs https forwarding to the target AWS ECR FQDN, rewriting the Host header as is necessary. This fargate service is behind ALB with an acm for my custom ECR FQDN.
Crux of the nginx.conf that does the heavy lifting:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
chunked_transfer_encoding on;
client_max_body_size 0;
server_name _;
location / {
proxy_pass https://<aws acct id>.dkr.ecr.ap-southeast-2.amazonaws.com;
proxy_set_header Host "<aws acct id>.dkr.ecr.ap-southeast-2.amazonaws.com";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto "https";
proxy_read_timeout 900;
}That's it.
Note: I couldn't use Http301 redirect rule on an ALB Listener for this. Unsure why but it must not perform a masqueraded proxy quite the same way as it's just providing a 301 back to the docker client as opposed to handing the request transparently to the requesting client. This makes the difference and is why I'm using nginx.
EDIT: If I'm able to get all of this working with CloudFront, ACM, and Lambda, I will (:pray:) publish my code as a Terraform module to the Terraform module registry so that others can do this without any hassle.
Nice idea, I'm considering sanitising the pattern I've used and sharing. It is a golang cdk setup which deploys the Hub infra including acm, alb, fargate cluster with an nginx proxy service and builds out all the desired team repos with custom kms keys per team, repo life cycle and access policies, driven from a configurable set of JSON cfgs (one per business team), and executed with a Github Action for live updates.
mhornbacher
WhyNotHugo
naftulikay
SebastianUA
thiagolsfortunato
drop-rahul
nomatterz
sumanthkumarc
NandGates
n1ngu
amancevice
edlevin6612
wosiu
devunt
relistan
jessefarinacci
jampy
benjimin
webertrlz
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
(2) Disaster recovery for the ECR account
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