如果你是一名开发者，最近在部署Web应用、搭建测试环境或者学习容器化技术，那么“Docker + Nginx”这个组合你一定绕不开。但你可能也发现了，网上教程千篇一律，要么是 docker run nginx 就结束了，要么是直接扔给你一个复杂的 nginx.conf 文件，却很少告诉你： 为什么要在Docker里用Nginx？它到底解决了传统部署的哪些痛点？以及，那些看似简单的配置背后，有哪些新手必踩的“坑”？

这篇文章不会重复那些“安装Docker”的基础步骤。我们假设你已经对Docker有了基本了解。我们要深入探讨的是： 如何将Nginx作为生产级Web服务器/反向代理，在Docker环境中进行正确、高效、可维护的部署和使用。 这不仅仅是跑起来一个容器，而是涉及到配置管理、日志持久化、性能调优、动态重载等一系列工程实践。

你会发现，用Docker部署Nginx，真正的价值不在于“能跑”，而在于它提供了一种 声明式、可移植、隔离性极强 的标准化部署方式。过去，你在不同服务器上部署Nginx，需要手动安装、编译模块、小心翼翼地修改配置文件，还要担心污染系统环境。现在，一个Docker镜像和一份配置文件就能在任何地方复现完全一致的服务。

本文将带你从“能用”到“用好”。你会学到：

  1. 核心场景 ：Nginx在Docker中最常见的三种角色（静态服务器、反向代理、负载均衡）该如何配置。
  2. 关键实践 ：如何通过 卷挂载（Volume） 优雅地管理配置和日志，而不是把数据锁死在容器里。
  3. 避坑指南 ：如何处理容器内Nginx的权限问题、如何实现配置热重载而不重启容器、以及如何优化性能参数。
  4. 完整示例 ：从单容器到使用Docker Compose编排多服务，提供可直接复用的配置文件和命令。

读完本文，你将能独立完成一个基于Docker的、可用于中小型生产环境的Nginx服务搭建。

1. 为什么是 Docker + Nginx？重新理解这个组合的价值

很多教程把“Docker部署Nginx”讲成了一个简单的安装练习，这大大低估了它的价值。我们得先搞清楚，这个组合到底解决了什么实际问题。

传统部署的典型痛点：

  • 环境不一致 ：开发机是Ubuntu 20.04，测试机是CentOS 7，生产机是Alpine。Nginx版本、编译参数、依赖库的细微差别都可能导致诡异的问题。
  • 配置污染与冲突 ：系统全局安装的Nginx，其配置文件、日志文件、站点目录都散落在 /etc/nginx 、 /var/log/nginx 、 /usr/share/nginx/html 等系统路径。想同时运行两个不同配置的Nginx实例？非常麻烦。
  • 清理困难 ：卸载Nginx后，残留的配置文件、日志和缓存目录很难彻底清理干净。
  • 移植性差 ：将一套完整的Nginx应用（包含自定义配置、SSL证书、静态资源）迁移到另一台服务器，步骤繁琐，容易遗漏。

