Docker 环境，nginx 反向代理，本地或全局

Question

Some docker-compose solutions, uses nginx as reverse proxy for security reasons, when exposing the service to the internet. Would it be more correct to install multiple docker services, with there own nginx (reverse proxy) or create one dedicated container, holding the nginx service, and redirect to all the "local" containers?

Answer 1

I'd almost always do this with only a single Nginx proxy, though more for simplicity than anything security-related.

An especially important pattern is around browser front-ends. Your React or Angular code runs in the browser, not in a container, so it can't use Docker networking; but for both deploy-time configuration and CORS reasons it's much better if the code and the back-end application are served from the same host and port. If you can use /api/whatever as the back-end URL, without embedding a host name or port, it will work anywhere the service can be deployed.

That would bring you a Compose setup like so:

version: '3.8'
services:
  ingress:
    image: nginx
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    ports:
      - '8888:80'  # <-- this is the only published port
  frontend:
    build: frontend
    # no ports:, volumes:, networks:, container_name:, _etc._
  backend:
    build: backend
    environment:
      - PGHOST=db
  db:
    image: postgresql
    environment: { ... }
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

In this stack, the only thing you can reach from outside Docker is the ingress container; nothing else has ports: . That's the (production) setup you want. (I tend to minimize differences between dev and prod Docker setups, but adding more ports: to e.g. directly access the database with psql and without docker exec is pretty helpful in non-prod.)

The Nginx configuration then has all of the URL routing you need

upstream backend { server backend:3000 }
upstream frontend { server frontend:3000 }

server {
  location / {
    proxy_pass http://frontend;
  }
  location /api {
    proxy_pass http://backend;
  }
}

You can do other things in this configuration like providing (unified) authentication checking, hiding .../admin/... routes, and integrate other services into your API. All of this is much harder to do consistently if you have many separate Nginxes.