阿里云ECS上使用Docker部署Nginx完整指南：从容器到HTTPS

帮朋友折腾阿里云服务器的时候最常见的需求就是Docker装好了接下来怎么把网站跑起来我在系列第一篇文章里讲了ECS上Docker环境的准备这篇直接往下走用Docker把Nginx完整部署起来从拉镜像、起容器到静态站点配置、反向代理、HTTPS证书落地一条线走通。目标读者很明确手里有一台阿里云服务器已经装好Docker想挂站又不想被零散教程绕晕的人。哪怕你现在连Nginx配置文件的语法都还不熟按这篇文章的步骤操作也能拿到一个能上线的服务。1. 动手之前为什么在阿里云上推荐用Docker部署Nginx1.1 比起apt装NginxDocker方案到底强在哪先回答一个很多人会纠结的问题既然服务器上有apt直接apt install nginx不就行了为什么非要用Docker我在阿里云上两种方式都跑过说点实际感受。直接装Nginx最大的问题是环境耦合——你升级系统、装别的软件、调整依赖库都有可能影响Nginx的运行。特别是在生产环境里你很难保证两台机器上的Nginx版本、编译参数、配置文件完全一致。Docker把Nginx连同它需要的运行环境封装在镜像里宿主机装了什么、缺了什么都不会干扰容器内的程序。再有就是升级和回滚。用apt升级Nginx要么改源要么手动下载出问题想退回旧版本比较麻烦。用Docker就简单得多新版本镜像拉下来换个tag重新起容器新版本有问题再把旧tag起回来。整个过程半分钟以内搞定损失最多是几秒钟的请求失败。还有一个很多新手忽略的点Docker部署Nginx后配置文件、网站文件、日志通过挂载目录暴露在宿主机上。这意味着你可以用本地的编辑器直接改配置不用SSH到服务器上跟vi较劲也不用操心系统里Nginx的目录结构。我个人的习惯是把所有站点文件放在/opt/nginx下统一管理哪个目录是配置、哪个目录是页面一目了然。1.2 部署前的四项检查安全组、端口、目录、域名动手前先做检查这能省掉后面大把排错时间。我在给服务器部署服务时习惯先过一遍下面这个清单检查项怎么查不检查的后果安全组规则阿里云控制台 - ECS实例详情 - 安全组外部访问不到80/443端口端口占用ss -lntp | grep :80容器启动时报端口冲突目录结构ls /opt/nginx配置文件和网站文件散落各处域名解析云解析DNS控制台查看A记录无法用域名访问站点安全组这个坑在阿里云上太典型了。很多人装完Docker、跑起容器本机curl localhost一切正常换到浏览器用公网IP访问就是白屏、连接超时。十有八九是安全组没放行。需要注意ECS实例的安全组在实例控制台里配置而轻量应用服务器那边叫“防火墙”入口位置不同别找错地方。放行规则很简单入方向添加TCP 80和443授权对象填0.0.0.0/0。如果后面还要折腾其他端口比如先跑一个8080测试服务也一并放行省得来回切控制台。另外提醒一句如果你打算绑定域名对外提供服务先把域名解析到服务器公网IP同时确认域名备案状态没问题。这一步不在技术配置范围内但经常是最后访问不了的真凶提前确认能避免白忙一场。2. 拉镜像、规划目录、启动容器把Nginx跑起来2.1 镜像选择与目录规划Nginx官方镜像有几个常用tag我推荐生产环境使用nginx:stable-alpine。Alpine基础镜像非常小整个镜像不到几十MB一个精简的Linux层加一个Nginx层干净利落。nginx:latest虽然更新更快但基于Debian体积大不少对于只跑Nginx的场景没必要。镜像确定后先规划目录。我的标准结构是/opt/nginx/ ├── conf.d/ 存放站点配置 ├── html/ 静态网站文件 ├── logs/ Nginx日志 └── ssl/ SSL证书文件执行命令建目录mkdir -p /opt/nginx/{conf.d,html,logs,ssl}然后放一个默认首页方便验证容器是否正常工作echo h1Hello Nginx/h1 /opt/nginx/html/index.html为什么把这些目录挂载出来因为Docker容器本身是“一次性”的。容器删了内部所有文件跟着消失。如果你把配置写在容器里哪天手滑执行了docker rm所有配置和网站文件就都没了。挂载目录相当于把容器的状态留在宿主机上删容器、重建容器数据依然还在。2.2 首次启动容器的完整命令与参数说明目录准备好后拉取镜像docker pull nginx:stable-alpine启动容器的命令我逐项拆开解释docker run -d --name nginx \ --restart unless-stopped \ -p 80:80 \ -p 443:443 \ -v /opt/nginx/conf.d:/etc/nginx/conf.d:ro \ -v /opt/nginx/html:/usr/share/nginx/html:ro \ -v /opt/nginx/logs:/var/log/nginx \ -v /opt/nginx/ssl:/etc/nginx/ssl:ro \ -v /etc/localtime:/etc/localtime:ro \ nginx:stable-alpine参数分别说明-d后台运行。--name nginx容器名字叫nginx后面执行docker exec nginx ...方便。--restart unless-stopped容器因异常退出自动重启服务器重启后也会跟着起来。这行在生产环境几乎是必须的。-p 80:80、-p 443:443把宿主机80和443端口映射到容器。-v /opt/nginx/conf.d:/etc/nginx/conf.d:ro把宿主机配置目录挂载到容器Nginx的conf.d目录只读。Nginx启动时会加载/etc/nginx/conf.d/*.conf里的所有配置。-v /opt/nginx/html:/usr/share/nginx/html:ro网站根目录挂载进去只读。-v /opt/nginx/logs:/var/log/nginx日志目录挂载出来。-v /opt/nginx/ssl:/etc/nginx/ssl:ro证书目录。现在还没有证书文件先挂上后面申请完直接放进去就能用。-v /etc/localtime:/etc/localtime:ro让容器使用宿主机时区否则容器内取到的是UTC时间Nginx访问日志的时间会差8个小时排查问题的时候容易产生奇怪的感觉。这里有一个很容易踩的细节挂载conf.d时必须保证目录里至少有一个站点配置文件否则目录虽然是空的但容器内原有的默认配置会被空目录“遮住”导致Nginx启动后没有可用的server块访问80端口会出现404或拒绝连接。后面章节我会专门说明。2.3 启动后必做的三步验证容器起来后不要急着配业务先做三项验证docker ps确认容器状态是Up没有反复重启。curl http://localhost在服务器本机测试能返回你写的首页内容就说明Nginx基本工作正常。docker logs nginx --tail 20查看容器日志确认没有报错。这里注意Nginx官方镜像默认把access_log和error_log挂到了标准输出所以docker logs能看到最近访问记录。本机通了之后再用浏览器访问公网IP。如果打不开回到第一章的安全组检查——80端口有没有放行。这一步我遇到过太多次本机curl通、浏览器不通折腾半天最后发现安全组忘配置。3. 静态站点配置location匹配规则与server块详解3.1 一个能用的静态站点配置长什么样容器跑起来了接下来就是Nginx的核心配置。很多人对Nginx的恐惧其实来自配置文件语法不熟不知道server、location、root之间的关系。我习惯把一个站点配置写在一个独立的文件中放在/opt/nginx/conf.d/下例如/opt/nginx/conf.d/blog.conf。server { listen 80; server_name blog.example.com; root /usr/share/nginx/html; index index.html index.htm; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/blog.access.log; error_log /var/log/nginx/blog.error.log; }server块代表一个虚拟主机listen 80监听80端口server_name决定哪个域名匹配到这个配置。root指定网站文件根目录注意这个路径是容器内部的路径不是宿主机路径。因为我们把/opt/nginx/html挂载到了/usr/share/nginx/html所以这里写容器内路径。location /是最基础的匹配代表所有未被其他location拦截的请求。try_files $uri $uri/ 404的意思很直白先尝试找URI对应的文件再尝试找这个目录都找不到就返回404。这行配置能避免访问一个不存在的路径时出现奇怪的错误页。写完配置后先做语法检查再重载docker exec nginx nginx -t docker exec nginx nginx -s reloadnginx -t是检查配置语法报错会指出具体文件和行号。确认没问题再用nginx -s reload重载。reload是平滑重载不会中断现有连接这是Nginx一个非常优雅的设计。3.2 location匹配机制的优先级location是Nginx配置里信息量最大的指令掌握了它的匹配规则写任何反代、静态资源都心中有数。它的匹配类型和优先级如下表匹配类型写法示例行为特点精确匹配location /api路径完全等于/api命中立即使用前缀匹配强制停止location ^~ /static/命中立即使用不再检查正表达式正则匹配区分大小写location ~ \.php$按配置文件顺序第一个命中的生效正则匹配不区分大小写location ~* \.jpg$同上普通前缀匹配location /static/记录最长匹配之后检查正则正则没命中才用它通用匹配location /兜底几乎能匹配所有请求理解这个规则有个简单的心法先找前缀最长匹配再按顺序跑正则正则赢了用正则正则没赢就用之前记录的最长前缀。和^~属于“赢家通吃”型命中就直接拍板。举个例子网站上有一批图片放在/static/images/下我一般这么配location ^~ /static/ { alias /data/static/; expires 7d; }^~保证了这个匹配优先于任何正则同时给静态资源加上expires 7d缓存头部浏览器访问过一次后七天内不再重复请求。3.3 root与alias最常见的路径困惑很多新手在root和alias之间选错导致静态文件一直404。我讲个最直观的差异。root会把你配置的路径和location匹配的URI拼在一起。比如location /img/ { root /usr/share/nginx/html; }请求/img/a.png时Nginx查找的文件路径是/usr/share/nginx/html/img/a.png。也就是root拼接完整URI包括img这段。而alias是替换关系location /img/ { alias /data/images/; }请求/img/a.png时Nginx会用/data/images/替换掉/img/实际查找/data/images/a.png。记住口诀root是“拼上去”alias是“换掉前缀”。实际项目里静态文件如果不在网站根目录下建议用alias逻辑更清晰。3.4 改完配置如何生效配置修改后严格遵循一个习惯先nginx -t再nginx -s reload两条命令连成一条执行也OKdocker exec nginx nginx -t docker exec nginx nginx -s reload这个习惯非常重要。我见过有人在生产环境改了配置直接reload结果配置有语法错误Nginx直接把所有worker进程全部退掉服务整个挂掉。先做语法检查再过五秒reload成本极低收益极高。另外reload和restart不一样reload是让Nginx重新读取配置不会中断正在处理的请求对线上影响为零。4. 反向代理实战一个域名挂多个后端服务4.1 反代场景与配置骨架静态站点只是Nginx的基本功真正凸显它价值的是反向代理。简单来说反代就是把外部的请求接进来转发到服务器上另一个端口跑着的服务再把响应返回给客户端。最常见的场景你在机器上跑了一个博客、一个管理系统、一个接口服务它们分别监听3000、8080、5000端口。不想让用户记端口号也不想在每个应用里配置TLS更不想让服务直接暴露公网。这时候Nginx做主入口根据域名或路径把流量分发到各自端口。配置骨架如下server { listen 80; server_name blog.example.com; location / { proxy_pass http://127.0.0.1:3000; 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_pass是反代的核心指令。请求到达Nginx后Nginx作为客户端把请求转发给127.0.0.1:3000拿到结果后再返回给浏览器。对浏览器来说它只看到Nginx在服务并不知道背后还有一层应用。4.2 proxy_pass末尾的斜杠细节决定成败proxy_pass这行配置里有一个非常容易踩的细节URL末尾到底带不带斜杠。假设location是/api/后端接口服务挂在8080端口location /api/ { proxy_pass http://127.0.0.1:8080; }此时请求/api/user转发给后端的是完整路径/api/user。location里面的/api/原封不动地带过去了。如果写成这样location /api/ { proxy_pass http://127.0.0.1:8080/; }请求/api/user转发给后端的是/user。/api/被替换成了/。这两者的语义差别很大。后端如果只认/user路由而你用了不带斜杠的写法它收到的/api/user就找不到对应接口返回404。反过来也一样。我建议写反代前先拉一下后端接口的根路径设计确认要不要带location前缀再决定斜杠。这是一个看着不起眼、坑起人来毫不含糊的细节。4.3 容器间通信用容器名别写IP如果你被反代的服务也是Docker容器注意不要用IP互相访问。容器的IP在每次重建后都会变化今天配置里写的172.17.0.3明天容器一重建可能变成172.17.0.5代理立刻失效。正确做法是让容器在同一个自定义网络里通过容器名互相访问。先创建网络docker network create webnet把Nginx和后端容器都加入网络docker network connect webnet nginx docker network connect webnet backend然后在Nginx配置里直接写容器名location / { proxy_pass http://backend:8080; }Docker自带的DNS解析会把backend解析到对应容器的地址IP怎么变都不影响。这是我在Docker部署里最推荐的做法比查docker inspect拿IP、写死IP要省心得多。4.4 请求头穿透把真实客户端IP传给后端反代有一个隐性问题后端服务看到的请求来源变成了Nginx的IP而不是真实用户的IP。日志里全是127.0.0.1无法做来源统计和访问控制。解决方法是把原始信息通过请求头传给后端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;$host是浏览器请求的域名$remote_addr是真实客户端IP$proxy_add_x_forwarded_for会把已有转发链追加在后面$scheme标记原始请求是HTTP还是HTTPS。后端服务器读取这些请求头就能拿到准确的客户端IP和访问协议。如果你的后端应用还要判断用户IP做限流或封禁这几行绝对不能省。5. HTTPS配置让443端口正式接管站点5.1 证书从哪来三种来源对比现在没有纯HTTP站点还能留住用户的。浏览器会直接标“不安全”小程序、App等在调用接口时也强制要求HTTPS。证书来源我实际用过的有三种证书来源有效时长适用场景阿里云免费数字证书3个月或1年视政策国内单域名站点申请方便Lets Encrypt通过certbot90天需要自动化续期习惯命令行自签证书无固定期限仅内网测试浏览器会告警个人站点我一般用阿里云免费证书控制台提交申请验证域名归属后就能下载里面有nginx用的.pem证书文件和.key私钥文件。如果是多域名或子域名特别多考虑Lets Encrypt配合certbot可以写脚本自动续期省去手动反复操作的麻烦。5.2 把证书文件放进容器挂载与路径拿到证书文件后放到宿主机/opt/nginx/ssl/目录下。注意Nginx运行在容器里它只能读取容器内的路径。因为我们在启动容器时已经挂载了/opt/nginx/ssl到/etc/nginx/ssl所以Nginx配置里写的是容器路径ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key;docker run命令里已经预留了ssl挂载这里只需要把文件放进去再reload配置即可生效。如果当初启动容器时忘了挂载ssl目录就得重建容器加上挂载操作起来麻烦一些这也是我推荐一开始就把目录规划完整的原因。5.3 完整的443 server配置与HTTP跳转一份完整的HTTPS server配置加上HTTP自动跳转HTTPS参考如下server { listen 80; server_name blog.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name blog.example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; root /usr/share/nginx/html; index index.html index.htm; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/blog.ssl.access.log; }return 301 https://$host$request_uri是HTTP跳转HTTPS的标准写法把80端口所有请求直接导向443端口。ssl_protocols建议至少支持TLS 1.2老旧的TLS 1.0和1.1协议漏洞多该退役就让它退役。配置写好老规矩执行语法检查和重载docker exec nginx nginx -t docker exec nginx nginx -s reload然后浏览器用https://域名访问地址栏出现小锁图标就说明配置成功。5.4 证书常见报错与域名校验HTTPS配置最容易出错的点我在实际操作中总结出两个高频问题。第一个nginx -t报cannot load certificate或类似无法读取证书文件的错误。原因通常是证书文件没放对地方Nginx在容器内看不到。排查方法很简单docker exec nginx ls /etc/nginx/ssl/如果看不到证书文件说明宿主机/opt/nginx/ssl目录下也没有或者文件名写错了。解决方法是把证书文件复制到宿主机对应目录确保文件名与配置完全一致。第二个浏览器访问报ERR_CERT_COMMON_NAME_INVALID。这种问题基本是证书的域名和访问的域名对不上。比如你申请的是example.com的证书在浏览器里却用blog.example.com访问或者干脆用IP访问域名证书浏览器就会因为证书CN/SAN不匹配而拦截连接。解决思路也很简单要么访问对应的域名要么重新申请匹配当前域名的证书。备案过的域名正常使用是没有这个问题的。6. 部署过程中最常见的五个坑6.1 安全组忘放行本机通、外网不通这个坑在第一章提过但在整个部署过程中出现的频率太高必须再强调一遍。现象是服务器上curl localhost返回正常用手机或本地电脑访问公网IP就是超时。判断思路很清晰既然本机能通Nginx服务肯定正常问题必然出在从服务器到外部网络之间的某个环节。对阿里云来说第一个要查的就是安全组规则。ECS去实例详情页看安全组轻量应用服务器去防火墙页面看规则入方向放行80和443授权对象0.0.0.0/0问题基本解决。6.2 conf.d空目录遮住默认配置启动容器后如果访问80端口返回403、404或者直接拒绝连接很可能是conf.d挂载导致的问题。比如执行了docker run -v /opt/nginx/conf.d:/etc/nginx/conf.d:ro但宿主机/opt/nginx/conf.d目录是空的。Docker挂载空目录后容器内原有目录里的文件就被遮蔽了Nginx找不到任何站点配置自然无法正常响应。排查方式docker exec nginx ls /etc/nginx/conf.d/看到为空问题就找到了。解决方法是先把一个默认站点配置文件放进/opt/nginx/conf.d/再重启容器。这也是我在第二章就提示先建目录并放配置文件的原因。6.3 改了配置页面没变确认挂载加reload配置改了半天网站一点变化没有这种挫败感我太懂了。排查顺序如下先确认挂载路径是宿主机的哪个目录。docker inspect nginx可以查看容器的挂载情况确认你编辑的文件确实映射到了容器内的Nginx配置目录。很多人会用vi直接改容器里的配置文件但没挂载的话容器一重建就全丢了。再确认是否执行了reload。改完conf.d里的文件后Nginx不会自动感知需要docker exec nginx nginx -s reload。如果config语法有问题reload也不会生效所以要养成nginx -t nginx -s reload连用的习惯。最后确认浏览器缓存。静态资源被浏览器缓存是常事按CtrlF5强制刷新或开隐私模式访问。6.4 容器删了配置全丢卷挂载是唯一的保险Docker容器删除后内部一切文件随之消失。之前没有做任何挂载的话配置、页面、证书都没了。我建议做任何修改前先检查docker inspect nginx --format {{json .Mounts}}如果Mounts列表里只有基础数据卷没有站点挂载那当前容器是一件“脏衣服”删了就没了。正确做法是重建容器并添加所有需要的挂载。不要试图往一个没有挂载的容器里长期保存配置容器随时可能因为故障或误操作被删除。在容器生命周期管理上我始终遵守一条原则容器可以随时删宿主机上的数据才是根本。6.5 日志无限膨胀处理好Nginx日志轮转跑了一段时间后宿主机磁盘突然告警查下来往往是Nginx日志把空间吃满了。原因是我们把日志挂载到了宿主机/opt/nginx/logs但没有任何轮转策略access.log和error.log会无限增长。处理办法分两步。第一步用系统crontab做一个简单的日志切割0 0 * * * mv /opt/nginx/logs/*.log /opt/nginx/logs/$(date \%Y\%m\%d).log 2/dev/null; docker exec nginx nginx -s reopen第二步nginx -s reopen这句很关键。Nginx进程仍然持有旧日志文件的文件句柄直接切割完文件后磁盘空间不会释放必须让Nginx重新打开日志文件。reopen就是干这个的。生产环境更优雅的方案是配置logrotate但对大多数单机站点上面的crontab思路已经够用。7. 生产环境常用优化自动重启、资源限制、Compose管理7.1 容器跟着服务器开机自启部署完服务只是开始稳定性才是关键。服务器重启后Nginx容器能不能自动恢复取决于启动参数里有没有--restart unless-stopped。如果当时忘了加不用重建容器一条命令补上docker update --restart unless-stopped nginx这个策略的含义是容器异常退出时自动重启除非你手动停止它。注意always和unless-stopped的区别always即使手动停止服务器重启后也会自动拉起有时候反而会打扰你排查问题。我习惯用unless-stopped。7.2 用资源限制防止Nginx吃干机器阿里云小规格的ECS内存可能只有2G甚至1G。Nginx默认配置在极端流量下会占用不少内存加上同一台机器上还可能跑着其他容器出现过内存耗尽导致整机卡死的尴尬。给容器加上资源限制docker update --memory512m --cpus1.0 nginx限制Nginx最多使用512MB内存和1个CPU核心。如果跑静态站点这个上限大概率够用遇到突发流量Nginx也不会拖垮整台服务器。这个限制对单机多服务的场景特别有意义谁都别占谁的资源。7.3 用docker compose固化整套配置当挂载项多起来手敲docker run命令就显得笨重且容易出错。我最终都会把部署定义写成docker compose文件放到/opt/nginx/docker-compose.ymlservices: nginx: image: nginx:stable-alpine container_name: nginx restart: unless-stopped ports: - 80:80 - 443:443 volumes: - /opt/nginx/conf.d:/etc/nginx/conf.d:ro - /opt/nginx/html:/usr/share/nginx/html:ro - /opt/nginx/logs:/var/log/nginx - /opt/nginx/ssl:/etc/nginx/ssl:ro之后启动就一句话docker compose up -d升级镜像、重建容器、老配置迁移到新机器把整个目录复制过去执行docker compose up -d就行。配置文件即代码出问题按定义重建比手动敲命令可靠得多。7.4 几个值得改的nginx.conf参数容器内Nginx的/etc/nginx/nginx.conf是镜像自带的默认配置生产上我一般会调整几个参数。可以直接修改宿主机和容器内的文件或者在配置里覆盖worker_processes auto; server_tokens off; gzip on; gzip_min_length 1k; gzip_types text/plain text/css application/javascript application/json;worker_processes auto让Nginx按服务器CPU核心数自动分配worker进程。server_tokens off隐藏Nginx版本号减少被针对性探测的风险。gzip压缩文本类资源对静态页面加载速度提升非常直观。这些参数改动后同样需要nginx -t nginx -s reload。如果对容器内nginx.conf修改比较谨慎也可以把这些优化放进站点配置的http块里不过更推荐直接在镜像挂载一份自定义nginx.conf出来。这个属于进阶玩法等你熟悉了当前的配置结构再折腾也不迟。最后再分享一个我个人的操作习惯每次改完Nginx配置无论是新增站点还是调整代理规则都严格按nginx -t nginx -s reload走并且立刻用浏览器无痕窗口验证一次。这个习惯帮我避免了很多线上事故。Nginx部署本身不难难的是把细节保持住——安全组放行、目录规划、卷挂载、reload验证每一步都老老实实做完Nginx在阿里云上跑个几年都不带出问题的。这篇文章到这就结束了下一篇准备聊聊用Docker部署后端服务以及和Nginx组成一套完整的站点体系到时候见。