Nginx热部署的实现

目录
  • 信号量
  • Nginx热部署

跟着上面这篇博客进行操作即可。关闭防火墙，让本地可以通过浏览器访问Nginx服务。

[root@localhost ~]# systemctl stop firewalld

信号量

查看信号量：

[root@localhost ~]# kill -l
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
63) SIGRTMAX-1	64) SIGRTMAX

有64种信号量，以下是几种常用的信号量：

  • SIGINT 、SIGTERM：快速关闭。
  • SIGQUIT：从容关闭（优雅的关闭进程，即等请求结束后再关闭）。
  • SIGHUP：平滑重启，重新加载配置文件 （平滑重启，修改配置文件之后不用重启服务器）。
  • SIGUSR1 ：重新读取日志文件，在切割日志文件时用途较大。
  • SIGUSR2：平滑升级可执行程序 ，nginx升级时候用。
  • SIGWINCH ：从容关闭工作进程。

Nginx热部署

Nginx是一个多进程的高性能反向代理服务器，包含一个master进程和多个worker进程（worker进程的数量可以通过nginx.conf配置文件中的worker_processes参数进行设置，默认1个），这样可以充分利用多核处理器。

默认1个worker进程。

并且master进程和worker进程是父子进程关系。

Nginx工作模式为多进程，Nginx在启动之后会有一个master进程和多个worker进程（默认1个），多个worker子进程将监听master父进程监听的端口（参考父子进程的关系），并行处理请求。master父进程主要用来管理worker子进程（管理真正提供服务的worker进程，向worker进程发送信号，监控worker进程的运行状态，当worker进程异常退出后，会重新启动新的worker进程），读取并验证配置信息，master进程不会对用户请求提供服务，而用户请求是由worker进程进行处理。

Nginx是通过信号量来控制，比如停止和重启Nginx。信号量是进程间通信的一种机制，master主进程控制多个worker子进程，也是通过信号量。

现在来演示Nginx是怎么实现热部署的，博主通过修改Nginx的配置文件来模拟Nginx的升级（先copy一份副本）。

[root@localhost ~]# cd /usr/local/nginx/conf/
[root@localhost conf]# ll
总用量 68
-rw-r--r--. 1 root root 1077 12月 20 20:24 fastcgi.conf
-rw-r--r--. 1 root root 1077 12月 20 20:24 fastcgi.conf.default
-rw-r--r--. 1 root root 1007 12月 20 20:24 fastcgi_params
-rw-r--r--. 1 root root 1007 12月 20 20:24 fastcgi_params.default
-rw-r--r--. 1 root root 2837 12月 20 20:24 koi-utf
-rw-r--r--. 1 root root 2223 12月 20 20:24 koi-win
-rw-r--r--. 1 root root 5231 12月 20 20:24 mime.types
-rw-r--r--. 1 root root 5231 12月 20 20:24 mime.types.default
-rw-r--r--. 1 root root 2656 12月 20 21:26 nginx.conf
-rw-r--r--. 1 root root 2656 12月 20 20:24 nginx.conf.default
-rw-r--r--. 1 root root  636 12月 20 20:24 scgi_params
-rw-r--r--. 1 root root  636 12月 20 20:24 scgi_params.default
-rw-r--r--. 1 root root  664 12月 20 20:24 uwsgi_params
-rw-r--r--. 1 root root  664 12月 20 20:24 uwsgi_params.default
-rw-r--r--. 1 root root 3610 12月 20 20:24 win-utf
[root@localhost conf]# cp nginx.conf nginx_old.conf
[root@localhost conf]# vim nginx.conf

由于还没有给Nginx进行热部署，现在访问http://192.168.1.199/还是原来的Nginx页面。

查看Nginx的进程：

[root@localhost conf]# ps -ef | grep nginx
root     14964     1  0 22:25 ?        00:00:00 nginx: master process ./nginx
nobody   14965 14964  0 22:25 ?        00:00:00 nginx: worker process
root     15016  1521  0 23:07 pts/0    00:00:00 grep --color=auto nginx

给master进程发送SIGUSR2信号，让Nginx平滑升级可执行程序。可以看到Nginx重新启动了一组master进程和worker进程，而新master进程是旧master进程的子进程（通过父子进程的继承关系，新master进程可以很方便地继承旧master进程的相关资源）。

