如何配置Nginx指向Docker容器内的应用public文件夹？

背景问题 #

传统部署时，我们通过Nginx直接指向宿主机的应用public目录处理静态资源，配置如下：

server {
  ...
  root /home/app/public;

  location ~ ^/(assets) {
    expires max;
    gzip_static on;
  }
  ...
}

迁移到Docker容器后，应用的public目录位于容器内部，宿主机Nginx无法直接访问，导致静态资源请求返回404。目前只能移除Nginx的静态资源规则，转而依赖应用自身（比如Rails开启config.public_file_server.enabled = true）提供静态文件服务，但这会把静态资源的处理压力转移到应用进程，性能表现不理想。

尝试过挂载宿主机目录到容器：

docker run --name app -v /home/app/public:/var/app/public

但这种方式会带来新问题：宿主机和容器的文件可能冲突，更新容器时需要手动清理宿主机上的过期指纹化资产，维护成本高。

可行解决方案 #

1. Nginx反向代理+缓存层（无需挂载目录） #

不用挂载目录，让Nginx把静态资源请求转发给容器，同时通过Nginx添加缓存规则，后续请求直接从Nginx缓存返回，避免重复打到应用：

server {
  ...
  # 动态请求转发到应用容器
  location / {
    proxy_pass http://your-app-container:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }

  # 静态资源请求转发到容器，同时由Nginx缓存
  location ~ ^/(assets) {
    proxy_pass http://your-app-container:3000;
    expires max;
    gzip_static on;
    proxy_cache static_cache;
    proxy_cache_valid any 1y;
  }
  ...
}

这种方式兼顾了性能和易用性，不用维护挂载目录，Nginx负责缓存后，大部分静态请求不会占用应用资源。

2. 静态资源预构建到Nginx镜像（性能最优） #

如果你的静态资源是构建时生成的（比如Rails执行assets:precompile），可以把预编译好的静态资源直接打包到Nginx镜像中，让Nginx直接读取本地文件：

• 应用构建阶段执行静态资源预编译，生成public/assets目录
• 构建Nginx镜像时，将public/assets复制到Nginx的静态资源目录（如/usr/share/nginx/html/assets）
• Nginx配置：

server {
  ...
  # Nginx直接处理静态资源
  location ~ ^/(assets) {
    root /usr/share/nginx/html;
    expires max;
    gzip_static on;
  }

  # 动态请求转发到应用容器
  location / {
    proxy_pass http://your-app-container:3000;
    proxy_set_header Host $host;
  }
  ...
}

这种方式完全让Nginx承担静态资源处理，应用只处理动态请求，性能最优，也没有挂载目录的维护问题。需要配合CI/CD流程，确保应用版本更新时同步更新Nginx镜像中的静态资源。

3. 用Docker命名卷优化挂载方案 #

如果一定要用挂载，改用Docker命名卷替代宿主机绑定挂载，由Docker统一管理卷的生命周期，避免宿主机文件冲突：

# 应用容器挂载命名卷
docker run --name app -v app-public:/var/app/public
# Nginx容器挂载同一个命名卷
docker run --name nginx -v app-public:/usr/share/nginx/html/public --link app:app ...

Nginx可以直接访问命名卷中的静态资源，更新容器时可以通过重新构建卷内容来同步静态资源，比直接挂载宿主机目录更易维护，但仍需处理资源同步问题。

总结 #

• 追求性能和简洁性，优先选择静态资源预构建到Nginx镜像的方案，适合有自动化CI/CD流程的场景；
• 不想修改镜像构建流程，可采用Nginx反向代理+缓存的方案，兼顾性能和易用性；
• 挂载卷方案适合特殊场景，推荐用Docker命名卷优化，减少维护成本。

内容的提问来源于stack exchange，提问作者Cameron