[CI/CD] several common non-stop release methods

[CICD] what are several common non-stop release methods?

The release without downtime mentioned in this article refersDo not stop external servicesTo update the application. The difference with hot deployment is that hot deployment focuses onApplicationLevel andDo not restart the applicationIs the premise, while releasing without stopping services focuses onServiceLevel. With Moore's law approaching the limit and multi-core era, distributed applications have become the mainstream. The following describes a general non-stop release method applicable to distributed application environments, and then describes a common non-stop release method for standalone applications such as Master and Worker.

Cluster mode

For distributed applications running in the cluster environment, load balancing (LB) is generally applied ). If the load of any node (or a group of nodes) is disabled before the node is released, the load is enabled after the node is updated, the service can be released without stopping services. On this basis, to ensure the stability of the service, you can add the support of the slave machine, that is, when updating a node, the slave machine is mounted first, and then removed after the update, rotate and update all nodes in turn, and then upgrade the slave, as shown in:

For the complete design, refer to another article I wrote.

The above release process is actually a simple CD (Continuous Deployment) system. As a reference implementation, you can use the Jenkins 2.0 Pipeline feature to define the entire release process, use the Nginx Dynamic Upstream plug-in to manipulate Nginx, and then use the script to start, stop, and detect the application.

Master/Worker mode

For standalone applications, because LB does not exist, application containers generally implement the non-stop release feature. The most common mode is the Master/Worker mode. The container is resident in one master process and multiple work processes. The master process is only responsible for loading programs and distributing requests, and the worker process from the fork completes the specific work. When the container receives a signal to update the application, the master process reloads the updated program and fork the new worker process processes the new request, the old worker process is automatically destroyed after processing the current request. Ruby's Unicorn and php fpm all adopt this mechanism.

Additional reading

Unlike the Master/Worker mode, erlang adopts another unique method to achieve non-stop publishing.

Erlang VM can store up to two pieces of code for each module. The current version 'current 'and the old version 'old'. When the module is loaded for the first time, the code is 'Current. If a new code is loaded, the 'date' version code is changed to 'old' version, and the new code is changed to 'date' version. Erlang uses the coexistence of two versions to ensure that a version is always available at any time, so that external services will not stop.

-- Import self-analysis: implementation mechanism of erlang hot update

Summary

Whether it is LB or Master/Worker, the basic idea is that service requests can always be processed by a certain node or process of the system through a certain mechanism during the release process, this ensures service availability.