Service Configuration

The documentation applies to: v0.8.0

Distributed Systems and Multiple Environments problem

In monolithic architecture, this problem isn't complexity. However, in distributed systems, it should be a big challenge to control many configuration files. Combine with multiple environments, it will multiply a number of configuration files for n environments.

So we need to have a solution for centralizing all configuration files into one place that can provide exactly a environment configuration file.

.NET Core Configuration

.NET Core Configuration is a Configuration feature which helps .NET Core serivce to maintain it own configuration file. LET Portal is developed to keep this feature in Service Configuration. Let's take a look in this flow:

1. In ServiceA, it has own appsettings.{env}.json which contains ServiceOptions and ConfigurationServiceOptions. The main purpose of these options is configuring Service Management's Url, Service Name and Version. Please keep note 3 parameters.
2. In ServiceA Program.cs, ServiceA will take Endpoint, Service Name and Version in appsettings.json, combine into a url is api\configurations\ServiceA\v1.0. For example: http://localhost:56456/api/configurations\ServiceA\v1.0.
3. Next, ServiceA performs HTTP GET via this url to retrieve a combined appsettings.json file which locates in Files\ServiceA\v1.0\appsettings.json folder
4. In Service Management, it combined apsettings.json and appsettings.{Env}.json which locates in the same folder ServiceA\v1.0. Then it returns this combined file back to ServiceA.
5. In ServiceA, after retrieving this file, it will combine between local appsettings.json and response appsettings.json into one. And it will register Configuration Dependency Injection which allowing to use IOptionsMonitor<Options>.

These files in Files folder will be look like below:

Merge version-based configuration

By default, LET Portal will merge top-bottom based on folder order. For example, if you have this service folder structure:

• ServiceA
  • v1.0
    • appsettings.json
    • appsettings.Prod.json
  • v1.1
    • appsetting.json
    • appsettings.Prod.json
  • v1.2
    • appsettngs.json
    • appsettings.Prod.json

So if you access api/configurations/ServiceA/v1.0, you will get appsettings.json of v1.0 only. But if you access api/configurations/ServiceA/v1.2, you will get combined of v1.0, v1.1, v1.2. Thus, a combined appsettings.json will be look like

```json tab="v1.0" { "DatabaseOptions": "ABC" }

```json tab="v1.1"
{
    "DatabaseOptions": "XYZ",
    "Component": "123",
    "IsAllowed": true
}

```json tab="v1.2" { "DatabaseOptions": "XYZW", "Component": "ABC" }

```json tab="combined v1.2"
{
    "DatabaseOptions": "XYZW",
    "Component": "ABC",
    "IsAllowed": true
}

Shared Folder

Another feature in Service Configuration is shared configuration file. It contains all shared options which applied into all services. The merging rule is applied as service folder.