Config Server

Services built on Light Frameworks are composed of many plugins as part of the embedded gateway. Each plugin (or middleware handler) has its configuration file and runtime behaviour to control if they are enabled. Developers usually don’t need to worry about these config files as these can be added later on by the operation team in the DevOps pipeline.

Unlike other application frameworks, we are not using a single config file but multiple config files because each service decides which plugins should be utilized and how they are utilized.

When managing the configurations, the following things need to be considered:

  • Multiple config template files per service.
  • Every environment has some different values.
  • Different release tags of the service will have different configurations.
  • Some sensitive values need to be encrypted.
  • Some of the config files need to be merged from several organizations.
  • Some of the config files need to be overwritten from several organizations.
  • When the config server is used, there should be minimum internal config files to ensure the connectivity to the config server

For more information on how to use the Config Server, please visit the tutorial section.

Config Key Design and Conversion

Read More »

Service Config

For any service built with the light-4j frameworks to leverage the light-config-server, we need to add some extra configuration files and environment variables to bootstrap the service. startup.yml Create a startup.yml file to enable the config loader for the a service to bootstrap with the light-config-server. startup.yml # This is the config file to replace the default config loader to a customized one. # For example, load the config files from the config server instead of filesystem. Read More »

Config Server API

There are four groups APIs for the config server. Config Server Admin - Initialize Server This API is used to initialize the server before using it. Two keys must be populated from the UI by two different operators on two different pages and submitted to the API. Once the server receives these keys, it will combine them together and generate a hash that is used to be the encryption key for the sensitive values in the database. Read More »

Config Server API verify on local environment

Build and start the service on local docker test environment Build the config server module cd ~/networknt/light-config-server git pull origin develop mvn clean install Build Hybrid-command from light-portal cd ~/networknt/light-portal git pull origin develop mvn clean install Copy the Hybrid service required jar files for light-docker cd ~/networknt/light-docker git pull origin develop cp ~/networknt/light-config-server/target/config-server-1.5.19.jar ~/networknt/light-docker/hybrid-services/service cp ~/networknt/light-portal/hybrid-command/target/hybrid-command.jar ~/networknt/light-docker/hybrid-services/service Start backend db and hybrid service from light-docker cd ~/networknt/light-docker docker-compose -f docker-compose-hybrid-service. Read More »

Config Server Process

There are three major processes in the light-config-server design: Key/Value/Secret Maintenance Key/value/secret maintenance is very simple. The focus point is the fine-grained authorization on who can access what value or secret. Once the values or secrets are in the database, they are ready to be retrieved when the first request comes in to get the config package. Config Template Management Config template management is a little bit tricky. We have a lot of config files from the light-4j platform that we can maintain in a repository in networknt for templates of each release version. Read More »

Config Server Design

Security Interaction There will be a lot of sensitive info in the config files such as database password, private key store password etc. The security design is very crucial for the config server and the interaction during the service startup. As the sensitive info in the config file is encrypted, we need to pass the encryption key to the service as an environmental variable in the deployment file. The same encryption key must be previously set up on the config server for the service from the same operator so that the config server will use it to encrypt the sensitive info. Read More »

Requirement

When managing the configurations, the following things need to be considered as part of the requirement. Config server instance per environment For each environment, there should be an instance of config server with config templates and key/value pairs for the environment. The authentication and authorization would be different so that developers can access the DEV config server. Operators can access the UAT config server, and Production operators can access the PROD config server. Read More »