"CI/CD" several common non-stop publishing methods

What is non-stop publishing?

This article refers to the non-stop release, is to do not stop the external services under the premise of completing the application of the update. The difference from a thermal deployment is that a hot deployment is focused on the application level and is premised on not restarting the application , while non-stop publishing focuses on the service level. With the advent of Moore's law approaching the limit and the multi-core era, distributed applications have become a de facto mainstream. The following first presents a general approach to non-stop publishing for distributed applications, and then introduces Master/worker, a common non-stop release method for stand-alone applications.

Cluster mode

For distributed applications running in a clustered environment, there is typically a load balancing (LB) on top of the application. If during the publishing process, before updating any node (or a group of nodes), the corresponding load of the node should be closed before the load can be updated and then the overall service can be released without downtime. On this basis, in order to ensure the stability of the service, you can add the backup machine support, that is, to update a node, the first hang up the standby machine, update and then remove, and then rotate the update after all the nodes and then finally upgrade the standby machine, as shown in:

A complete design can 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 publishing process, use the Nginx Dynamic Upstream plugin to manipulate Nginx, and then complete the application's start-stop and detection with the script.

Master/worker mode

For stand-alone applications, due to the absence of LB, it is generally implemented by the application container for non-stop publishing features, most commonly master/worker mode. The container resides in a master process and multiple work processes, and the master process is only responsible for loading the program and distributing the request, which is done by the fork worker process. When the container receives a signal to update the application, the master process reloads the updated program and then fork the new worker process to process the new request, and the old worker process is automatically destroyed after the current request has been processed. Ruby's Unicorn, PHP's FPM uses this set of mechanisms.

Extended Reading

Unlike the Master/worker model, Erlang uses another unique way to achieve non-stop publishing.

The Erlang VM holds up to 2 copies of the code for each module, the current version of ' existing ' and the older version ' old ', and when the module is loaded for the first time, the code is the ' present ' version. If a new code is loaded, the ' current ' version of the code becomes ' old ', and the new code becomes the ' old ' version. Erlang has a two-version coexistence approach to ensure that a version is available at any time, and that the service will not stop.

--From the analysis of Erlang thermal update implementation mechanism

Summary

Whether lb or master/worker, the basic idea is that during the release process, a service request can always be processed by a node or a process in the system, thus guaranteeing the availability of the service.

