osp-configuration-dispatcher¶
Overview¶
The configuration dispatcher functions as a repository storing configurations and facilitating access to other modules. It maintains a configuration history, enabling review of changes and the ability to revert to prior configurations.
This module offers the following functionalities:
Authentication of modules
Generation of module certificates when required.
Storage of certificates in Swarm.
Maintenance of up-to-date stack definitions based on the configuration.
Storage of configuration (refer to the persistent configuration section for details).
Sending of configuration to modules.
A GIT interface with validation of the configuration
Warning
During its initial execution, the dispatcher may experience delays in certificate generation. These delays can become particularly pronounced in cases where the system lacks a reliable entropy source, such as in virtual machine environments. It is essential to ensure that your system is properly configured for optimal performances in such situations.
List of configuration files¶
Filename |
Short description |
Format |
Documentation |
---|---|---|---|
module.service |
Each service is described in its proper file and then assembled |
yml |
See the Swarm administration or Official documentation |
module.dispatcher |
Defines the dispatcher configuration |
json |
Healthcheck¶
The process survey that the GIT hook is available.
Environnement variables¶
Note
Environnement variables can be used to fine tune some of the module parameters, for generic information see the swarm page.
Variable name |
Default value |
Usage |
---|---|---|
DISPATCHER_HOST |
10000 |
The hostname on which the modules can fetch the configuration |
DISPATCHER_PORT |
Describe the SWARM configuration see below |
The port on which the modules can fetch the configuration |
dispatcher-threads-number |
50 |
The configuration dispatcher’s thread count can be adjusted, especially when dealing with a high number of modules. This adjustment is particularly useful as the dispatcher dedicates one thread to each module during the configuration parsing process. If you’re working with constrained CPU resources, reducing this value can be beneficial. |
aggregation-timeout-ms |
15000 |
The maximum time in millisecond to parse the configuration when a new one is pushed. After this timeout the configuration is rejected. |
wait-for-configuration-timeout-ms |
60000 |
The maximum time to wait for another configuration to be fully parsed |