[root@localhost conf]# kill -s SIGUSR2 14964
[root@localhost conf]# ps -ef | grep nginx
root     14964     1  0 22:25 ?        00:00:00 nginx: master process ./nginx
nobody   14965 14964  0 22:25 ?        00:00:00 nginx: worker process
root     15019 14964  0 23:18 ?        00:00:00 nginx: master process ./nginx
nobody   15020 15019  0 23:18 ?        00:00:00 nginx: worker process
root     15022  1521  0 23:19 pts/0    00:00:00 grep --color=auto nginx

并且Nginx在日志目录中存储了新旧pid文件（保存了新旧master进程的ID）。

[root@localhost conf]# ll ../logs
总用量 16
-rw-r--r--. 1 root root 2729 12月 20 23:20 access.log
-rw-r--r--. 1 root root  708 12月 20 23:18 error.log
-rw-r--r--. 1 root root    6 12月 20 23:18 nginx.pid
-rw-r--r--. 1 root root    6 12月 20 22:25 nginx.pid.oldbin
[root@localhost conf]# cat ../logs/nginx.pid
15019
[root@localhost conf]# cat ../logs/nginx.pid.oldbin
14964

给旧master进程发送SIGWINCH信号，让旧master进程关闭旧worker进程。

[root@localhost conf]# kill -s SIGWINCH 14964
[root@localhost conf]# ps -ef | grep nginx
root     14964     1  0 22:25 ?        00:00:00 nginx: master process ./nginx
root     15019 14964  0 23:18 ?        00:00:00 nginx: master process ./nginx
nobody   15020 15019  0 23:18 ?        00:00:00 nginx: worker process
root     15030  1521  0 23:27 pts/0    00:00:00 grep --color=auto nginx

现在访问http://192.168.1.199/，会响应404。

而访问http://192.168.1.199/nacos，会访问到Nacos服务。

如果升级版本没有问题，就可以给旧master进程发送SIGQUIT信号，让旧master进程关闭，这样就只剩下新master进程和新worker进程，实现了Nginx的热部署。

[root@localhost conf]# kill -s SIGQUIT 14964
[root@localhost conf]# ps -ef | grep nginx
root     15019     1  0 23:18 ?        00:00:00 nginx: master process ./nginx
nobody   15020 15019  0 23:18 ?        00:00:00 nginx: worker process
root     15034  1521  0 23:31 pts/0    00:00:00 grep --color=auto nginx

如果升级版本有问题，需要回滚到之前的版本，就可以给旧master进程发送SIGHUP信号，因为博主重新进行了测试，所以进程号都变了，但很显然旧master进程重新创建了旧worker进程，并且进行版本升级的master和worker进程没有被关闭。

[root@localhost conf]# kill -s SIGHUP 15084
[root@localhost conf]# ps -ef | grep nginx
root     15084     1  0 12月20 ?      00:00:00 nginx: master process ./nginx
root     15106 15084  0 12月20 ?      00:00:00 nginx: master process ./nginx
nobody   15107 15106  0 12月20 ?      00:00:00 nginx: worker process
nobody   15131 15084  0 00:02 ?        00:00:00 nginx: worker process
root     15141  1521  0 00:09 pts/0    00:00:00 grep --color=auto nginx

给新master进程发送SIGQUIT信号，让新master进程关闭，这样就只剩下旧master进程和新创建的旧worker进程，实现了回滚。

[root@localhost conf]# kill -s SIGQUIT 15106
[root@localhost conf]# ps -ef | grep nginx
root     15084     1  0 12月20 ?      00:00:00 nginx: master process ./nginx
nobody   15131 15084  0 00:02 ?        00:00:00 nginx: worker process
root     15159  1521  0 00:25 pts/0    00:00:00 grep --color=auto nginx

回滚成功。

还需要对版本回滚（即博主这里的配置文件回滚，不然下次重启就会出问题）。

[root@localhost conf]# cp -f nginx_old.conf nginx.conf
cp：是否覆盖"nginx.conf"？ y

为什么给旧master进程发送SIGHUP信号，旧master进程重新创建的worker进程没有重新读取配置文件？下面是官方的说明：

Send the HUP signal to the old master process. The old master process will start new worker processes without re-reading the configuration. After that, all new processes can be shut down gracefully, by sending the QUIT signal to the new master process.

向旧master进程发送SIGHUP信号。旧master进程将启动新worker进程，而无需重新读取配置。之后，通过向新master进程发送SIGQUIT信号，所有新进程都可以正常关闭。

如果不存在新进程的情况下（只有一组master、worker进程），修改配置文件，再向master进程发送SIGHUP信号，看是否会重新加载配置文件。

