Skip to main content

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 the docker-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 the docker-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.

Apache Port Mapping Reverse Proxy Example

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>

Nginx Host Mapping Reverse Proxy Example

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;
   }
 }}

AWS Application Load Balancer (ALB) Example

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

  1. Create a Target Group

    In the AWS EC2 console, navigate to Target Groups under Load Balancing.

    1. Click Create target group and select Instances or IP addresses as the target type, depending on how your Docker repository is deployed.

    2. 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.

    3. Create the target group.

  2. Create an Application Load Balancer

    In the AWS EC2 console, navigate to Load Balancers under Load Balancing.

    1. Select Create Load Balancer. Select "Application Load Balancer and Create.

    2. 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.

    3. 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.

    4. Security groups:

      Create or select a security group that allows HTTPS (port 443) traffic from the internet (or your desired source).

    5. Create the load balancer.

  3. Configure DNS

    In your DNS provider, create a CNAME record for docker.yourdomain.com that points to the DNS name of your ALB.