Implementation of Nginx hot deployment

Just follow the above blog post. Turn off the firewall and allow local access to Nginx service through a browser.

[root@localhost ~]# systemctl stop firewalld

Semaphore

View the 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 types of semaphores. The following are some commonly used semaphores:

• SIGINT , SIGTERM : fast shutdown.
• SIGQUIT : graceful shutdown (closing the process gracefully, that is, waiting for the request to complete before closing).
• SIGHUP : Smooth restart, reload the configuration file (smooth restart, no need to restart the server after modifying the configuration file).
• SIGUSR1 : Reread the log file, which is very useful when cutting log files.
• SIGUSR2 : Smoothly upgrade executable programs, used when upgrading nginx .
• SIGWINCH : Gracefully shut down a worker process.

Nginx hot deployment

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

The default is 1 worker process.

And the master process and the worker process are parent-child process relationships.

Nginx works in multi-process mode. After startup, Nginx will have a master process and multiple worker processes ( 1 by default). Multiple worker child processes will listen to the port listened by master parent process (refer to the relationship between parent and child processes) and process requests in parallel. The master parent process is mainly used to manage 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, and restart a new worker process when the worker process exits abnormally), read and verify configuration information. The master process does not provide services for user requests, and user requests are processed by the worker process.

Nginx is controlled by semaphores, such as stopping and restarting Nginx . Semaphore is a mechanism for inter-process communication. master process controls multiple worker processes through semaphores.

Now let's demonstrate how Nginx implements hot deployment. The blogger simulates the upgrade of Nginx by modifying the Nginx configuration file (make a copy first).

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

Since Nginx has not been hot-deployed yet, visiting http://192.168.1.199/ now still displays the original Nginx page.

View the Nginx process:

[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 a SIGUSR2 signal to master process to allow Nginx to smoothly upgrade the executable program. You can see that Nginx restarted a set of master processes and worker processes, and the new master process is a child process of the old master process (through the inheritance relationship between parent and child processes, the new master process can easily inherit the relevant resources of the old master process).

[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

And Nginx stores the old and new pid files in the log directory (saving ID of the new and old master processes).

[root@localhost conf]# ll ../logs
Total dosage 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 Dec 20 23:18 nginx.pid
-rw-r--r--. 1 root root 6 Dec 20 22:25 nginx.pid.oldbin
[root@localhost conf]# cat ../logs/nginx.pid
15019
[root@localhost conf]# cat ../logs/nginx.pid.oldbin 
14964

Send a SIGWINCH signal to the old master process to let the old master process shut down the old worker process.

[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

Now visit http://192.168.1.199/ and it will respond with 404 .

And visiting http://192.168.1.199/nacos will access the Nacos service.

If there is no problem with the upgraded version, you can send a SIGQUIT signal to the old master process to shut it down. This way, only master master and the new worker process remain, thus realizing hot deployment of 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

If there is a problem with the upgraded version and you need to roll back to the previous version, you can send a SIGHUP signal to the old master process. Because the blogger retested, the process numbers have changed, but it is obvious that the old master process recreated the old worker process, and master and worker processes that were upgraded were not closed.

[root@localhost conf]# kill -s SIGHUP 15084
[root@localhost conf]# ps -ef | grep nginx
root 15084 1 0 December 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

Send a SIGQUIT signal to the new master process to shut it down. This way, only master master and the newly created old worker process remain, thus achieving rollback.

[root@localhost conf]# kill -s SIGQUIT 15106
[root@localhost conf]# ps -ef | grep nginx
root 15084 1 0 December 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

Rollback successful.

You also need to roll back the version (that is, roll back the configuration file here, otherwise there will be problems when you restart next time).

[root@localhost conf]# cp -f nginx_old.conf nginx.conf
cp: Overwrite "nginx.conf"? y

Why does the worker process created by the old master process fail to re-read the configuration file when the old master process sends the SIGHUP signal? Here is the official description:

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.

Send a SIGHUP signal to the old master process. The old master process will start new worker processes without rereading the configuration . Afterwards, all new processes can be shut down gracefully by sending a SIGQUIT signal to the new master process.

If there is no new process (only a set of master and worker processes), modify the configuration file and send a SIGHUP signal to the master process to see if the configuration file will be reloaded.

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

Obviously the configuration file has been reloaded. Since the blogger has not read the source code, he can only guess the implementation of Nginx (if it is wrong, please comment and supplement). Nginx should decide whether SIGHUP signal needs to reload the configuration file based on whether hot deployment is currently in progress (there is a new master process).

This is the end of this article about the implementation of Nginx hot deployment. For more relevant Nginx hot deployment content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!