CONFIGSERVICE

This core service manages profile-related and other configuration files using git as storage backend.

Characteristics


Service Nameconfigservice
Port Range7281
Profilesprod,cloud,native
Helm Chartyuuvis

Function

Most of the yuuvis® Momentum core services are configured via profiles and corresponding configuration files. Following the basic concepts of Spring Boot, the configuration files are stored on a git server and are managed via the CONFIGSERVICE.
>> Configuring Services using Profiles

The CONFIGSERVICE cannot start without an active connection to the git server.

At runtime, the CONFIGSERVICE applies all changes to configuration files to its local resources first. At regular intervals of 5 minutes, the remote resources on the git server are synchronized according to the following procedure:

  • All changes in the local resources applied during the last five minutes are summarized in one single commit.
  • A git pull request with THEIRS merge policy is used to introduce changes made directly in the remote resources into the local resources. 
    Note: It is thus possible to overwrite changes that are applied to the local resources (e.g., via yuuvis® Momentum endpoints) by applying changes directly to the remote repository. However, those changes are NOT visible before the regular synchronization.
  • The commit and the merge result are published via a single push request.

This procedure of collecting and summarizing changes reduces the number of commits that have to be managed by the CONFIGSERVICE in case of a high frequency of change requests.

Additionally, as of 2022 Summer, it is possible to synchronize the local resources of the CONFIGSERVICE and the remote resources on the git server via the endpoint POST <host>:<port_of_configservice>/manage/refresh at any time. This synchronization is additional and independent of the automated synchronization every 5 minutes.
>> POST /configservice/manage/refresh

Note: In case multiple instances of the CONFIGSERVICE are running, the synchronization of the individual local resources is done at the regular intervals of 5 minutes as well. Thus, requests for resources that have been modified less than 5 minutes ago might lead to the retrieval of a deprecated version of those resources. Resources created less than 5 minutes ago might be not available.

In the Kubernetes environment, each instance of the CONFIGSERVICE additionally stores the resources in a separate persistent volume at /tmp/configservice. In the default configuration, changes in those resources are used for the service initialization. I.e., changes that are not yet included in the commit are calculated via git diff and considered during the synchronization procedure described above.

Configuration

 Open description of deprecated version 2021 Autumn...

The CONFIGSERVICE can retrieve the cached version of configuration files even if the git is temporarily not accessible. Thus, during a downtime of the git server, GET requests to the CONFIGSERVICE will be successful whereas requests for storing resources will not be successful. The behavior is controlled via the boolean value of the the service-internal parameter fail-if-git-not-available in case the git server is temporarily not accessible.

Value for 'fail-if-git-not-available'Behavior of CONFIGSERVICE during temporary downtime of the git server
false (default)Retrieval of cached resource files during git server downtime is enabled.
trueAny request for a resource file via CONFIGSERVICE will return an error. 

Per default, the CONFIGSERVICE uses the persistent volume at /tmp/configservice for initialization during a restart. Alternatively, the CONFIGSERVICE can delete and recreate the directory /tmp/configservice by cloning the remote resources during the initialization. This behavior can be applied by one of the following configurations:

  • Set resume-from-local-git: false in the application-prod.yml configuration file.
  • Set the environment variable RESUME-FROM-LOCAL-GIT=false in the Kubernetes deployment of the CONFIGSERVICE (default is true).

Read on

SYSTEM Service

This core service manages schemata, role sets and app sets. Find here characteristics and configuration options. Keep reading

AUTHENTICATION Service

This core service manages the authentication of users and applications for the access to services within the yuuvis® Momentum cluster. Keep reading

Basic Use Case Flows

Graphical overviews describing the interaction of the yuuvis® Momentum core services in exemplary basic use case flows.  Keep reading