1. 环境隔离与反向代理先搞清楚这套组合到底在解决什么问题我经常在面试里问候选人一个问题“你在本机跑得好好的服务为什么一上服务器就挂了”十个人里有八个会回答环境问题、依赖问题、版本问题但真正能把这个答案落到技术层面、讲清楚“环境隔离”到底是什么的人少之又少。这就是 Docker 存在的最根本理由——把应用连同它运行所需要的一切打包在一起让在我机器上能跑变成在哪都能跑。另一个面试必考点就是 Nginx 的反向代理。很多刚入行的人把 Nginx 当成一个 Web 服务器用来托管静态页面。这么理解没错但远远不够。在现代的微服务、前后端分离、容器化部署架构里Nginx 更多时候扮演的是一个流量入口、请求中转站的角色——用户只访问 80 或 443 端口至于请求该转发给哪个后端服务、要不要做负载均衡、要不要缓存静态资源全部由 Nginx 说了算。反向代理就是它行使这种权力最核心的手段。我见过太多运维工程师把 Docker 和 Nginx 拆开学最后发现两者根本是紧密咬合的一对。用 Docker 跑 Nginx 几乎是生产环境里最普遍的用法之一Nginx 容器做反代后端服务也用容器跑起来Nginx 把请求转发给容器网络中其他服务的地址。这套架构从个人项目的单机部署到大厂的 Kubernetes 集群链路逻辑是一脉相承的。所以这篇文章我不打算只讲命令而是把原理、实操、排查串成一条线让你不仅知道怎么敲更知道为什么这么敲。适合正在准备运维、DevOps 方向岗位面试的读者也适合刚接触 Docker 和 Nginx、想系统入门的人。1.1 环境隔离到底“隔离”了什么很多人以为环境隔离只是把不同的服务装在不同的目录里这是个误区。Docker 的隔离是操作系统层面的它通过 Linux 内核的 Namespace 和 Cgroups 两个机制给每个容器一份“独立”的系统视图和资源配额。Namespace 做的是“看得见”的隔离它负责让容器内的进程只看到属于自己的进程列表、网络栈、文件系统挂载点、主机名等。比如容器 A 里执行ps -ef只能看到自己内部的进程看不到容器 B 的进程。Cgroups 做的是“用多少”的限制它负责分配 CPU、内存、磁盘 IO 等硬件资源。举个例子你可以在启动容器时指定--memory512m这个容器最多只能用 512MB 内存超过就会被强制杀掉或触发 OOM不会影响宿主机上其他进程。用生活里的场景类比Namespace 相当于每个人住在自己独立的房间里互相看不到对方的摆设Cgroups 则是物业对每套房的用电、用水做了上限避免谁家疯狂用电导致整栋楼跳闸。理解了 Docker 靠内核机制做隔离你就能回答面试里那个经典问题了“Docker 和虚拟机有什么区别”虚拟机的隔离是硬件级的每一台虚拟机都有自己的操作系统内核Docker 容器是进程级的所有容器共享宿主机内核。所以容器启动快、占用小但隔离性不如虚拟机。这不是谁好谁坏而是取舍。1.2 Nginx 为什么能扛住高并发面试里另一个高频问题“Nginx 为什么性能这么好”答案的核心在它的事件驱动模型。传统 Web 服务器比如早期的 Apache一个进程或线程只能处理一个连接连接多了就要创建大量线程内存和上下文切换开销很大。Nginx 采用的是异步、非阻塞、事件驱动模型它用少量的 worker 进程就能处理成千上万的并发连接。说得再通俗一点传统的服务模式像银行柜台一个柜员服务一个客户客户多了就得开很多窗口但柜员多了成本也高了而 Nginx 的模式更像一个灵活的接待员他记住每个客户的需求不需要一直陪着客户等业务窗口空闲了再带客户过去办。所以 Nginx 的并发能力强本质上是它把大量时间花在等待上的连接用很少的资源就管理起来了。Nginx 的架构分为 master 进程和 worker 进程。master 进程负责读取和验证配置文件、管理 worker 进程的生命周期真正干活的是 worker 进程处理请求、转发请求、读写日志都是它们。生产环境调优时一个常见的设置是worker_processes auto让 Nginx 根据 CPU 核心数自动决定 worker 数量。每个 worker 能处理的最大并发连接数由worker_connections控制。举个具体的计算例子你的机器是 4 核worker_processes设为 4worker_connections设为 10240那理论上 Nginx 能支撑的最大并发连接数就是 4 × 10240 40960。当然这只是理论值实际还受文件描述符上限、带宽、后端服务处理能力等影响但这个公式你自己要能算出来面试时直接甩出来很加分。1.3 为什么这套组合是运维面试必考点我不止一次说过运维工程师面试基本绕不开两个维度一是“能不能把服务稳定跑起来”二是“出问题时能不能快速定位”。Docker 和 Nginx 刚好分别对应了这两个维度的核心场景。Docker 考的不仅仅是几条命令它考的是你对环境一致性、交付方式、资源隔离、故障恢复的理解。比如上线一个 Java 应用传统方式是在服务器上装 JDK、配置环境变量、丢 jar 包、写 systemd 服务用 Docker 的话你只需要一个包含 JDK 和应用的镜像启动容器即可。这个变化看着简单背后却涉及交付物形态的变化——交付的内容从“代码 部署文档”变成了“一个镜像”。这就是为什么现在很多公司把“容器化改造”作为运维和研发协作的核心项目。面试官问 Docker实际是在考察你有没有把这种交付思路用到实际工作中的意识。Nginx 考的也远不止配置语法。它考的是你对请求链路、网络转发、负载均衡策略、稳定性配置的理解。比如高可用场景下 Nginx 自身挂了怎么办比如后端服务重启时怎么做到平滑升级不起服务中断比如proxy_pass后面有没有斜杠会引发什么样的转发差异。这些问题看着细但恰恰是生产环境里最容易坑人的地方。把 Docker 和 Nginx 组合在一起考是因为这两者在真实架构里往往是一起出现的——用 Docker 部署 Nginx、用 Nginx 代理容器内的服务这套链路本身就是微服务架构里的关键骨架。2. 从镜像到容器把镜像、容器、数据卷、网络模式一次讲透Docker 最核心的三个概念——镜像、容器、数据卷很多人只是背定义没有真正吃透它们之间的关系。我来换个角度讲镜像是一个只读的模板容器是基于模板运行起来的一个实例进程数据卷是容器外部的一块持久化存储。你可以把镜像理解成做蛋糕用的模具模具本身是固定的不管你烤几次蛋糕模具都不会变。每次用模具烤出来的蛋糕就是容器——它们长得相似但都是独立的个体。问题在于蛋糕如果不做保鲜处理过几天就变质了这就像容器里的数据容器一删里面产生的文件、日志、数据库数据全部消失。所以 Docker 引入了数据卷Volume它的作用就是把容器产生的数据放到宿主机上实现容器与数据的分离。这样哪怕容器被删了重建数据还在。2.1 镜像的分层结构为什么 Docker 镜像下载快、占用省镜像可能是 Docker 中最值得理解的设计。它采用分层Layer存储结构每一层都是只读的。从 Dockerfile 构建镜像时每一行指令如RUN apt-get install、COPY都会生成一层。多个镜像可以共享底层的公共层这就是为什么你拉取一个基于 Ubuntu 的镜像时如果本地已经有另一个 Ubuntu 镜像很多层不用重复下载速度快很多。分层设计还带来一个很重要的能力容器在运行时Docker 会在镜像最上层加一个可写层。你对容器内文件的修改、新增、删除都发生在这个可写层里。这意味着多个容器可以共享同一个镜像互相不影响各自的可写层。类比来说镜像像一张光盘内容是只读的、固化的容器像在光盘上面铺了一张透明薄膜你在薄膜上写写画画光盘内容始终不变。这也是为什么容器启动只需要新建一个可写层所以启动速度能做到毫秒级。实操中写 Dockerfile 有一条重要经验把不容易变化的指令放在前面把容易变化的指令放在后面。比如先COPY依赖锁定文件如requirements.txt、package.json执行依赖安装再COPY项目源代码。这样依赖层可以缓存你改代码重新构建时不会触发依赖重装。我见过很多新手把COPY . .写在前头导致每次改一行代码都要重新下载几百兆的依赖构建时间直接翻好几倍。面试如果问“镜像构建怎么优化”这条一定要讲出来。2.2 容器网络模式bridge、host、none 到底怎么选容器跑起来之后第一个要解决的就是网络问题。Docker 默认提供几种网络模式最常见的是 bridge桥接模式、host主机模式和 none无网络模式。面试里常问到生产环境里也真的会用。默认的 bridge 模式相当于 Docker 给每个容器分配一个独立的网络命名空间再通过一个虚拟网桥docker0让容器和宿主机通信。在这种模式下容器有自己独立的 IP比如 172.17.0.x外部网络不能直接访问容器的 IP需要做端口映射-p 8080:80把宿主机的 8080 端口流量转发到容器的 80 端口。这是最常用的模式也是我们部署 Nginx 容器时默认使用的网络方案。host 模式则完全不同容器直接共享宿主机的网络命名空间没有独立 IP、不隔离端口。它的好处是网络性能极高因为没有一层 NAT 转发坏处是容器的端口不能和宿主机的端口冲突而且隔离性变差。遇到对网络性能极致敏感的场景比如一些视频流处理、高频金融交易类应用有人会选 host 模式但日常业务基本用不到。还有一种使用频率很高但很多人没意识到它是网络模式的场景Docker Compose 创建的自定义 bridge 网络。在自定义网络中容器之间可以通过服务名直接互相访问不需要关心彼此的 IP 地址。比如你用 docker-compose 同时启动了一个 Nginx 服务和一个后端 API 服务Nginx 配置文件里直接写proxy_pass http://backend:8080就能访问到后端的容器Docker 内置的 DNS 会自动完成域名解析。这个特性太重要了配置 Nginx 反向代理指向容器时它让你彻底告别了手动查 IP 然后硬编码的痛苦。2.3 数据卷和挂载容器删了数据不能丢容器本身是瞬时的但你的数据必须持久化。这就引出了 Docker 的挂载机制。最常用的是 bind mount绑定挂载它把宿主机的一个目录直接挂到容器内部的某个路径。比如我们部署 Nginx 时把宿主机上的/data/nginx/html挂载到容器内的/usr/share/nginx/html这样容器里的 Nginx 提供的就是宿主机这个目录下的文件改文件不需要进容器直接编辑宿主机文件就行。还有一种是 named volume命名卷由 Docker 管理卷的生命周期数据存在 Docker 指定的目录中。你只需要在命令里写一个名字比如-v nginx-logs:/var/log/nginxDocker 会帮你创建和管理这个卷。相比 bind mount命名卷和数据的心智负担更小因为你不用关心它在宿主机上的具体位置Docker 自己维护。生产环境推荐优先使用命名卷因为它跨主机迁移、备份、恢复都更方便。挂载这里有一个非常经典的坑权限问题。你会在下一节看到具体案例但先记住一个原则挂载后容器内进程对目录的读写权限取决于宿主机目录的权限和容器进程的有效 UID 是否匹配。很多 Nginx 容器挂载目录后报Permission denied十有八九是这个原因。解决办法要么修改宿主机目录权限要么用--user参数指定容器进程的 UID要么在 Dockerfile 里提前做好目录权限声明。我后面会再展开。3. Docker 部署 Nginx 实操全流程从安装到挂载多个项目目录原理讲完必须上手这一节我把从零到一的完整流程走一遍。环境以 Linux 服务端为主Windows 和 macOS 版本的 Docker Desktop 逻辑一致只是安装包不同命令基本通用。3.1 Docker 安装与镜像源的配置Linux 上安装 Docker 的常规做法是用官方脚本一行命令搞定但国内网络环境下经常会遇到下载慢甚至超时的问题。这里我不展开任何所谓第三方加速的细节直接说一个官方支持的、合法稳定的做法配置 Docker 官方的镜像仓库站点并把registry-mirrors指向可用的公共镜像加速地址这个地址需要你自己根据网络环境查找和验证。如果你发现某个加速地址不稳定换一个再试这属于最基础的网络调优操作。安装完成之后连续执行systemctl start docker和systemctl enable docker前者启动服务后者设置开机自启这两步别漏掉。验证是否安装成功执行docker version如果客户端和服务端版本都正常显示说明组件都装好了。注意如果执行docker ps时报权限错误说明当前用户不在 docker 用户组里执行sudo usermod -aG docker $USER然后重新登录即可这个也是高频操作。再强调一个小细节Linux 上手动安装 Docker 的方式其实更可控这里给出一段可参考的步骤——解压二进制包、生成 systemd 服务配置然后启动服务。这个方式适合对默认包管理器版本不满意的人但我个人建议新手直接用发行版仓库安装版本虽然不是最新但是经过了充分测试稳定性优先。生产环境我宁可要一个稳定的老版本也不追新。3.2 拉取 Nginx 镜像并启动容器安装好 Docker 后跑 Nginx 容器只需要三件事拉镜像、写映射、起容器。先拉镜像docker pull nginx这个命令默认从官方仓库拉取最新版 Nginx 镜像时间取决于网络状况。启动一个最简单的容器测试docker run -d --name my-nginx -p 8080:80 nginx-d表示后台运行--name给容器命名-p 8080:80把宿主机的 8080 端口映射到容器的 80 端口。访问http://服务器IP:8080如果能出现 Nginx 的欢迎页说明容器已经正常工作了。这个欢迎页就是镜像默认放在/usr/share/nginx/html/index.html里的文件。用docker ps可以看到容器运行状态。停止和删除容器分别是docker stop my-nginx和docker rm my-nginx。这里注意docker stop只是停止进程容器还在还能docker start再拉起来docker rm才是彻底删除。想只需要一条命令加-f参数强制删除但正常操作我不推荐因为强制删除会跳过优雅终止流程可能造成数据不一致。3.3 挂载多个项目目录的核心配置实际工作里你不会满足于跑一个默认欢迎页。最常见的需求是宿主机上有好几个项目目录Nginx 容器要分别给它们提供服务。比如两个前端项目一个在/data/www/site-a另一个在/data/www/site-b。这时候你的启动命令要加上多个挂载参数docker run -d \ --name nginx-prod \ -p 80:80 \ -p 443:443 \ -v /data/www/site-a:/usr/share/nginx/html/site-a:ro \ -v /data/www/site-b:/usr/share/nginx/html/site-b:ro \ -v /data/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /data/nginx/conf/conf.d:/etc/nginx/conf.d:ro \ -v /data/nginx/logs:/var/log/nginx \ nginx这里有几个关键知识点。:ro表示只读挂载宿主机目录里的内容容器内只能读不能写这是保护静态资源的一种好习惯。配置文件用只读挂载是为了防止在容器内误改配置日志目录不做只读因为 Nginx 要向里面写日志。挂载配置文件时有个大坑如果你直接把整个宿主机目录挂到/etc/nginx/conf.d而这个目录在宿主机上是空的容器内原有的默认配置就全没了。很多教程让你创建一个宿主机目录挂进去打开浏览器发现 403 或者什么都不显示原因就是配置文件丢失或者权限不匹配。合理做法是先把容器里的默认配置拷出来再挂载修改过的版本。具体命令docker cp nginx-prod:/etc/nginx/conf.d/default.conf /data/nginx/conf/conf.d/default.conf先拷出来再改挂载参数这样既有模板可改又不至于丢失关键配置。如果你已经建了空目录挂载启动后想检查问题用docker logs nginx-prod看 Nginx 报错它会明确告诉你找不到配置文件或目录权限有问题。3.4 Docker Compose多服务编排的正确姿势当你的 Nginx 后面不止一个服务时一条条敲docker run就有点原始了。生产环境我强烈建议用 Docker Compose 来管理。它通过一个docker-compose.yml文件描述所有服务的镜像、端口、挂载、网络和环境变量一条docker-compose up -d全部拉起管理起来清爽得多。举个实际例子你有一个 Nginx 反代服务和一个后端 API 服务version: 3.8 services: nginx: image: nginx:1.24-alpine container_name: api-gateway ports: - 80:80 - 443:443 volumes: - /data/nginx/conf/conf.d:/etc/nginx/conf.d:ro - /data/nginx/html:/usr/share/nginx/html:ro - /data/nginx/logs:/var/log/nginx - /data/nginx/cert:/etc/nginx/cert:ro networks: - app-net restart: always backend: image: node:18-alpine container_name: backend-api volumes: - /data/apps/backend:/app working_dir: /app command: node server.js networks: - app-net restart: always networks: app-net: driver: bridge这段配置把 Nginx 和后端服务放在同一个自定义 bridge 网络中。Nginx 的 server 配置里写proxy_pass http://backend:3000就能直接命中后端服务。这个方案我用了好几年稳定可靠。用 Compose 还有一个额外好处配置变更后执行docker-compose up -d --build它只重建有变动的服务没变的服务保持不变。这比写一堆脚本去 stop、rm、run 要可靠太多。4. Nginx 核心配置拆解把 nginx.conf 和反向代理吃透很多运维面试题表面在问 Nginx实际都在同一个底盘上转——你对配置文件的理解深度。Nginx 的配置文件是树形结构不是脚本语言理清层级就不怕看不懂任何一份 nginx.conf。4.1 配置文件结构与全局块、events、http 块的作用Nginx 的主配置文件通常叫nginx.conf位于/etc/nginx/nginx.conf。它的结构大致分三块全局块、events 块、http 块。全局块里主要配置 Nginx 主进程和 worker 进程的行为。比如user nginx;指定运行 worker 进程的系统用户worker_processes auto;让 worker 数量和 CPU 核心数保持一致。events 块里的核心配置是worker_connections它定义了每个 worker 进程能同时打开的最大连接数直接影响并发能力。http 块是配置的核心区域它包含与被代理的服务、请求路由、缓存、日志相关的所有指令比如server块、location块、upstream块全部嵌套在 http 块内部。这种分层的结构对于理解 Nginx 的行为至关重要。简单来说events管的是 Nginx 自身网络模型的行为http管的是对 HTTP 请求的处理逻辑。面试官如果问你“修改了 worker_processes 需要重启还是 reload”答案是reload即可平滑生效因为 master 进程会重新读取配置并启动新的 worker 进程旧的 worker 在处理完当前请求后自动退出整个过程中连接不中断。4.2 反向代理与正向代理一字之差方向相反先把这个概念理清。正向代理是帮客户端转发请求比如你在公司内网访问外网通过一台代理服务器出去服务器不知道真正的客户端是谁只知道请求来自代理服务器。反向代理是帮服务器接收请求客户端的请求先到达代理服务器代理服务器再转发给后端的真实服务客户端不知道请求最终由哪台服务器处理。Nginx 作为反向代理最典型的配置长这样server { listen 80; server_name example.com; location / { proxy_pass http://backend_service; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } upstream backend_service { server 192.168.1.10:8080; server 192.168.1.11:8080; }proxy_pass指定了请求要转发到的目标地址。upstream块定义了一组后端服务器Nginx 会按照默认的轮询算法把请求依次分发到不同服务器上这就是负载均衡。proxy_set_header这三行很多人不理解但生产环境必须写。Host $host把客户端访问的域名原样传给后端保证后端能做基于域名的路由X-Real-IP和X-Forwarded-For把客户端的真实 IP 传递到后端。如果不加这三行后端服务看到的 IP 永远是 Nginx 的 IP日志排查、安全限制、风控逻辑全部无效。这是我见过的最高频的配置遗漏之一。4.3 proxy_pass 的斜杠陷阱一个字符引起的转发差异proxy_pass后面地址末尾有没有斜杠直接决定转发时把客户端请求的哪些部分拼到后端地址上这是我当初踩过最深的一个坑也是面试中很容易被问到的细节。假设 Nginx 配置了location /api/后端地址是http://backend_service如果proxy_pass http://backend_service;末尾无斜杠那么请求/api/users会原样转发成http://backend_service/api/usersURI 中匹配部分的路径保留。如果proxy_pass http://backend_service/;末尾有斜杠那么请求/api/users会变成http://backend_service/users匹配部分的/api/被替换成/。这两种行为有本质差异。如果你的后端接口本来就带有/api前缀用无斜杠如果后端接口没有这个前缀你想把/api这一层剥掉用有斜杠。实际工作中我曾经因为敲多了一个斜杠导致所有接口 404 又排查了半天后来发现是转发路径多了个斜杠导致整个路由不匹配。这种问题从日志看不出来明显的报错最直接的排错方式是打开 Nginx 的日志看实际转发出去的请求行是什么样的。这也是为什么我后来一直强调排错要先看日志再猜问题。4.4 location 匹配规则和 try_files 的用法location是 Nginx 配置中最重要的指令之一它的匹配规则直接决定每个请求去了哪个处理逻辑。Nginx 的 location 匹配有优先级精确匹配最高其次是前缀匹配加通配符^~再其次是正则匹配~或~*区分大小写和不区分大小写最后才是普通的前缀匹配。举个例子location /favicon.ico { log_not_found off; access_log off; } location ^~ /static/ { alias /data/www/static/; expires 7d; } location ~* \.(js|css|png|jpg)$ { expires 30d; add_header Cache-Control public, no-transform; } location / { proxy_pass http://backend_service; }这个配置的含义是精确匹配/favicon.ico时直接不记日志/static/前缀的请求直接找本地静态文件并设置 7 天过期所有 js、css、png 等静态资源设置 30 天缓存其他请求全部走反向代理。try_files也是一个高级用法它按顺序尝试文件是否存在存在就返回文件不存在就重写到指定路径。常见场景是单页应用SPA的前端路由用户在浏览器里直接访问/about这个路径但这个路径在后端并不存在真实文件需要把请求交给index.html去处理让前端路由接管location / { try_files $uri $uri/ /index.html; }这段配置先尝试$uri请求的路径对应的真实文件再尝试$uri/目录下的 index 文件都找不到就回退到/index.html。没有这一行用户刷新刷新单页应用的子页面就会直接 404这是前后端分离部署里最容易踩的坑之一。5. Docker 与 Nginx 组合运维日志、证书、重启策略与最佳实践到了组合应用的环节。单学 Docker 和单学 Nginx 是一条线把两者合在一起用才更接近生产的真实状态。这个章节聚焦实际运维中最高频的几个场景。5.1 容器内配置 Nginx 的三种姿势与选择建议在 Docker 里使用 Nginx有三种配置方式各有适用场景。第一种是直接进入容器修改配置。用docker exec -it nginx-prod bash进入容器终端用 vi 或 vim 修改配置文件。这种方式最直接但问题也很明显容器一旦被删除重建所有修改全部丢失属于不可重复、不可审计的操作。所以这种方式我一般只用来做临时调试看看容器里的默认配置长什么样从不在生产环境用它做配置变更。第二种是我前面提过的 bind mount把宿主机上的配置文件目录挂载进容器。这是生产环境最推荐的方案因为配置文件和容器生命周期解耦了——你可以在宿主机上任意编辑配置然后用docker exec nginx-prod nginx -s reload让 Nginx 平滑加载新配置优雅地实现配置变更。第三种是把配置打进镜像里。这种方式适合需要同步交付到多套环境的场景——你把自定义配置文件写进 Dockerfile 并构建一个新镜像发布时直接拉镜像配置跟着镜像走。比如公司内部写好一套标准化的 Nginx 安全基线配置用 Dockerfile 构建成nginx-secured:1.24镜像所有业务线都基于这个镜像启动容器配置管理就统一了。三种方案的取舍核心是你要“灵活可改”还是要“交付统一”。临时调试选第一种生产固定环境选第二种发布到多套环境且需要配置固化选第三种。我见过一些公司两种混合使用基础镜像内置基线配置运行时再用挂载方式覆盖部分差异化配置这是一种比较成熟的折中方案。5.2 HTTPS 证书挂载容器里的证书更新不能重启容器现在部署服务基本都是 HTTPS 起步而且 Nginx 容器里配置证书有一个痛点证书更新后如何优雅生效。你当然可以整个容器重启但这意味着所有连接中断一次对于高可用的系统这是一个不小的风险。更合理的方法是把证书文件放在宿主机上通过卷挂载让容器读取证书更新时直接替换宿主机上的证书文件然后执行docker exec nginx-prod nginx -s reload让 Nginx 平滑加载新证书期间连接不断开。Nginx 的 HTTPS server 配置核心就几行server { listen 443 ssl http2; server_name example.com; ssl_certificate /etc/nginx/cert/example.com.pem; ssl_certificate_key /etc/nginx/cert/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; }ssl_certificate和ssl_certificate_key指向容器内部的证书路径这个路径实际对应宿主机上挂载进去的目录。建议再做一个计划任务来自动检测证书过期时间到时间自动替换文件并执行 reload实现证书的无人值守更新。这里有一个细节Nginx reload 会在新连接使用新证书已建立的连接继续使用旧证书直到连接结束所以这个过程不会出现服务中断。5.3 容器日志管理策略别让日志撑爆磁盘Docker 容器运行久了最大的隐患之一就是日志文件无限增长。默认情况下 Docker 会把容器的标准输出和标准错误写到一个 json 文件里如果你的应用日志量大这个文件会以肉眼可见的速度膨胀最后把磁盘写满。我在生产环境里见过一次比较典型的故障容器跑了三个月日志文件把 40GB 的磁盘占满宿主机上所有依赖磁盘的服务全部卡死。后来排查才发现是 Docker 默认日志驱动不限制文件大小应用又在大地震后疯狂打日志。那次之后我把所有容器的日志配置统一修改了docker run -d \ --log-opt max-size10m \ --log-opt max-file3 \ --name nginx-prod \ nginx这组参数的意思是每个日志文件最大 10MB最多保留 3 个文件超过就滚动覆盖。还可以在 Docker daemon 配置里加全局默认值这样所有容器都默认带上日志限制。对于 Nginx 容器还有一件事很重要Nginx 本身的 access log 和 error log 如果挂载到宿主机要注意这些日志文件同样也会增长。生产环境一般按天切分日志具体切分方式可以用 logrotate 配置一条也可以用 shell 脚本配合计划任务来做。这块不做好的话你迟早会被磁盘报警叫起来一次。5.4 重启策略与优雅停止容器挂了怎么自愈容器的自愈能力靠--restart策略来保证。生产环境我几乎每个容器都会加上--restart always意思是容器不管因为什么原因退出Docker 都会自动把它拉起来。这个策略在意外崩溃、服务器重启后都有效。具体的策略有几种no默认值容器退出后不自动重启always总是重启即使容器是手动停止的Docker 服务重启后也会自动启动它unless-stopped总是重启但如果你手动停止了容器Docker 服务重启后不会自动启动它on-failure只在异常退出时重启正常停止不重启unless-stopped是我个人的首选因为它避免了一个常见问题你明确停止了某个不用的容器服务器一重启它又自动起来了你说气不气。always则一定会这样。还有一件事值得记下停止容器时docker stop会向容器发送 SIGTERM 信号等待容器内的进程优雅退出如果等了一段时间还没退出就会发送 SIGKILL 强制杀死。这个等待时间默认是 10 秒。如果你要停止的是 Nginx 这类处理大量活跃连接的容器建议先把流量从它身上摘掉比如在负载均衡设备上调整权重等连接处理完再停止这样用户体验不受影响。6. 高频面试题与真实故障排查能讲清楚才是真掌握技术文章如果只讲概念不讲排查总感觉缺了最实用的那一块。这一节我把面试里出现频率最高、以及现实中踩坑概率最大的问题整理出来做成一份可以直接参考的速查手册。6.1 面试高频问答Docker 与虚拟机、镜像与容器问Docker 容器和虚拟机有什么区别答虚拟机通过 Hypervisor 虚拟出完整的硬件在每个虚拟机里跑一个完整的操作系统所以隔离性强、启动慢、资源占用高。Docker 容器共享宿主机内核通过 Namespace 和 Cgroups 做资源隔离与限制本质上是宿主机上的普通进程所以启动快、资源占用低、单机可以运行成百上千个容器。但两者的隔离层级不同容器的隔离性不如虚拟机。问镜像和容器的关系是什么答镜像是一个只读的静态模板定义了容器运行所需的所有文件、依赖、配置和启动命令。容器的本质是一个运行中的进程基于镜像创建在镜像的只读层之上增加一层可写层。同一个镜像可以启动多个容器它们互相隔离、互不影响。这个关系很像“类与实例”或“程序与进程”的关系。问如何排查容器启动失败的问题答第一步docker logs 容器名看应用日志第二步docker inspect 容器名看详细信息检查挂载路径、环境变量、网络配置是否正确第三步检查宿主机端口是否被占用有冲突就用netstat -tlnp看端口占用情况。6.2 Nginx 常见错误 403、502、504 的排查思路这三个错误码是我在运维工作中处理次数最多的每个的产生机制都不一样。403 ForbiddenNginx 权限不足或目录配置有问题。排查思路第一看 error.log通常会明确写出“Permission denied”或“directory index is forbidden”。如果是静态文件目录检查目录的读权限和 Nginx worker 进程的用户是否有权限访问如果你访问的是/但目录下没有 index.html也会 403。502 Bad GatewayNginx 成功收到了请求但转发给后端时没有得到有效响应。主要原因通常是后端服务没启动、后端端口写错、后端进程崩溃。一个小技巧是先用docker ps确认后端容器状态再用curl直接访问后端的地址和端口如果能通说明 Nginx 到后端的链路有问题如果也不通说明后端自身挂了。504 Gateway TimeoutNginx 转发请求后后端在超时时间内没返回响应。这时调整两个关键参数proxy_connect_timeout控制与后端建立连接的超时时间proxy_read_timeout控制等待后端响应的超时时间。比如某个接口本身需要处理很久才返回默认的 60 秒不够就可以调大这两个值。6.3 容器化部署中最常踩的五个大坑整理一份踩坑清单每一条都是用真金白银换来的教训。第一个坑配置文件挂载后没有测试就删了旧容器新容器起不来才知道配置文件格式错误。正确做法是先执行docker exec nginx-prod nginx -t验证配置文件语法再 reload 或重启。验证通过后再重新加载配置这个习惯能救命。第二个坑前端项目挂载目录里文件权限不对导致 403。Nginx 容器默认以 nginx 用户运行UID 大致为 101如果你宿主机上的项目文件权限是 root 所有且没有其他用户的读权限Nginx 就没有办法读取。解决方式是把项目目录的所有者改为101:101或者调整目录权限为755或者--user指定以其他用户运行容器。第三个坑Docker 容器内的时间是 UTC 时区日志时间比北京时间差 8 小时。Nginx 容器默认的时区确实是这样导致排查日志时时间对不上。解决方式启动时挂载宿主机时区文件-v /etc/localtime:/etc/localtime:ro或者在 Dockerfile 里设置环境变量TZAsia/Shanghai推荐后者。第四个坑Dockerfile 构建时反复拉取海外依赖源导致构建极慢。经验做法是尽量使用语言官方提供的国内镜像源如 npm、pip、apt 的对应镜像、合理编排 Dockerfile 指令顺序、充分利用层缓存。这些操作配合分层结构理解构建速度可以快好几倍。第五个坑docker exec进去之后改了配置文件但忘了容器删除重建会丢失所有修改。前面提过进容器改文件只适合临时调试想持久化一套配置要么挂载、要么打镜像这个意识要建立起来。6.4 排查流程速查表我把排查流程整理成一张速查表实际遇到问题时对着走一遍比瞎试高效得多现象第一步第二步第三步容器启动失败docker logs 容器名看报错docker inspect查挂载与环境变量检查宿主机端口是否占用访问 Nginx 首页 403看/var/log/nginx/error.log检查宿主机目录权限和所有者确认目录下存在 index.html反向代理返回 502用docker ps确认后端容器状态在容器内 curl 后端地址检查proxy_pass地址和端口反向代理返回 504检查后端接口实际耗时调大proxy_read_timeout检查后端数据库或依赖服务静态资源加载失败看浏览器请求的 URL 和状态码检查 location 匹配顺序检查 alias 或 root 路径是否写对这张表不光是面试的提词器也是工作中排障的标准动作。真正可靠的排查流程永远是从日志开始、从链路入手、从配置落点而不是靠猜和碰。7. 最后分享一个我百试不爽的调试技巧这篇文章到这儿核心内容其实已经讲完。最后分享一个我用了很久的调试技巧算是个人经验里最值得拿出来说的部分。很多人排查 Nginx 问题习惯用浏览器访问来看结果但浏览器有很多缓存、代理、安全策略的干扰反而让你误判。我的习惯是先用 curl 带着完整的 Host 头和 URL 直接打 Nginx比如curl -v http://127.0.0.1:80/api/users -H Host: example.com这样我能直接在终端里看到请求的完整链路DNS 解析、TCP 连接、请求报文、响应状态码、响应头。然后再用同样的方式访问一遍后端服务就能判断问题到底出在 Nginx 这一层还是后端服务那一层。结合前面说的打开 Nginx 的 access log 和 error log把 curl 打出来的请求和 Nginx 日志里的记录对照一下大多数路由、转发、权限问题几分钟内就能定位。另一个习惯是每次修改完配置无论大改小改一定先执行nginx -t验证一遍语法再 reload。这个习惯我坚持了很多年它让我避免了一次次的在线事故。Docker 和 Nginx 这套组合的学习曲线其实不算陡真正拉开差距的是对细节的理解和对故障的敏感度。希望这篇文章能帮你把原理的线头理顺把操作的步骤踩实下次面试或排障的时候心里更有底。