运维笔记：宿主机转发实现多容器复用CA证书

1. 概述

1.1 背景介绍

我为服务器购买了域名以及CA证书，但是我的应用却有多个。首先，需要部署一个静态的Web页面作为网站主页——这就需要使用80和443端口，他们分别是HTTP和HTTPS中规定的默认端口。与此同时，需要部署其它同样需要使用HPPTS协议通信的应用——这不奇怪，尤其是随着安全通信标准的提高，例如在移动端中从Android 9 (API级别28)开始，Google要求所有从应用发出的网络请求默认必须使用HTTPS来确保数据传输的安全性。我有一个Django后端，它同时为多个项目提供API，其中就包括了移动端、Web甚至桌面端，迫切需要解决在使用 SSL/TLS 加密的问题。

因此在项目开发和部署过程中，SSL证书的应用成为了一个关键点，我们需要确保在单一域名下，不同类型的服务——无论是静态页面还是动态API——都能够通过HTTPS加密通信，而且要在不增加额外证书成本的前提下实现这一点。

1.2 关于本文

本文的目标是总结在实现多容器环境下复用单个CA证书的经验。我们将探讨在宿主机上使用Nginx作为反向代理的方法，这不仅解决了HTTPS请求的处理和转发问题，还允许我们在不增加额外证书成本的前提下，确保不同类型服务的安全通信。通过这次经验的总结，我们希望为面临类似挑战的开发者和项目提供参考和指导，帮助他们更高效地部署和管理他们的应用，同时保持高度的安全性和成本效益。

接下来的部分将详细介绍我们在寻找解决方案的过程中考虑的各种可能方案及其优缺点，为什么最终选择在宿主机上使用Nginx转发的方法，以及这一决策的具体实施细节。我们还将分享在实施过程中遇到的挑战及其解决方法，最后总结本次经验的关键点和学习成果。

2. 寻找解决方案

在经济上考虑成本，尽可能地减少证书和维护的开销。在评估了多种可能的解决方案后，我们主要考虑了以下几个方案：

• 单独为每个服务配置SSL证书：最直接的方法是为每个服务（Web页面服务和API服务）分别配置SSL证书。这种方法的优点是配置简单，每个服务都可以独立管理自己的证书，但缺点也很明显，即成本较高，且管理多个证书会增加运维的复杂性。
  
• 使用负载均衡器处理SSL终端：通过在负载均衡器上配置SSL证书，然后将HTTPS请求解密后转发给后端的服务。这种方法可以集中管理SSL证书，减少证书的数量，但需要额外的硬件或软件资源来部署负载均衡器，增加了系统的复杂性和成本。
  
• 在宿主机上使用Nginx转发：在宿主机上配置Nginx作为反向代理，使用单个SSL证书处理所有HTTPS请求，然后根据请求的类型转发到相应的容器（静态页面服务或Django应用）。这种方法结合了前两种方法的优点，既可以减少证书的数量，又可以避免引入额外的负载均衡器，同时利用Nginx强大的反向代理和配置灵活性。

3. Nginx转发方案

在面对项目需求和挑战时，我们经过深入的讨论和评估，最终选择了在宿主机上使用Nginx作为反向代理来实现多容器复用单个CA证书的方案。这一决策基于对技术可行性、安全性、成本效益以及实施难度的综合考量。

3.1 可行性

Nginx作为一个成熟且广泛使用的高性能Web服务器和反向代理服务器，具备了处理大量并发连接的能力。它支持SSL终端，可以在接收到HTTPS请求后解密，然后以HTTP请求的形式转发到后端的服务，这一点对于我们的需求来说是非常关键的。Nginx的高度可配置性也使得我们能够根据请求的不同类型（如API请求和静态页面请求）将流量转发到不同的容器，这为我们提供了极大的灵活性和控制能力。

3.2 安全性

通过在宿主机上统一处理HTTPS请求，我们可以确保所有经过Nginx转发的通信都是在加密状态下进行的。这种集中式的SSL终端处理方式，不仅简化了每个容器内部的SSL配置，减少了潜在的配置错误和安全漏洞，而且还加强了整个系统的安全性。此外，使用单个CA证书减少了证书管理的复杂性，降低了因证书配置错误导致的安全风险。

3.3 成本

在成本方面，使用单个CA证书为所有服务提供HTTPS支持，无疑是一种经济高效的解决方案。这种方法避免了为每个服务单独购买和维护SSL证书的需要，显著降低了项目的运维成本。此外，选择Nginx作为反向代理，我们能够利用现有的开源技术，无需投入额外的硬件或软件资源，进一步优化了成本结构。

3.3 难度

