这篇文章主要讲解了“Nginx热升级的流程”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Nginx热升级的流程”吧!
第一步就是把旧的 Nginx 替换为新的 Nginx 文件(binary文件),之所以说只替换 binary 文件是因为大部分场景下,我们新编译的 nginx 文件所指定的相应的配置选项,比如说配置文件的目录在哪里?log 的所在目录在哪里?必须保持和老的 Nginx 是一致的,否则的话没有办法复用 nginx.conf 文件,如果我们仅仅替换 binary 文件,请注意要备份,另外在新版本的 Linux 中,会要求在覆盖一个正在使用的文件时需要用 cp -f
才能够替换。
接下来我们像现在的老 master 进程发送 USR2 信号,这时候我们注意到,我们没有办法通过 Nginx 命令行直接用 nginx -s
一个信号来处理,因为 Nginx 到目前为止,还没有支持这样的信号。
发送 USR2 信号以后,现有的 master 进程会做以下几件事情:修改 pid 文件名,加后缀 .oldbin,这是为什么呢?这是在为新的 master 进程让路,虽然 master、worker 进程都可以接受信号,但是为了管理方便,通常不对 worker 进程直接发送信号,所以我们依赖于 master 进程,他必须把他的 pid 保存下来,为了新的 master 使用 pid.bin 这个文件名,所以把老的 pid 文件改为 pid.oldbin。
接下来使用新的二进制文件启动新的 master 进程,所以到此为止,会出现两个 master 进程和老的 worker 进程,然后新的 master 进程会自动启动新的 worker 进程,所以这时候我们会发现两个 master 进程和多个 worker 进程的情况。
接下来我们要向老的 master 进程发送 QUIT 信号,怎么样找到老的 master 进程呢?我们可以根据 ps
看到 master 进程的进程号,或者通过 .oldbin 文件找到老的 master 进程的进程号,向这个进程号发送 QUIT 信号,那么老的 master 进程会优雅的关闭老 worker 进程,这样我们的热升级就结束。
但是老 master 进程是一直保存下来的,这是为了方便我们进行回滚,也就是发现新的 Nginx 程序有问题了,这个时候因为老的 master 进程还在,可以向老的 master 进程发送 HUP 信号,相当于执行了一次 reload,会启动新的 worker 进程,然后再向新 master 进程发送 QUIT 信号,也就是要求新的 worker 进程优雅退出,就实现了回滚。
接下来看下不停机更新 Nginx 二进制文件的具体流程图:
一开始老的 master 进程启动了四个绿色的 worker 进程,当我们更新了Nginx 的 binary 以后,向老 master 进程发送了 SIGUSR2 信号,这个时候老 master 进程会把自己的 pid 文件改名,这个时候可以认为是黄色这种的进程。
那么启动了新的 master 进程是怎么样启动的呢?他启动了新的子进程,也就是说新的 master 进程是老 master 进程的子进程,但这个子进程是使用了新的 binary 载入来启动的,在中间这个流程新老 Nginx 并存,但是老的 master 开始关闭监听端口,所有的黄色老的 worker 进程开始优雅地退出,在完成以后就会出现只有新的 master 进程存在的场景。
当退出老 master 进程以后不能进行回滚,如果想回滚,就需要再走一次热升级流程,用备份好的老 Nginx 文件作为新的热升级文件(因此建议备份旧的 Nginx 文件)。
在一个父进程退出,而它的一个或多个子进程还在运行时,那么这些子进程将成为孤儿进程。孤儿进程将被 init 进程(进程号为1)所收养,并由 init 进程对它们完成状态收集工作。所以老 master 进程退出后,新的 master 进程并不会退出。
感谢各位的阅读,以上就是“Nginx热升级的流程”的内容了,经过本文的学习后,相信大家对Nginx热升级的流程这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。