How to implement Nginx hot deployment

Close the firewall so that the Nginx service can be accessed locally through the browser.

[root@localhost ~]# systemctl stop firewalld

Semaphore

View semaphore:

[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	

There are 64 kinds of semaphore, the following are several Commonly used semaphores:

• SIGINT, SIGTERM: Quickly close.

• SIGQUIT: Graceful shutdown (gracefully shut down the process, that is, wait until the request is completed and then shut down).

• SIGHUP: Smooth restart, reload the configuration file (smooth restart, no need to restart the server after modifying the configuration file).

• SIGUSR1: Re-read the log file, which is more useful when cutting the log file.

• SIGUSR2: Smoothly upgrade the executable program, used when nginx is upgraded.

• SIGWINCH: Shut down the worker process gracefully.

Nginx hot deployment

Nginx is a multi-process, high-performance reverse proxy server, including a master process and multiple worker processes (the number of worker processes can be set through the worker_processes parameter in the nginx.conf configuration file, the default1), which can make full use of multi-core processors.

Default 1 worker processes.

And the master process and the worker process have a parent-child process relationship.

NginxThe working mode is multi-process, NginxThere will be a master## after startup #Processes and multiple worker processes (default 1), multiple worker child processes will listen to the master parent process listening port (Refer to the relationship between parent and child processes), handle requests in parallel. masterThe parent process is mainly used to manage the worker child process (manage the worker process that actually provides services, send signals to the worker process, monitor The running status of the worker process. When the worker process exits abnormally, a new worker process will be restarted) to read and verify the configuration information, The master process will not serve user requests, but user requests are processed by the worker process.

Nginx is controlled through semaphores, such as stopping and restarting Nginx. Semaphores are a mechanism for inter-process communication. The main process controls multiple worker sub-processes through semaphores.

Now let’s demonstrate how
Nginx

implements hot deployment. The blogger modified

Nginx Configuration file to simulate the upgrade of Nginx (first copy a 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

Since the hot deployment of Nginx

has not yet been performed, the current visit to

http://192.168.1.199/ is still the original one Nginx page.

View the process of
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

Send# to the master

process ##SIGUSR2

signal allows Nginx to smoothly upgrade the executable program. You can see that Nginx has restarted a set of master processes and worker processes, and the new master process is the old master The child process of the process (through the inheritance relationship between parent and child processes, the new master process can easily inherit the related resources of the old master process). <pre class="brush:bash;">[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</pre>And Nginx stores the old and new

pid

files in the log directory (saves the ID of the old and new master processes) ). <pre class="brush:bash;">[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</pre>Sends the SIGWINCH signal to the old

master

process, allowing the old master process to close the old worker process. <pre class="brush:bash;">[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</pre>Now visit http://192.168.1.199/, it will respond

404

.

When accessing http://192.168.1.199/nacos
, you will access the

Nacos

service .

如果升级版本没有问题，就可以给旧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信号是否需要重新加载配置文件。

The above is the detailed content of How to implement Nginx hot deployment. For more information, please follow other related articles on the PHP Chinese website!