Nginx在线服务状态下平滑升级或新增模块的详细操作记录

今天，产品那边发来需求，说有个 APP 的 IOS 版本下载包需要新增 https 协议，在景安购买了免费的 SSL 证书。当我往 nginx 上新增 ssl 时，发现服务器上的 nginx 居然没编译 SSL 模块！

看了下旧版本 nginx 的 configure 选项：

可能是出于最小化安装的考虑，就只有一个 prefix 参数，而版本也挺低的，干脆就升级一下好了！由于服务器处于在线服务状态，为了避免升级带来的不良影响，我决定给 nginx 来个平滑升级，结果发现还真是如丝般顺滑。。。

下面记录一下平滑升级和新增模块的过程。

一、半自动平滑升级

所谓半自动，其实就是在最后迁移的时候使用源码自带的升级命令：make upgrade 来自动完成。

①、按需编译新版本的 nginx

根据需求，常规编译新版本 nginx，不过只要执行到 make 就打住，不要 make install！

②、重命名 nginx 旧版本二进制文件，即 sbin 目录下的 nginx（期间 nginx 并不会停止服务！）：

③、然后拷贝一份新编译的二进制文件：

④、在源码目录执行 make upgrade 开始升级：

完成后，最后确认一下 nginx -V ：

正常了，平滑升级成功！

二、纯手动平滑升级

纯手动模式，指的是在最后做迁移的时候，全部使用手动命令来搞定，避免编译可能存在不一致的参数啥的。

实际上，在 make 之后，我们可以查看 nginx 源码目录下的 Makefile 内容如下：

所以，说白了纯手动就是执行 upgrade 标签下的命令行而已，实际上只要确认 Makefile 下的命令路径都是正确的，用命令自动迁移是没有任何问题的。

总是有人会不放心的，喜欢手动一步一步的搞定，我也来整理下纯手动步骤：

①~③和半自动一样，按常规步骤先编译 nginx，不过只执行到 make 就打住，然后将旧的 sbin 下的 nginx 文件移走，再将编译得到的 objs 目录下的 nginx 文件放到原来的 sbin 目录。

④、测试新版本的 nginx 是否正常：

⑤、给旧 nginx 发送平滑迁移信号（若不清楚 pid 路径就用可用命令(2)）：

Ps：后面其实就是旧 nginx 的 pid，所以先用 ps aux 找到正在运行的 nginx 主进程 pid,再执行 kill -USR2 PID 值亦可。

⑥、等待旧版本 Nginx 的 pid 变为 oldbin（执行如下命令查看是否生成）

⑦、  从容关闭旧版本的 Nginx 进程

此时，旧的工作进程就都会慢慢随着任务执行完毕而退出，新版的 Nginx 的工作进程会逐渐取代旧版工作进程。

⑧、此时，不重载配置启动旧工作进程（个人感觉是为了将任务完全切换到新的 nginx 上）

⑨、结束工作进程，完成此次升级操作：

⑩、最后，验证 nginx 是否升级成功：

特意测试了下纯手动的做法，下面是我的操作记录，仅供参考：

为了验证平滑升级确实不影响在线业务，我特意在升级的时候，利用 ab 命令一直在发送请求：

直到升级完成，使用 ctrl +C 终止并查看 ab 结果，可以发现几十万次的请求全部成功，没有失败！证明平滑升级的可行性！可惜忘记了截图，感兴趣的童鞋可以自行测试下！

好了，关于 nginx 的平滑升级和在线新增模块的操作记录就到这里结束了，希望对你有所帮助。