Using a Reverse Proxy to Expose Multiple Microservices Through a Single Port in Docker Compose

In modern microservices architectures, applications are often broken down into smaller, independent services that communicate with each other. Each microservice typically runs on its own port, which can lead to challenges when exposing these services to the outside world. For example, managing multiple ports, handling cross-origin requests, and ensuring consistent API gateways can become cumbersome. A reverse proxy is a powerful solution to these challenges. By using a reverse proxy like NGINX, you can expose multiple microservices through a single port, simplifying access and improving manageability. Let’s dive into how this works and the benefits it brings. How It Works A reverse proxy acts as an intermediary between clients (e.g., browsers, mobile apps) and your microservices. It listens on a single port (e.g., 80 or 8180) and routes incoming requests to the appropriate microservice based on the request path. Example Setup Here’s a simplified example using Docker Compose and NGINX: 1. Docker Compose File: Define your microservices (user_service, department_service, etc.). Add an NGINX service as the reverse proxy. version: "3.8" services: reverse-proxy: image: nginx:latest ports: - "8180:80" # Expose NGINX on port 8180 volumes: - ./nginx.conf:/etc/nginx/nginx.conf # Custom NGINX configuration depends_on: - user_service - department_service user_service: image: your_user_service_image ports: - "5001:8185" # Internal port for user_service environment: - PORT=8185 department_service: image: your_department_service_image ports: - "5002:8185" # Internal port for department_service environment: - PORT=8185 2. NGINX Configuration: Define routing rules in nginx.conf to map paths to microservices. events {} http { server { listen 80; # Route requests to the user_service location /api/users/ { proxy_pass http://user_service:8185/; proxy_set_header Host $host; 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 $scheme; } # Route requests to the department_service location /api/departments/ { proxy_pass http://department_service:8185/; proxy_set_header Host $host; 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 $scheme; } } } 3. Accessing the Services: Clients can now access the microservices through the reverse proxy: http://localhost:8180/api/users → Routes to user_service. http://localhost:8180/api/departments → Routes to department_service.

Mar 3, 2025 - 07:04

Using a Reverse Proxy to Expose Multiple Microservices Through a Single Port in Docker Compose

In modern microservices architectures, applications are often broken down into smaller, independent services that communicate with each other. Each microservice typically runs on its own port, which can lead to challenges when exposing these services to the outside world. For example, managing multiple ports, handling cross-origin requests, and ensuring consistent API gateways can become cumbersome.

A reverse proxy is a powerful solution to these challenges. By using a reverse proxy like NGINX, you can expose multiple microservices through a single port, simplifying access and improving manageability. Let’s dive into how this works and the benefits it brings.

How It Works

A reverse proxy acts as an intermediary between clients (e.g., browsers, mobile apps) and your microservices. It listens on a single port (e.g., 80 or 8180) and routes incoming requests to the appropriate microservice based on the request path.

Example Setup
Here’s a simplified example using Docker Compose and NGINX:

1. Docker Compose File:

Define your microservices (user_service, department_service, etc.).
Add an NGINX service as the reverse proxy.

version: "3.8"

services:
  reverse-proxy:
    image: nginx:latest
    ports:
      - "8180:80"  # Expose NGINX on port 8180
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf  # Custom NGINX configuration
    depends_on:
      - user_service
      - department_service

  user_service:
    image: your_user_service_image
    ports:
      - "5001:8185"  # Internal port for user_service
    environment:
      - PORT=8185

  department_service:
    image: your_department_service_image
    ports:
      - "5002:8185"  # Internal port for department_service
    environment:
      - PORT=8185

2. NGINX Configuration:

Define routing rules in nginx.conf to map paths to microservices.

events {}

http {
  server {
    listen 80;

    # Route requests to the user_service
    location /api/users/ {
      proxy_pass http://user_service:8185/;
      proxy_set_header Host $host;
      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 $scheme;
    }

    # Route requests to the department_service
    location /api/departments/ {
      proxy_pass http://department_service:8185/;
      proxy_set_header Host $host;
      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 $scheme;
    }
  }
}

3. Accessing the Services:

Clients can now access the microservices through the reverse proxy:

http://localhost:8180/api/users → Routes to user_service.
http://localhost:8180/api/departments → Routes to department_service.