Docker化部署带来的根本改变：

  • 环境标准化 ： nginx:alpine 镜像在任何安装了Docker的Linux、Windows、Mac上，运行的都是完全一致的操作系统环境和Nginx二进制文件。彻底消除了“在我机器上是好的”这类问题。
  • 隔离与安全 ：每个Nginx服务运行在独立的容器中，拥有自己的文件系统、网络命名空间。一个容器的配置错误或安全漏洞，很难波及其他容器或宿主机。
  • 配置即代码 ：你的Nginx配置文件（ nginx.conf 、 conf.d/*.conf ）、SSL证书、网站静态文件，都可以作为代码的一部分，存放在Git仓库中。部署就是拉取代码和镜像，然后启动容器。
  • 秒级启停与扩缩容 ：需要一个新的测试环境？ docker run 一下。流量激增需要扩容？使用Docker Compose或K8s可以快速拉起多个Nginx容器实例。

所以， Docker + Nginx的核心价值，是实现了Web服务部署的工业化与可预测性 。对于前端开发者，可以快速搭建本地的静态资源服务器；对于后端开发者，可以轻松构建API网关和反向代理；对于运维人员，则拥有了一个统一、高效的部署单元。

2. 核心概念与准备工作：镜像、容器与卷

在开始实操前，我们需要统一几个关键概念，这能帮助你理解后续每一个操作的意图。

2.1 Docker 镜像与容器

  • 镜像（Image） ：一个只读的模板，包含了运行Nginx所需的操作系统、Nginx程序、基础配置等。例如 nginx:1.25-alpine 。你可以把它理解为一个“安装包”或“蓝图”。
  • 容器（Container） ：是镜像的一个运行实例。当你执行 docker run nginx 时，Docker会从镜像创建一个可写的容器层，然后运行它。容器是活着的、正在运行的进程。

2.2 卷（Volume）与绑定挂载（Bind Mount）

这是Docker化部署Nginx的 灵魂所在 ，也是新手最容易出错的地方。

  • 默认情况 ：如果不做任何挂载，Nginx容器会在其内部的容器文件系统（如 /etc/nginx , /usr/share/nginx/html , /var/log/nginx ）中读写配置、网站文件和日志。 一旦容器被删除，这些数据就永远丢失了。
  • 卷（Volume） ：由Docker管理的数据存储区域，独立于容器的生命周期。即使容器删除，卷依然存在。适合存储数据库文件、持久化日志等。
  • 绑定挂载（Bind Mount） ：将宿主机上的一个特定目录或文件，直接映射到容器内的路径。 这是我们管理Nginx配置和网站代码最推荐的方式。 因为你可以用熟悉的文本编辑器（如VS Code）在宿主机上修改配置，改动会立刻反映到容器内。

简单记忆：配置文件、网站代码用绑定挂载；需要长期保存且不常改动的数据（如大型文件）可以考虑用卷。

2.3 准备工作：确认你的Docker环境

请确保你的机器上已经安装了Docker并可以正常运行。打开终端，执行以下命令验证：

# 检查Docker版本和运行状态
docker --version
docker info

# 运行一个测试容器，验证Docker基础功能
docker run hello-world

如果 hello-world 容器能成功运行并输出欢迎信息，说明你的Docker环境基本就绪。如果遇到类似“Cannot connect to the Docker daemon”或“virtualization is not enabled”的错误，你需要根据你的操作系统（Windows/macOS/Linux）去查找如何正确启动Docker服务或启用虚拟化支持，这超出了本文的范围，但却是必须解决的前提。

3. 初体验：运行你的第一个Nginx容器

让我们从一个最简单的命令开始，直观感受一下。

docker run -d -p 8080:80 --name my-nginx nginx:alpine

逐参数解释：

  • docker run ：创建并运行一个新容器。
  • -d ：后台运行（detached mode）。
  • -p 8080:80 ：端口映射。将宿主机的 8080 端口映射到容器的 80 端口（Nginx默认监听80）。
  • --name my-nginx ：给容器起一个名字，方便后续管理（如停止、删除）。
  • nginx:alpine ：指定使用的镜像。我们选择 alpine 标签，因为它基于极简的Alpine Linux，镜像体积非常小（约10MB），适合生产环境。

执行后，打开浏览器，访问 http://localhost:8080 。你应该能看到Nginx经典的欢迎页面。

恭喜，你的第一个Nginx容器已经运行起来了！ 但现在的它只是一个“黑盒”，配置和日志都在容器内部，无法定制。我们接下来就要打开这个黑盒。

4. 核心实践：通过挂载自定义配置与静态资源

直接使用默认镜像毫无意义。我们的目标是使用自己的网站内容和配置。

4.1 项目目录结构规划

首先，在宿主机上创建一个清晰的项目目录。良好的结构是成功的一半。

mkdir -p ~/my-docker-nginx
cd ~/my-docker-nginx
mkdir -p conf.d html logs ssl
  • conf.d/ ：存放自定义的Nginx服务器块（server block）配置文件。
  • html/ ：存放你的网站静态文件（如 index.html , style.css , app.js ）。
  • logs/ ：用于持久化保存Nginx的访问日志和错误日志（从容器挂载出来）。
  • ssl/ ：存放SSL证书文件（如 cert.pem , key.pem ），用于HTTPS。

4.2 创建自定义静态页面

在 html 目录下创建一个简单的 index.html 。

cat > ~/my-docker-nginx/html/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>My Dockerized Nginx</title>
    <style>
        body { font-family: Arial, sans-serif; text-align: center; padding: 50px; }
        h1 { color: #333; }
        p { color: #666; }
    </style>
</head>
<body>
    <h1>🚀 Hello from Nginx inside Docker!</h1>
    <p>This page is served from a custom HTML file mounted into the container.</p>
    <p>Current time on server: <span id="time"></span></p>
    <script>
        document.getElementById('time').textContent = new Date().toLocaleString();
    </script>
</body>
</html>
EOF

4.3 创建自定义Nginx配置

Nginx的主配置文件通常是 /etc/nginx/nginx.conf ，它会包含 conf.d/*.conf 这样的目录。我们一般不直接覆盖主配置，而是在 conf.d 目录下添加我们的配置。

在 conf.d 目录下创建 default.conf ：

cat > ~/my-docker-nginx/conf.d/default.conf << 'EOF'
server {
    listen       80;
    server_name  localhost;

    # 访问日志和错误日志的路径
    # 这些路径是容器内的路径，我们会通过挂载映射到宿主机的 ./logs 目录
    access_log  /var/log/nginx/access.log  main;
    error_log   /var/log/nginx/error.log warn;

    location / {
        # 网站根目录，对应容器内的路径
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        # 一个有用的配置：尝试以 $uri/index.html 的形式查找目录下的index文件
        try_files $uri $uri/ /index.html;
    }

    # 定义一个简单的健康检查端点
    location /health {
        access_log off;
        return 200 "healthy\n";
        add_header Content-Type text/plain;
    }

    # 禁止访问 .ht 开头的隐藏文件
    location ~ /\.ht {
        deny all;
    }
}
EOF

这个配置定义了一个监听80端口的服务器，将根请求指向 /usr/share/nginx/html ，并设置了一个健康检查端点 /health 。

4.4 运行带有自定义配置和资源的容器

现在，我们使用绑定挂载，将宿主机上的目录“注入”到容器中对应的路径。

# 先停止并删除之前创建的测试容器
docker stop my-nginx
docker rm my-nginx

# 运行新的容器，并挂载我们的目录
docker run -d \
  -p 8080:80 \
  --name my-nginx \
  -v $(pwd)/html:/usr/share/nginx/html:ro \
  -v $(pwd)/conf.d:/etc/nginx/conf.d:ro \
  -v $(pwd)/logs:/var/log/nginx \
  nginx:alpine

挂载参数详解：

  • -v $(pwd)/html:/usr/share/nginx/html:ro
    • 将宿主机的 ./html 目录挂载到容器的 /usr/share/nginx/html 。
    • :ro 表示“只读”（read-only）。对于静态资源，设置为只读是安全最佳实践，防止容器内进程意外修改你的源代码。
  • -v $(pwd)/conf.d:/etc/nginx/conf.d:ro
    • 将宿主机的 ./conf.d 目录挂载到容器的 /etc/nginx/conf.d 。Nginx会自动加载此目录下所有 .conf 文件。
    • 同样设置为只读，保证配置的不可变性。
  • -v $(pwd)/logs:/var/log/nginx
    • 将宿主机的 ./logs 目录挂载到容器的 /var/log/nginx 。
    • 这里 没有 加 :ro ，因为Nginx进程需要向这个目录写入日志文件。

现在，再次访问 http://localhost:8080 ，你会看到我们自定义的HTML页面，而不是默认的欢迎页。同时，在宿主机的 ~/my-docker-nginx/logs 目录下，你会看到自动生成的 access.log 和 error.log 文件。

至此，你已经掌握了Docker部署Nginx最核心的模式：通过绑定挂载实现配置、代码、日志的宿主机管理。

5. 进阶场景一：作为反向代理（API网关）

Nginx更强大的功能是作为 反向代理 。假设你有一个运行在 localhost:3000 的Node.js API服务，你想通过Nginx来代理它，实现统一的入口、负载均衡或添加安全层。

5.1 修改Nginx配置

编辑 ~/my-docker-nginx/conf.d/default.conf ，将其替换为反向代理配置：

cat > ~/my-docker-nginx/conf.d/default.conf << 'EOF'
# 上游服务定义
upstream backend {
    # 这里可以配置多个后端服务器实现负载均衡
    server host.docker.internal:3000; # 关键点：在容器内访问宿主机服务
    # server backend2:3001; # 如果后端也在Docker中，可使用服务名
    # 负载均衡策略，如 ip_hash, least_conn 等
    # ip_hash;
}

server {
    listen       80;
    server_name  localhost;

    access_log  /var/log/nginx/access.log  main;
    error_log   /var/log/nginx/error.log warn;

    # 静态文件服务（可选）
    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        try_files $uri $uri/ /index.html;
    }

    # 反向代理到后端API
    location /api/ {
        # 移除请求路径中的 /api 前缀，再传递给后端（根据后端需求决定）
        # rewrite ^/api/(.*)$ /$1 break;

        proxy_pass http://backend/; # 注意结尾的斜杠，它会影响URI的传递
        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_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    location /health {
        access_log off;
        return 200 "proxy is healthy\n";
        add_header Content-Type text/plain;
    }
}
EOF

关键点解释：

  1. upstream backend : 定义了一个名为 backend 的上游服务器组。这里指向 host.docker.internal:3000 。 host.docker.internal 是Docker提供的一个特殊DNS名称， 用于从容器内部访问宿主机的服务 （在Windows/macOS的Docker Desktop和较新版本的Linux Docker中支持）。如果你的后端服务运行在宿主机上，就用这个。
  2. location /api/ : 所有以 /api/ 开头的请求，都会被转发到 http://backend （即上游服务器组）。
  3. proxy_set_header : 这些指令将客户端的真实IP、协议等信息传递给后端服务，对于后端日志记录和安全检查至关重要。

5.2 重新加载Nginx配置

我们不需要重启容器，Nginx支持热重载配置。有两种方式：

方式一：进入容器执行命令 

docker exec my-nginx nginx -s reload

nginx -s reload 命令会优雅地重新加载配置文件，不会断开正在处理的连接。

方式二：直接向Nginx主进程发送信号 

docker kill -s HUP my-nginx

重载后，访问 http://localhost:8080/api/your-endpoint ，Nginx就会将请求代理到你宿主机上 3000 端口的服务。

6. 进阶场景二：使用Docker Compose编排多服务

在实际项目中，Nginx很少单独存在，它通常与后端应用、数据库等服务协同工作。使用Docker Compose可以一键定义和启动整个应用栈。

6.1 创建 docker-compose.yml

在项目根目录 ( ~/my-docker-nginx ) 下创建 docker-compose.yml 文件。

version: '3.8'

services:
  # Nginx 服务
  nginx:
    image: nginx:alpine
    container_name: my-nginx-compose
    ports:
      - "8080:80"
      # 如果需要HTTPS，可以暴露443端口
      # - "8443:443"
    volumes:
      # 挂载自定义配置
      - ./conf.d:/etc/nginx/conf.d:ro
      # 挂载静态资源
      - ./html:/usr/share/nginx/html:ro
      # 挂载日志目录
      - ./logs:/var/log/nginx
      # 如果需要HTTPS，挂载SSL证书目录
      # - ./ssl:/etc/nginx/ssl:ro
    networks:
      - app-network
    # 依赖关系：确保backend服务先启动
    depends_on:
      - backend
    # 健康检查
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  # 示例后端服务（这里用一个简单的Node.js应用模拟）
  backend:
    image: node:18-alpine
    container_name: my-backend
    # 假设你的后端代码在 ./backend 目录下
    # volumes:
    #   - ./backend:/usr/src/app
    working_dir: /usr/src/app
    # 为了演示，我们直接运行一个简单的HTTP服务器
    command: >
      sh -c "
        echo 'const http = require(\"http\"); 
        const server = http.createServer((req, res) => {
          res.writeHead(200, {\"Content-Type\": \"application/json\"});
          res.end(JSON.stringify({ message: \"Hello from Backend API\", path: req.url, time: new Date().toISOString() }));
        }); 
        server.listen(3000, () => console.log(\"Backend listening on port 3000\"));' > server.js &&
        node server.js
      "
    networks:
      - app-network
    # 暴露端口给同一网络内的其他容器（这里是nginx）访问，不映射到宿主机
    expose:
      - "3000"
    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:3000/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3

# 定义自定义网络，方便服务间通过服务名通信
networks:
  app-network:
    driver: bridge

6.2 修改Nginx配置以使用服务名

更新 conf.d/default.conf 中的 upstream 部分，将 host.docker.internal 改为Docker Compose服务名 backend 。

upstream backend {
    server backend:3000; # 使用Docker Compose服务名
}

6.3 启动与管理整个应用栈

# 进入项目目录
cd ~/my-docker-nginx

# 启动所有服务（在后台运行）
docker-compose up -d

# 查看运行状态
docker-compose ps

# 查看所有服务的日志
docker-compose logs -f

# 停止所有服务
docker-compose down

# 停止并删除所有服务、网络、卷（数据卷不会被默认删除，需加 -v）
docker-compose down -v

现在，访问 http://localhost:8080/api/anything ，Nginx容器会通过内部网络 app-network 将请求代理到名为 backend 的后端容器。你实现了一个完全容器化、服务间通过名称发现的小型应用架构。

7. 常见问题与排查思路（Q&A）

在实际操作中，你几乎一定会遇到下面这些问题。这里提供了清晰的排查路径。

问题现象 可能原因 排查方式 解决方案
容器启动后立即退出 1. Nginx配置文件语法错误。
2. 挂载的宿主机目录不存在或权限不足。		 1. docker logs <container_name> 查看启动日志。
2. docker run -it --rm nginx:alpine nginx -t 测试默认配置。
3. 检查 docker run 命令中 -v 挂载的路径是否正确。		 1. 修正nginx.conf语法。
2. 确保宿主机目录存在，对于Linux，注意SELinux或目录权限（可尝试 chmod 755 ）。
3. 先不加 -d 参数运行，在前台查看输出。
访问 localhost:8080 报错 403 Forbidden 1. 挂载的 html 目录为空或 index.html 不存在。
2. Nginx进程权限无法读取挂载的文件。		 1. 检查宿主机 html/ 目录下是否有 index.html 。
2. 进入容器检查： docker exec -it my-nginx ls -la /usr/share/nginx/html 。
3. 查看Nginx错误日志： docker exec my-nginx cat /var/log/nginx/error.log 。		 1. 确保网站文件已放入正确目录。
2. 在Linux上，如果宿主机目录权限过严（如root所有），可调整权限或使用 :Z 或 :z 挂载选项（针对SELinux），或最简单的方式：确保文件对“其他用户”有读权限 ( chmod o+r )。
反向代理返回 502 Bad Gateway 1. 后端服务未启动或不可达。
2. proxy_pass 地址或端口错误。
3. 上游服务响应超时。		 1. 确认后端服务是否运行： docker-compose ps 或 docker ps 。
2. 在Nginx容器内测试连接后端： docker exec my-nginx curl -v http://backend:3000/health 。
3. 检查Nginx配置中的 upstream 和 proxy_pass 指令。
4. 查看Nginx错误日志，常有 connect() failed 等信息。		 1. 启动或重启后端服务。
2. 确保使用正确的容器服务名或宿主机地址（ host.docker.internal ）。
3. 调整 proxy_connect_timeout , proxy_read_timeout 等值。
4. 检查后端服务是否监听在 0.0.0.0 而非 127.0.0.1 。
修改配置文件后，Nginx不生效 1. 配置文件未挂载或挂载路径错误。
2. 修改后未重载Nginx配置。
3. 配置文件存在语法错误，重载被拒绝。		 1. docker exec my-nginx cat /etc/nginx/conf.d/default.conf 查看容器内实际内容。
2. docker exec my-nginx nginx -t 测试配置文件语法。
3. docker exec my-nginx nginx -s reload 后查看日志。		 1. 检查 -v 挂载路径，确保宿主机配置文件已保存。
2. 每次修改宿主机配置后，执行 docker exec my-nginx nginx -s reload 。
3. 根据 nginx -t 的输出修正语法错误。
Docker Desktop 启动失败，提示虚拟化未开启 系统BIOS/UEFI中的虚拟化技术（Intel VT-x/AMD-V）未启用，或Hyper-V/WSL2冲突。 1. Windows: 任务管理器 -> 性能 -> CPU，查看“虚拟化”是否已启用。
2. macOS: 确保系统版本支持。		 1. Windows: 重启进入BIOS，启用Intel Virtualization Technology或AMD SVM。
2. Windows Home版: 安装WSL2，Docker Desktop会使用它。
3. macOS: 通常自动支持，旧Intel Mac需在设置->安全中允许。
日志文件未在宿主机 logs/ 目录生成 1. 挂载的宿主机 logs 目录权限问题，Nginx worker进程（通常以 nginx 用户运行）无权写入。
2. 挂载路径错误。		 1. 检查宿主机 logs/ 目录的权限： ls -ld logs 。
2. 进入容器查看日志路径： docker exec my-nginx ls -la /var/log/nginx/ 。		 1. 最简单方案：在宿主机上 chmod 777 logs （仅用于开发测试）。
2. 更安全的方案：在宿主机创建目录时指定合适的所有者，或使用Docker的 user 指令让容器以特定用户运行。

8. 生产环境最佳实践与建议

当你准备将Docker化的Nginx用于生产环境时，以下建议能帮你提升安全性、可靠性和可维护性。

8.1 使用非root用户运行Nginx进程

默认的 nginx 镜像以 root 用户启动，但Nginx主进程会降权到 nginx 用户。为了更安全，你可以强制容器以非root用户运行。

# 在 docker-compose.yml 中
services:
  nginx:
    image: nginx:alpine
    user: "1000:1000" # 使用宿主机上的某个非root用户UID和GID
    # ... 其他配置

或者通过Dockerfile构建自定义镜像：

FROM nginx:alpine
RUN chown -R nginx:nginx /var/cache/nginx /var/log/nginx
USER nginx

注意 ：这可能会与挂载目录的权限产生冲突，需要提前协调好宿主机目录的所有权和权限。

8.2 优化Nginx配置参数

在 nginx.conf 或 conf.d 下的配置中，根据你的服务器硬件和业务特点进行调整。

  • Worker进程 ： worker_processes auto; （自动设置为CPU核心数）。
  • 连接数 ： worker_connections 1024; （根据系统 ulimit -n 调整）。
  • 启用Gzip压缩 ：减少静态资源传输体积。
  • 设置缓存 ：对于静态资源，设置 expires 头，利用浏览器缓存。
  • 限制请求体大小 ： client_max_body_size 10m; 防止过大请求攻击。

8.3 日志管理

生产环境日志至关重要。

  • 日志轮转（Log Rotation） ：Nginx容器本身不处理日志轮转。你有两个选择：
    1. 使用宿主机日志轮转工具 ：如 logrotate ，配置其监控挂载出来的日志文件。
    2. 将日志发送到标准输出（stdout/stderr） ：修改Nginx配置，将 access_log 和 error_log 指向 /dev/stdout 和 /dev/stderr ，然后使用Docker的日志驱动（如 json-file , journald , 或 syslog ）来收集和管理。这是容器化应用更推荐的方式。 
      access_log /dev/stdout main;
error_log /dev/stderr warn;
  • 敏感信息过滤 ：确保日志中不会记录密码、令牌等敏感信息。

8.4 健康检查与监控

如Docker Compose示例所示，为服务配置 healthcheck 。在Kubernetes中，使用 livenessProbe 和 readinessProbe 。这使编排工具能自动重启不健康的容器。

8.5 使用自定义镜像

对于生产环境，建议基于官方镜像构建自定义镜像，将固定的配置文件、SSL证书等打包进去，减少对运行时挂载的依赖，提升启动速度和一致性。

FROM nginx:alpine
# 复制自定义配置文件
COPY conf.d/ /etc/nginx/conf.d/
# 复制静态网站文件
COPY html/ /usr/share/nginx/html/
# 复制SSL证书（如果有）
COPY ssl/ /etc/nginx/ssl/
# 暴露端口
EXPOSE 80 443
# 可以在此运行一些初始化脚本

然后构建并推送至你的私有镜像仓库： docker build -t my-company/nginx:latest .

8.6 网络安全

  • 最小化暴露端口 ：只将必要的端口（如80, 443）映射到宿主机。后端服务的端口仅在Docker网络内部暴露。
  • 使用安全网络 ：在Docker Compose或K8s中，为不同分层的服务（如前端、后端、数据库）创建独立的网络。
  • 定期更新镜像 ：定期拉取 nginx:alpine 镜像的新版本，以获取安全补丁。

从最简单的 docker run nginx 到通过Docker Compose编排一个包含反向代理的完整应用栈，我们完整走通了在Docker中使用Nginx的核心路径。关键在于理解 “数据（配置、代码、日志）与容器分离” 这一原则，并通过 卷挂载 将其实现。

这篇文章提供的配置文件和命令，你可以直接复制到自己的项目中修改使用。记住，在容器化世界里，一切皆可定义为代码。你的Nginx配置、你的应用依赖、你的运行环境，都被固化在了 Dockerfile 、 docker-compose.yml 和一堆配置文件中。这带来了前所未有的可重复性和团队协作效率。

下一步，你可以探索：

  1. 集成HTTPS ：在 ssl/ 目录放置证书，并配置Nginx的 server 块监听443端口，实现安全的HTTPS访问。
  2. 更复杂的负载均衡策略 ：在 upstream 中配置多台服务器，并尝试 least_conn 、 ip_hash 等算法。
  3. 与CI/CD流水线集成 ：将构建Nginx自定义镜像、部署容器的步骤自动化。
  4. 学习Kubernetes ：当你的服务越来越多时，Kubernetes是管理容器化应用的更强大平台，其 Ingress 资源本质上就是基于Nginx等实现的集群入口控制器。

希望这篇长文能成为你容器化Web服务部署的实用手册。如果在实践中遇到新的问题，不妨回头看看“常见问题”部分，或者深入查阅Nginx和Docker的官方文档——它们永远是最权威的信息来源。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区