Warm update libraries from the application or via API

The most commonly used method of upgrading to a new minor version.

Produced inside the container by substituting all libraries and assets with versions from the archive with the update. Docker-The container is not recreated, but remains the same. Therefore, the version of the container also remains the same and may not be consistent with the internally executable version of the platform. This, however, does not create any risks.

The update file has the format name 'era_<VERSION>_debian_amd64.zip' and contains the libraries and assemblies in the target directory tree. Such an update archive can be applied to an arbitrary installed version, except in a few cases described below in "Limitations".

Uploading is performed to the web server via API or the "Settings" admin application with authorization under the master domain administrator account.

Preparing the update involves copying the archive to all available servers in the cluster and unpacking it. The archives are placed in the working directories of nodes with active microservices instances mic and ic. Path inside the container: "/var/lib/era/_workdir/<NODE>/autoupdate"). The unpacked directories are placed in the directory "/usr/lib/era_platform/<VERSION_DIRECTORY>". The entire time the training is in progress, the system is active and available. Update copying is intentionally slowed down so as not to significantly impact network bandwidth.

The upgrade is applied by changing the /usr/lib/era/ symlink to the directory with the updated version on all available servers in the cluster. The root application is then unloaded, initiating a restart of the docker container. A previously prepared update can be applied at any time if no other operations (canceling the current update or uploading another update file) have been performed since it was prepared.

The architecture prevents servers and nodes of different versions from meshing into a single cluster. So as you apply, nodes with the old version are unloaded and those with the new version are loaded without affecting each other. The upgrade is completed when all nodes are restarted on the upgraded version and meshed into a single cluster.

The first time the updated version is loaded, the databases are updated with scripts and the static assets are moved to their new placement according to the changes.

In terms of all target system processes, the update runs from the time the update is applied until the node reboot is complete

The state is checked by polling /system/state and monitoring nodes and their uptime.

If state monitoring tools are connected to the system, successful completion can also be tracked using them.

This update can be done through the master domain administrator application, through the API, or manually within the container.

Step 1. log in to the master domain under the role account "admin". Open the Settings application":

Step 2. Select System/Update section":

Step 3. Select the update archive:

Step 4. Upload the selected archive to the server by clicking the "Upload" button and wait for the upload to finish:

Step 5: Initiate preparation for the upgrade by clicking the "Prepare":

Step 6. Preparation is a lengthy procedure, depending on the number of servers, it can take 5-10 minutes. The application does regular polling of the status of the update process and displays its output in the left list. The displayed list lists the cluster nodes responsible for the update. Each of them goes through the states: idle .. prepare .. ready. The completion of the preparation procedure will be indicated by the "ready" status of all items in the left list:

Step 7. When this state is reached (all ready), you can continue the upgrade, initiate a system restart on the new version, or wait for a more appropriate time. For example, waiting for a load drop or the onset of a process interruption time.

When you click on the "Apply" button, a dialog box listing all states will be displayed first. It is intended to help eliminate the hasty application of an update when not all items on the list have become ready. This is what it looks like on a false start:

This is how the confirmation window looks in normal mode:

Step 8. After confirming the start of the upgrade, the system will begin to restart. Both the web server and access to the API. In the app, it looks like this:

After startup, the state of the nodes responsible for the update will be displayed again. All servers will display the new version:

Step 9: In the "System/Nodes" section, you can monitor the progress of restarting the nodes and resetting the uptime. Sorted by uptime, you can monitor the progress of booting. Immediately after the restart and for the first 10 minutes the node status is displayed with a red pictogram. The first hour - yellow pictogram, and after that - green pictogram.

Step 10. Switching to the System/State section, you can get information about /system/state. An empty list is a criterion of correctness of the performed update:

Step 11. In the "Home" section, after pressing F5, the browser will display information about the new version:

Step 12. After 10 minutes, no red icon should remain in the node monitoring:

The update process is managed through the master domain API available to accounts with the role of "admin".

Detailed description Update-API.

Teams:

Separate API for monitoring:

The described upgrade method cannot be used in the following cases:

In these cases, when the server attempts to perform an upgrade, it will return information about the need to upgrade.

If not all servers are available at the time of the update, but the system is up and running, the available set of servers will be updated. If a previously unavailable server is connected, it will be refreshed just before the microservices download is initiated.