Docker化的反向代理

Question

我打算在一个主机上托管三个网站，我们称之为 raspi-dev：

home.redacted.ca、brew.redacted.ca、www.redacted.ca（或 redacted.ca）

为了实现这一点，我正在使用一个在端口 80 上接受传入连接的容器。这是反向代理配置的 sn-p：

server {
    server_name brew.redacted.ca;
    listen 80;
    location / {
        proxy_pass http://brewweb;
    }
}

brewweb 是一个名为 brewweb 的容器。通讯工作至今。当导航到 http://brew.redacted.ca 时，我得到了我所期望的：

"GET / HTTP/1.1" 301 169 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Firefox/60.0" "-"

关键是将流量重定向到https。这是来自其他网络服务器的代码：

server {
    listen 80;
    server_name brew.redacted.ca;
    return 301 https://brew.redacted.ca$request_uri;
}


server {
    server_name brew.redacted.ca;
    root /var/www/brew;
    listen 443 ssl;
    location / {
        try_files $uri $uri/ /index.html =404;
    }

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
}

所以它按预期工作。您转到http://brew.redacted.ca，它会告诉您返回端口 443。但是，在浏览器中，我得到一个死链接：“无法连接”。我现在的假设是，这是因为我的反向代理（它是主机网络上唯一侦听的容器）无法接收并转发未来的 443 请求。不过，我对如何处理这个问题有点不知所措..我是否获得了反向代理的证书？？？我怎么会这样做，因为它本身甚至没有提供任何内容..

我愿意接受所有建议。

Answer 1

需要与客户安全对话的是您的代理，而不是托管的应用程序。我在我的内部网络上执行此操作。我有一个 docker 主机，在单个 Nginx 反向代理后面运行几个不同的开发人员工具。

所有 SSL/TLS 均由代理服务器处理。实际为应用程序提供服务的 Web 服务器位于 docker 容器中，仅对 Nginx 代理容器可见。他们通过 http 而不是 https 与代理通信。

我正在使用为我的主服务器 *.app.co 颁发的通配符证书，其中包含 www.app.co、utility.app.co 和 another.app.co 的 SA 条目

Nginx 代理服务器配置实际上最终看起来像这样：

ssl_certificate     redacted.pem
ssl_certificate_key redacted.key
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         HIGH:!aNULL:!MD5;
ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;

server {
  listen 80 default_server;
  server_name _;
  return 301 https://$host$request_uri;
}

server {
  listen 443;
  server_name www.app.co;
  proxy_pass http://www-container
  ...
}

server {
  listen 443 default_server;
  server_name www.app.co;
  proxy_pass http://www-container
  ...
}

server {
  listen 443;
  server_name another.app.co;
  proxy_pass http://another-container
  ...
}