Shulou(Shulou.com)06/01 Report--

Editor to share with you how to achieve Nginx hot deployment, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Turn off the firewall so that Nginx services can be accessed locally through a browser.

[root@localhost ~] # systemctl stop firewalld

Semaphore

View semaphores:

[root@localhost ~] # kill-l 1) SIGHUP 2) SIGINT 3) SIGILL 4) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR111) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGTERM16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ26) SIGVTALRM 27) SIGPROF 28) SIGIO 29) SIGPWR31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+843) SIGRTMIN+9 44) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+1348) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-1253) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-758) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-263) SIGRTMAX-1 64) SIGRTMAX

There are 64 semaphores, and here are several commonly used semaphores:

SIGINT, SIGTERM: quick shutdown.

SIGQUIT: shut down the process gracefully (that is, wait for the request to finish before closing).

SIGHUP: smooth restart, reload 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: smooth upgrade executable program, used when upgrading nginx.

SIGWINCH: shut down the worker process calmly.

Hot deployment of Nginx

Nginx is a multi-process, high-performance reverse proxy server that contains one 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, default 1), so you 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 processes.

The Nginx working mode is multi-process. After Nginx is started, there will be one master process and multiple worker processes (default 1). Multiple worker child processes will listen to the port that the master parent process listens to (refer to the relationship between the parent and child processes) and process requests in parallel. The master parent process is mainly used to manage the worker child process (manage the worker process that really provides services, send signals to the worker process, monitor the running status of the worker process, when the worker process exits abnormally, it will restart the new worker process), read and verify the configuration information, the master process will not provide services to the user request, but the user request is processed by the worker process.

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

Now to demonstrate how Nginx is hot deployed, the blogger simulates the upgrade of Nginx by modifying Nginx's configuration file (copy a copy first).

[root@localhost] # cd / usr/local/nginx/conf/ [root@localhost conf] # ll total consumption 68m / r / 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 December 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 December 20 20:24 scgi_params-rw-r--r--. 1 root root 636 December 20 20:24 scgi_params.default-rw-r--r--. 1 root root 664 December 20 20:24 uwsgi_params-rw-r--r--. 1 root root 664 December 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.confession [root @ localhost conf] # vim nginx.conf

Since there is no hot deployment for Nginx, visiting the http://192.168.1.199/ page is still the original Nginx page.

View the progress of Nginx:

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

Send a SIGUSR2 signal to the master process to allow Nginx to smoothly upgrade the executable. You can see that Nginx restarts a set of master processes and worker processes, and the new master process is a child of the old master process (through the inheritance of the parent-child process, 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 nginxroot 14964 10 22:25? 00:00:00 nginx: master process. / nginxnobody 14965 14964 0 22:25? 00:00:00 nginx: worker processroot 15019 14964 0 23:18? 00:00:00 nginx: master process. / nginxnobody 15020 15019 0 23:18? 00:00:00 nginx: worker processroot 15022 1521 0 23:19 pts/0 00:00:00 grep-color=auto nginx

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

[root@localhost conf] # ll.. / logs total dosage 16 RW / logs. 1 root root 2729 December 20 23:20 access.log-rw-r--r--. 1 root root 708 December 20 23:18 error.log-rw-r--r--. 1 root root 6 December 20 23:18 nginx.pid-rw-r--r--. 1 root root 6 December 20 22:25 nginx.pid.oldbin [root@localhost conf] # cat.. / logs/nginx.pid15019 [root@localhost conf] # cat.. / logs/nginx.pid.oldbin 14964

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

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

When you visit http://192.168.1.199/ now, you will respond to 404.

If you visit http://192.168.1.199/nacos, you will access the Nacos service.

If there is no problem with the upgrade version, you can send a SIGQUIT signal to the old master process to shut down the old master process, leaving only the new master process and the new worker process, realizing the hot deployment of Nginx.

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

If there is a problem with the upgrade 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 has re-tested, so the process number has changed, but it is clear that the old master process recreated the old worker process, and the master and worker processes that carried out the version upgrade were not shut down.

[root@localhost conf] # kill-s SIGHUP 15084 [root@localhost conf] # ps-ef | grep nginxroot 15084 10 December 20? 00:00:00 nginx: master process. / nginxroot 15106 15084 December 20? 00:00:00 nginx: master process. / nginxnobody 15107 15106 December 20? 00:00:00 nginx: worker processnobody 15131 1584 0 00:02? 00:00:00 nginx: worker processroot 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 down the new master process, leaving only the old master process and the newly created old worker process to be rolled back.

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

The rollback was successful.

You also need to roll back the version (that is, the configuration file here of the blogger, otherwise there will be a problem with the next restart).

[root@localhost conf] # cp-f nginx_old.conf nginx.confcp: overwrite "nginx.conf"? Y

Why send a SIGHUP signal to the old master process, and the worker process recreated by the old master process did not reread the configuration file? Here are the official instructions:

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.

Sends a SIGHUP signal to the old master process. The old master process starts the new worker process without rereading the configuration. After that, all new processes can shut down normally by sending a SIGQUIT signal to the new master process.

If there is no new process (only a set of master, worker processes), modify the configuration file, and then 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, and since the blogger has not looked at the source code, he can only guess the implementation of Nginx (if it is wrong, please comment and add). Nginx should decide whether the SIGHUP signal needs to reload the configuration file based on whether it is currently in hot deployment (there is a new master process).

These are all the contents of the article "how to achieve Nginx Hot deployment". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.