相比于配置负载均衡器或为每个服务单独购买和配置SSL证书，使用Nginx作为反向代理的方法在实施上更为简单和直接。

由此可见，选择在宿主机上使用Nginx转发的方案，不仅技术上可行，安全性高，而且在成本和实施难度上都具有明显的优势。这一方案有效地满足了我们在项目中对于HTTPS通信安全、成本控制以及系统可维护性的综合需求，是一种既实用又经济的解决方案。

4. 方案的具体实行细节

在决定采用Nginx作为反向代理来实现多容器复用单个CA证书后，我们的主要任务转向了如何具体实施这一方案。这包括了对Nginx的配置进行精确的设置，以确保能够高效地处理来自不同服务的请求。以下是我们在实施过程中采取的关键步骤，以及如何通过具体的配置来解决遇到的挑战。

4.1 Nginx配置实施

4.2.1 Nginx中配置SSL证书

首先，我们需要在Nginx中配置SSL证书，以便Nginx能够处理HTTPS请求。这涉及到将证书文件和私钥文件放置在Nginx服务器的指定目录下，并在Nginx的配置文件中正确引用这些文件。以下是我们的SSL证书配置示例：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/cert/your-cert-file.pem;
    ssl_certificate_key /etc/nginx/cert/your-cert-file.key;

    # SSL配置
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

接下来，我们配置了两个主要的server块，分别用于处理静态Web页面的请求和指向Django应用的API请求。

4.2.2 静态Web页面的请求处理

对于静态Web页面的请求，我们配置Nginx直接将请求转发到托管静态内容的容器。这是通过设置一个简单的location /块来实现的，如下所示：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    # SSL证书配置...

    location / {
        root /var/www/html;
        index index.html index.htm;
    }
}

4.2.3 Django应用的API请求处理

对于API请求，我们通过配置Nginx将请求转发到运行Django应用的容器。这涉及到使用location指令来匹配所有以/api/开头的请求，并将它们转发到Django应用容器的指定端口。同时，我们通过

proxy_set_header指令确保Django应用能够接收到正确的请求信息。以下是相关配置的示例：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    # SSL证书配置...

    location /api/ {
        proxy_pass http://localhost:8000; # 假设Django应用运行在8000端口
        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;
    }
}

通过这种方式，我们能够确保所有以/api/开头的请求都被正确地转发到Django应用，而其他请求则被服务于静态内容。这种配置不仅提高了我们的服务的灵活性和可维护性，还确保了通过HTTPS进行的所有通信都是安全的。

4.2 配置Nginx作为反向代理

在实现多容器环境下复用单个CA证书的过程中，配置Nginx作为反向代理是核心步骤之一。这一步骤不仅涉及到SSL证书的正确配置，以确保HTTPS请求的安全处理，还包括了对不同类型请求的正确转发，以满足我们的服务需求。以下是具体的配置实施细节：

4.2.1 SSL证书配置

首先，我们需要确保Nginx能够通过SSL证书处理HTTPS请求。这涉及到将证书文件（.pem）和私钥文件（.key）放置在Nginx服务器的指定目录下，并在Nginx的配置文件中正确引用这些文件。以下是SSL证书配置的示例：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/cert/your-cert-file.pem;
    ssl_certificate_key /etc/nginx/cert/your-cert-file.key;

    # SSL配置
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

4.2.2 配置反向代理

接下来，我们配置Nginx作为反向代理，以将HTTPS请求根据其类型转发到相应的容器。这包括静态Web页面的请求和指向Django应用的API请求。

静态Web页面的请求处理

对于静态Web页面的请求，我们配置Nginx直接将请求转发到托管静态内容的容器。这可以通过设置一个简单的location /块来实现，如下所示：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    # SSL证书配置...

    location / {
        root /var/www/html;
        index index.html index.htm;
    }
}

Django应用的API请求处理

对于API请求，我们通过配置Nginx将请求转发到运行Django应用的容器。这涉及到使用location指令来匹配所有以/api/开头的请求，并将它们转发到Django应用容器的指定端口。同时，我们通过

proxy_set_header指令确保Django应用能够接收到正确的请求信息。以下是相关配置的示例：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    # SSL证书配置...

    location /api/ {
        proxy_pass http://localhost:8000; # 假设Django应用运行在8000端口
        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;
    }
}

通过这种配置，我们确保了所有以/api/开头的请求都被正确地转发到Django应用，而其他请求则被服务于静态内容。这种方法不仅提高了服务的灵活性和可维护性，还确保了通过HTTPS进行的所有通信都是安全的。

4.3 处理不同类型的请求

