docker nginx 代理与 poste.io 邮件服务器

Question

如果一个 docker 容器已经绑定到您某个接口 IP 上的端口 443（或 0.0.0.0 表示所有接口），则其他 docker 容器无法绑定到同一 IP。当一个 1 容器启动时，使用 netstat 检查：

sudo netstat -nalp64 | grep 443
tcp     0    0    0.0.0.0:443     0.0.0.0:*    LISTEN     26547/docker-proxy

由于 0.0.0.0 上的端口 443 已被 docker 容器使用，因此新容器无法绑定到该 IP + 端口。

可视化

  0.0.0.0:443   (Error: Port 443 already in use)
        |               \
+--------------+    +--------------+
|  CONTAINER   |    |  CONTAINER   |
|   172.0.0.2  |    |   172.0.0.3  |
+--------------+    +--------------+

您不需要将多个容器绑定到同一个端口，而是需要一些软件绑定到端口，将连接重定向到适当的容器。

最简单的方法是运行专用的反向代理，这是绑定到端口 (443) 的唯一程序。反向代理的目的是根据请求的 HTTP 主机转发传入的连接。

反向代理可以在运行docker的物理主机上运行，也可以在docker容器内运行。

反向代理还可以终止 SSL 连接，这意味着这个 nginx 实例处理所有往返于客户端的加密/解密，而与后端（容器）的连接未加密。

我不认为这绝对必要，现代浏览器支持 SNI，因此 nginx 仍然可以将请求转发到适当的后端，而无需解密所有流量。但使用中央 SSL 终端，您只需在一个地方配置证书，并且对于大多数用例，只需全局配置一次 SSL。

为了设置具有 SSL 终止功能的反向代理

在docker主机上安装nginx（反向代理）
为容器定义静态 IP 或主机名
使容器的 SSL 证书 + 私钥文件可供 nginx 反向代理使用
在反向代理配置中定义 Docker 容器的 nginx 上游
定义 nginx 服务器（“vhosts”）来为以下定义的域名提供服务server_name
location将请求转发到使用中定义的上游proxy_pass

例子：

我的/etc/nginx/sites-enabled/dockerproxy样子是这样的：

# gitlab
upstream gitlab
{
    server 172.20.0.2;
}

# docker registry
upstream registry
{
    server 172.20.0.3:5050;
}

# dev.mycompany.org
server
{
    listen 10.10.10.40:80 default;
    listen 10.10.10.40:443 ssl default;
    server_name dev.mycompany.org;

    ssl_certificate         /data/run/certbot/data/live/dev.mycompany.org/fullchain.pem;
    ssl_certificate_key     /data/run/certbot/data/live/dev.mycompany.org/privkey.pem;

    location /
    {
        proxy_pass http://gitlab/;
        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;
    }
}

# registry.mycompany.org
server
{
    listen 10.10.10.40:443 ssl;
    server_name registry.mycompany.org;

    ssl_certificate         /data/run/certbot/data/live/registry.mycompany.org/fullchain.pem;
    ssl_certificate_key     /data/run/certbot/data/live/registry.mycompany.org/privkey.pem;
    ssl_session_cache       builtin:1000 shared:SSL:60m;
    ssl_session_timeout     60m;

    client_max_body_size 0;
    chunked_transfer_encoding on;

    location /
    {
        proxy_pass http://registry/;
        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;
    }
}

请注意，这些proxy_set_header指令严格来说并不是必需的，它们取决于各个后端应用程序的期望。

如你所见，这个配置告诉 nginx：

绑定到 10.10.10.40:443
将 dev.mycompany.org 的请求代理到 172.20.0.2[:80]（gitlab 容器的 IP）
将 registry.mycompany.org 的请求代理到 172.20.0.3:5050（注册容器的 IP）
使用给定的证书文件终止 SSL（在我的情况下，直接来自 certbot 容器）

可视化

           0.0.0.0:443
                |
    +-----------------------+
    |       nginx           |
    +-----------------------+
        |               |
+--------------+    +--------------+
|   VHOST      |    |   VHOST      |
| web.app1.com |    | web.app2.com |
+--------------+    +--------------+
        |               |
+--------------+    +--------------+
|  CONTAINER   |    |  CONTAINER   |
|   172.0.0.2  |    |   172.0.0.3  |
+--------------+    +--------------+

通过使用不同的指令定义其他upstream对象，您可以使用相同的接口 IP + 端口提供其他 HTTP(S) 服务。serverserver_name

请注意，该listen 10.10.10.40:443指令在 nginx 配置中被多次使用。这是可能的，因为 nginx 仅绑定到该 IP 一次，然后解析Host客户端请求中的标头以确定哪个server(vhost) 将处理此请求。

我的配置在upstream定义中使用静态 IP，但你也可以使用容器的主机名，只需确保它们是预先知道的（在 docker-compose 中定义，请参阅https://docs.docker.com/compose/compose-file/#domainname-hostname-ipc-mac_address-privileged-read_only-shm_size-stdin_open-tty-user-working_dir) 并可由 nginx 解析。

最后，不要将容器/服务的端口映射到主机端口！它们不需要向外界开放，只有 nginx 需要访问它们。

Answer 1