[root@localhost conf]# kill -s SIGHUP 15084

很显然配置文件被重新加载了，由于博主还没有看源码，只能猜测Nginx的实现（如果说错了，请大家评论补充），Nginx应该是根据当前是否在进行热部署（存在新master进程），来决定SIGHUP信号是否需要重新加载配置文件。

到此这篇关于Nginx热部署的实现的文章就介绍到这了,更多相关Nginx热部署内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • Nginx部署vue项目和配置代理的问题解析

    Nginx部署vue项目和配置代理的问题解析

    1.nginx安装和启动 # 安装nginx sudo apt-get install nginx # 启动 sudo service nginx start 验证安装 # 安装完成后使用nginx -v检查,如果输出nginx的版本信息表明安装成功 nginx -v # 如果输出类似于这样的版本号等,证明安装完成 nginx version: nginx/1.14.0 (Ubuntu) 2.修改nginx配置文件,部署项目 查看nginx的配置,linux系统下的配置文件通常会存放在/etc目

  • nginx部署多前端项目的几种方法

    nginx部署多前端项目的几种方法

    个人总结了3种方法来实现在一台服务器上使用nginx部署多个前端项目的方法. 基于域名配置 基于端口配置 基于location配置 在正式开始之前,我们先来看一下nginx安装的默认配置文件: /etc/nginx/nginx.conf 文件 可以看到图中的:include /usr/nginx/modules/*.conf,这句话的作用就是可以在nginx启动加载所有 /usr/nginx/modules/ 目录下的 *.conf 文件. 所以,平时我们为了方便管理,可以在此目录下面定义自己的

  • shell脚本多实例部署nginx的详细教程

    1. 创建一个目录,用来存放脚本和安装包 [root@localhost nginx]# tree . ├── install.sh └── packages └── nginx-1.20.1.tar.gz 1 directory, 2 files [root@localhost nginx]# 2. 下载好对应的安装包 [root@localhost packages]# wget https://nginx.org/download/nginx-1.20.1.tar.gz [root@loc

  • tomcat+nginx实现多应用部署的示例代码

    tomcat+nginx实现多应用部署的示例代码

    目录 多应用部署 1-tomcat配置   1.1-项目配置  1.2-服务配置 2-Nginx配置 3-完成部署 多应用部署 1-tomcat配置   1.1-项目配置  首先进入到 tomcat 的目录下, 将其中的 webapps 文件夹进行一份拷贝, 用于第二个应用的部署. cp webapps webapps1  此时就可以将需要部署的第二个项目同部署平常项目时一样, 将数据包上传到 webapps1 文件下面.  1.2-服务配置  进入到 tomcat 的服务配置文件下面, 打开

  • docker部署nginx并且挂载文件夹和文件操作

    这段时间在研究docker,在部署nginx时遇到了坑,最主要的问题是在挂载文件和文件夹的时候不知道怎么挂载,经过反复实验以及查看网上的教程,先总结如下: 1首先pull下载nginx镜像包 docker pull nginx 2(关键)查看nginx镜像里面配置文件.日志等文件的具体位置,只有找到镜像配置文件的路径,后面挂载文件和文件夹才能覆盖这些路径 以终端的方式打开镜像容器 [root@docker2 nginx]# docker run -i -t nginx /bin/bash roo

  • Nginx下SSL证书安装部署步骤介绍

    Nginx下SSL证书安装部署步骤介绍

    目录 问题描述: 安装步骤 1.准备工作 2.远程连接服务器 3.拷贝证书和私钥文件 4.编辑 Nginx 根目录下的 conf/nginx.conf 文件 5.在 Nginx 根目录下,通过执行以下命令验证配置文件问题 6.重启 Nginx,访问网站 问题描述: 小编遇到https协议过期了,于是重新申请,在Nginx服务器部署SSL证书 安装步骤 1.准备工作 在 SSL 证书管理控制台 中下载并解压缩 cloud.tencent.com 证书文件包到本地目录. 解压缩后,可获得相关类型的证

  • Nginx热部署的实现

    Nginx热部署的实现

    目录 信号量 Nginx热部署 跟着上面这篇博客进行操作即可.关闭防火墙,让本地可以通过浏览器访问Nginx服务. [root@localhost ~]# systemctl stop firewalld 信号量 查看信号量: [root@localhost ~]# kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11

  • 详解tomcat热部署和热加载的方法

    详解tomcat热部署和热加载的方法 我在项目开发过程中,经常要改动Java/JSP 文件,但是又不想从新启动服务器(服务器从新启动花时间),想直接获得(debug)结果.有两种方式热部署 和热加载: 1.热加载:在server.xml -> context 属性中 设置 reloadable="true" <Context docBase="xxx" path="/xxx" reloadable="true"/&

  • Tomcat 热部署的实现原理详解

    Tomcat热部署机制 对于Java应用程序来说,热部署就是在运行时更新Java类文件.在基于Java的应用服务器实现热部署的过程中,类装入器扮演着重要的角色.大多数基于Java的应用服务器,包括EJB服务器和Servlet容器,都支持热部署.类装入器不能重新装入一个已经装入的类,但只要使用一个新的类装入器实例,就可以将类再次装入一个正在运行的应用程序. 我们知道,现在大多数的web服务器都支持热部署,而对于热部署的实现机制,网上讲的却不够完善,下面我们就Tomcat的热部署实现机制,讲解一下它

  • Tomcat实现热部署

    热部署概念 热部署是指在你对JSP或JAVA类进行了修改在不重启WEB服务器前提下能让修改生效,配置文件的修改除外 热部署好处 每次打增量包的时候就不用重新启动tomcat了 实现方式 在tomcat\conf\server.xml中的<host></host>内部添加<context/>标签 <!-- 实现tomcat热部署和自定义ContextPath--> <Context docBase="myPrj " path=&quo

  • SpringBoot配置devtools实现热部署的方法

    SpringBoot配置devtools实现热部署的方法

    spring为开发者提供了一个名为spring-boot-devtools的模块来使Spring Boot应用支持热部署,提高开发者的开发效率,无需手动重启Spring Boot应用. devtools的原理 深层原理是使用了两个ClassLoader,一个Classloader加载那些不会改变的类(第三方Jar包),另一个ClassLoader加载会更改的类,称为restart ClassLoader,这样在有代码更改的时候,原来的restart ClassLoader 被丢弃,重新创建一个r

  • 详解SpringBoot配置devtools实现热部署

    详解SpringBoot配置devtools实现热部署

    spring为开发者提供了一个名为spring-boot-devtools的模块来使Spring Boot应用支持热部署,提高开发者的开发效率,无需手动重启Spring Boot应用. devtools的原理 深层原理是使用了两个ClassLoader,一个Classloader加载那些不会改变的类(第三方Jar包),另一个ClassLoader加载会更改的类,称为restart ClassLoader,这样在有代码更改的时候,原来的restart ClassLoader 被丢弃,重新创建一个r

  • springboot + devtools（热部署）实例教程

    springboot + devtools（热部署）实例教程

    技术介绍 devtools:是boot的一个热部署工具,当我们修改了classpath下的文件(包括类文件.属性文件.页面等)时,会重新启动应用(由于其采用的双类加载器机制,这个启动会非常快,如果发现这个启动比较慢,可以选择使用jrebel) 双类加载器机制:boot使用了两个类加载器来实现重启(restart)机制:base类加载器(简称bc)+restart类加载器(简称rc). bc:用于加载不会改变的jar(eg.第三方依赖的jar) rc:用于加载我们正在开发的jar(eg.整个项目里

  • Spring boot实现热部署的两种方式详解

    Spring boot实现热部署的两种方式详解

    热部署是什么 大家都知道在项目开发过程中,常常会改动页面数据或者修改数据结构,为了显示改动效果,往往需要重启应用查看改变效果,其实就是重新编译生成了新的 Class 文件,这个文件里记录着和代码等对应的各种信息,然后 Class 文件将被虚拟机的 ClassLoader 加载. 而热部署正是利用了这个特点,它监听到如果有 Class 文件改动了,就会创建一个新的 ClaassLoader 进行加载该文件,经过一系列的过程,最终将结果呈现在我们眼前. 类加载机制 Java 中的类经过编译器可以把代

  • 详解springboot热启动与热部署

    一.热启动: 每自修改后, 程序自动启动spring Application上下文. Pom中直接添加依赖即可: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency> 这里需要注意的

  • 详解关于Spring Cloud 框架热部署的方法

    详解关于Spring Cloud 框架热部署的方法

    摘要: 所谓热部署,就是在应用正在运行的时候升级软件,却不需要重新启动应用.对于Java应用程序来说,热部署就是在运行时更新Java类文件. 1.在对应的pom.xml 文件中添加依赖 <!--热部署功能-添加依赖 by libingbin2015@aliyun.com --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devt

随机推荐