Microservice Starter (msvc)

Provides elevation of user/project microservices (external processes). The composition of domain microservices is determined by the class of domain center entities `mservices`. Processes are raised there in the same docker container where the platform itself runs. A separate folder is created for each microservice in the working directory of the node, where the contents of the archive are unpacked, and which becomes the working directory.

According to the entity setting `mservice` performs service elevation in active-passive or active-active mode. On all sites, or on specific sites.

The process is lifted by specifying the working folder to which the archive is unpacked as the working folder. This is the path "/var/lib/era/_workdir/<NODE>/mservices/<DOMAIN>/<ENTITY_NAME>". The `/var/lib/era/_workdir/<NODE>/mservices/<DOMAIN>/<ENTITY_NAME>.pid` file, which contains the active operating system process pid, is generated at the same time as it is raised.
If a process crashes, it is immediately rebooted by the port control gen-server, updating the data in the pid file.
If the port control genserver goes down, the process is killed by charged monitoring, and the genserver is immediately rebooted by the domain supervisor.
If a domain is deleted, monitoring slows down the process.
If a node closes, it has time to slow down child processes.
If a node crashes, the next time the domain is started, it will clean up unnecessary processes based on pid files. If there are no processes, but there are files, it will try to nail the process by identifier. The start command is not checked.
If the corresponding `mservice` entity is changed, the domain microservices synchronization process starts no later than 1 second later. The synchronization process is started every 60-65 seconds even without the presence of changes.
If some crash occurs while trying to start processes - retry the domain to synchronize - after 10 seconds.
If synchronization completes with an error - retry the domain to synchronize microservices - after 10-15 seconds.
If synchronization is completed by skipping some part of microservices (the archive has not had time to download, not detected, checksums do not match) - the domain will try again to synchronize microservices in 20-25 seconds.
In case of errors, some of the microservices may have had time to start, some may not, so a stop is enforced before starting.
+ Newly created entities go through the procedure of site filtering, data preparation, finding and unpacking the attachment archive, and starting the service process corresponding to the entity’s settings.
The deleted entities are stopped, the process is terminated, the pid file is deleted, and the data in the directory with the extracted archive is deleted.
+ During synchronization, an entity in which any change is made to any field, except for a field, is considered a changed entity `ext`.
Uploading a new archive to an attachment is also considered an entity change, since the file’s metadata is prescribed in the field `opts.attachment_info`.
Changed entities cause the microservice process to stop (`kill`, without clearing the directory with the extracted archive) and then start again.
Whenever an entity is started/restarted, a check is made to see if it has a zip archive attachment. If the unzip command cannot unzip it, the attachment is considered broken and the entity is excluded from being loaded.
If there is no archive attached to the entity (empty object in the `opts.attachment_info` field) - the entity is analyzed.
If an archive is bound to an entity but is not yet present on the node, the entity is removed from the list of active entities until the next synchronization iteration (no later than 20 seconds later).
If an archive is bound to an entity, but its data does not match the information about the attachment in the entity - the entity is removed from the list of active entities until the next synchronization iteration (no later than 20 seconds later).
If the archive to an entity has not been modified (its data matches the information in `/var/lib/era/_workdir/<NODE>/mservices/<DOMAIN>/<ENTITY_NAME>.archive-info.json`), then no repackaging is performed (even if the directory is manually corrupted).
If the archive to the entity is changed (its data differs from the information about the already unpacked archive) - the service directory is deleted and the archive is unpacked anew, the file is created `*.archive-info.json`
If the archive to an entity is deleted, the entity is removed from the active list until the next synchronization iteration, processes are terminated, and the microservice directory is cleaned.
+ Untouched entities continue to execute without stopping.
+ The microservice process itself should generate the full access URL. Select the connection protocol and authorization method. Authorize the connection under the token of the integration channel, or under the system user. These parameters must be passed to it in the `cmdline` / `cmdparam` entities mservice.

Description of columns in the table

The configuration is managed in an application available to master domain administrators. The application hides the full content of the configuration, but it is nevertheless accessible via the API.

The configuration contains a section to describe all instances of all roles. Parameters are defined for each specific role instance.