Docker Reverse Proxy Strategies
A reverse proxy in front of Nexus Repository may also be used to avoid docker port connector scalability issues as using more than 20 port connectors to expose docker repositories may causes performance issues in Nexus Repository.
See Run Behind a Reverse Proxy
This method is to remap incoming requests to specific ports or subdomains to the complete repository base path of the intended docker repository.
Port Mapping
In this example, the reverse proxy remaps the request using an assigned port to the repository base path. The port
8086
is used to map to the repository path for thedocker-hosted-project
repository. The repository does not require configuring the port connector in this use-case.https://nexus.example.com:8086 > http://nexus.example.com:8081/repository/docker-hosted-project
Host Mapping
In this example, the reverse proxy remaps the request using a subdomain to the repository base path. The subdomain
project-push
is used to map to the repository path for thedocker-hosted-project
repository. The repository does not require configuring the subdomain connector in this use-case.https://project-push.example.com > http://nexus.example.com/repository/docker-hosted-project
Limitations
Using a reverse proxy means that you do not have to reserve port connectors in Nexus Repository when configuring your docker repositories. This method does have a few limitations which may suggest that other methods are prefered:
A wildcard TLS certificate may be needed for the uses subdomain when you have many hostnames mapped to repositories.
As the mapping is completely in the reverse proxy configuration, it may be difficult to keep track of the mapping and debug issues in connectivity.
The following example Apache HTTP Server configuration port maps the port 8087
to the repository base path /repository/docker-repo
without the need of port connectors needing to be configured in Nexus Repository.
Listen 8087 https <VirtualHost *:8087> ServerName project.example.com ServerAdmin admin@example.com AllowEncodedSlashes NoDecode ProxyRequests Off ProxyPreserveHost On SSLEngine ON SSLCertificateFile "/path/to/ssl/server.crt" SSLCertificateKeyFile "/path/to/ssl/server.key" ProxyTimeout 300 ProxyPass / http://nexus.example.com:8081/repository/docker-repo/ nocanon ProxyPassReverse / http://nexus.example.com:8081/repository/docker-repo/ RequestHeader set X-Forwarded-Proto "https" </VirtualHost>
The following example Nginx configuration to maps the subdomain project.example.com
to the repository base path /repository/docker-repo
only using the reverse.
This Nginx host mapping example uses the same server for Nexus Repository requests.
http { proxy_send_timeout 120; proxy_read_timeout 300; proxy_buffering off; proxy_request_buffering off; keepalive_timeout 5 5; tcp_nodelay on; server { listen 443 ssl; server_name project.example.com ssl on; ssl_certificate /path/to/ssl/server.crt; ssl_certificate_key /path/to/ssl/server.key; # Docker /v2 and /v1 (for search) requests location /v2 { proxy_set_header Host $host:$server_port; 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_pass http://nexus.example.com:8081/repository/docker-repo/$request_uri; } location /v1 { proxy_set_header Host $host:$server_port; 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_pass http://nexus.example.com:8081/repository/docker-repo/$request_uri; } # Regular Nexus requests location / { proxy_set_header Host $host:$server_port; 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_pass http://nexus.example.com:8081; } }}
An AWS Application Load Balancer (ALB) can be configured as a reverse proxy for your Docker repository. This approach offers scalability, high availability, and integration with other AWS services.
See AWS Application Load Balancer
Create a Target Group In the AWS EC2 console, navigate to
Target Groups
underLoad Balancing
.Click
Create target group
and selectInstances
orIP addresses
as the target type, depending on how your Docker repository is deployed.Choose your VPC. Specify the port your Docker repository is listening on (e.g., 5000). Add the instance(s) or IP address(es) of your Docker repository to the target group. Configure health checks to ensure the repository is reachable.
Create the target group.
Create an Application Load Balancer In the AWS EC2 console, navigate to
Load Balancers
underLoad Balancing
.Select
Create Load Balancer
. Select "Application Load Balancer
andCreate
.Basic Configuration Name: docker-alb (or your preferred name)
Scheme: Internet-facing or Internal as needed.
IP address type: IPv4 or Dualstack.
VPC and availability zones: select the VPC and Availability zones where your docker repository resides.
Listeners and routing: Add a listener with: Protocol: HTTPS, Port: 443, Default actions: Forward to the target group you created.
Select the SSL certificate from ACM that you created for your domain.
Security groups: Create or select a security group that allows HTTPS (port 443) traffic from the internet (or your desired source).
Create the load balancer.
Configure DNS In your DNS provider, create a CNAME record for
docker.yourdomain.com
that points to the DNS name of your ALB.