在配置Nginx作为反向代理的过程中，一个关键的挑战是如何准确地区分和转发不同类型的请求，确保每种请求都能被正确地处理并转发到相应的服务。这通常涉及到对静态Web页面的请求和动态API请求的处理。为了实现这一目标，我们利用了Nginx的location指令，通过匹配请求的URL路径来区分请求类型，并将它们转发到不同的后端服务。

以下是一个具体的配置示例，展示了如何在Nginx中设置不同的location块来处理静态页面请求和API请求：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/cert/your-cert-file.pem;
    ssl_certificate_key /etc/nginx/cert/your-cert-file.key;

    # 静态内容的处理
    location / {
        root /var/www/html;
        index index.html index.htm;
    }

    # 动态API请求的处理
    location /api/ {
        proxy_pass http://localhost:8000; # 假设Django应用运行在8000端口
        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;
    }
}

静态内容处理：对于静态Web页面的请求，我们通过配置一个简单的location /块来直接将请求转发到托管静态内容的目录。这种方式简单高效，能够快速响应用户对静态资源的请求。

动态API请求处理：对于以/api/开头的动态API请求，我们通过另一个location /api/块将请求转发到运行Django应用的容器。这里使用了proxy_pass指令来指定Django应用的地址和端口，同时通过proxy_set_header指令确保请求的头部信息被正确地传递给Django应用，这对于应用处理请求和维持会话非常重要。

在配置完成后，进行了一系列的测试来验证配置的正确性。测试包括：

访问静态Web页面，确保页面能够正常加载。

发送API请求到/api/路径，验证请求是否成功被转发到Django应用，并且应用能够正确响应。

通过这些测试，我们确信Nginx的配置能够准确地区分和处理不同类型的请求，满足我们的项目需求。

5. 一个完整的配置示例

在本节中，我们将提供一个完整的Nginx配置示例，这个配置旨在实现多容器环境下复用单个CA证书，同时处理静态Web页面请求和转发至Django应用的API请求。此配置将确保所有通过Nginx的通信都是加密的，并且根据请求的不同类型将流量正确地转发到相应的服务。

假设静态Web页面托管在Nginx服务器上的/var/www/html目录中，而Django应用运行在同一宿主机的8000端口上。你的域名为yourdomain.com，SSL证书和私钥分别存放在/etc/nginx/cert/your-cert-file.pem和/etc/nginx/cert/your-cert-file.key。

以下是一个完整的Nginx配置文件示例，该配置同时处理HTTPS请求的静态内容服务和API请求的代理转发。

# HTTPS服务器配置
server {
    # 监听443端口，启用ssl
    listen 443 ssl;
    server_name yourdomain.com;

    # SSL证书和私钥的位置
    ssl_certificate /etc/nginx/cert/your-cert-file.pem;
    ssl_certificate_key /etc/nginx/cert/your-cert-file.key;

    # SSL配置
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    # 静态内容的处理
    location / {
        root /var/www/html;
        index index.html index.htm;
    }

    # Django应用的API请求处理
    location /api/ {
        proxy_pass http://localhost:8000; # Django应用的本地端口
        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;
    }
}

# HTTP到HTTPS的重定向配置
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri; # 将所有HTTP请求重定向到HTTPS
}

这个配置文件中包含了两个server块：

第一个server块配置了SSL证书的路径，以及如何处理HTTPS请求。它首先定义了如何处理对静态内容的请求（例如HTML、CSS和JavaScript文件），然后定义了如何将以/api/开头的请求转发到Django应用。这样，无论用户是请求静态页面还是通过API与Django应用交互，所有的通信都将通过HTTPS加密。

第一个server块配置了SSL证书的路径，以及如何处理HTTPS请求。它首先定义了如何处理对静态内容的请求（例如HTML、CSS和JavaScript文件），然后定义了如何将以/api/开头的请求转发到Django应用。这样，无论用户是请求静态页面还是通过API与Django应用交互，所有的通信都将通过HTTPS加密。

通过这种配置，我们实现了在单一宿主机上，使用单个CA证书为多个容器提供HTTPS服务的目标，同时保持了配置的简洁性和高效性。这不仅提高了安全性，还优化了资源的使用，减少了证书管理的复杂性。

6. 结论

通过本次经验的总结，我们成功地探索并实施了一种在宿主机上使用Nginx作为反向代理来实现多容器复用单个CA证书的方案。这一方案不仅技术上可行，而且在安全性、成本效益以及实施难度上都展现出了明显的优势。通过配置Nginx，我们能够确保所有服务——无论是静态网页还是动态API——都能在单一域名下通过HTTPS加密通信，同时避免了为每个服务单独配置SSL证书的需要，显著降低了项目的运维成本。