There are several new resources in swarm mode—as well as nodes and services, there are stacks, secrets, and configs. Config objects are just text files that are created in the swarm and have surfaced as files inside service containers. They're a great way of managing configuration settings, because they give you a single place to store the settings for all your applications.

You use config objects in two ways. You create and manage them with docker config commands, and you make them available to services in Docker service commands and Docker Compose files. This clean separation means your application definition is separate from your configuration—the definition is the same everywhere, and the configuration is loaded by Docker from the environment.

Docker surfaces a config object as a text file inside a container at the path you specify, so you could have a secret called my-app-config in the swarm that appears as C:my-appconfigappSettings.config. Docker doesn't care about the file contents, so it could be XML, JSON, key-value pairs, or anything else. It's up to your application to actually do something with the file, which could be using the complete file as config, or merging the file contents with some default configuration baked into the Docker image.

In my modernization of NerdDinner, I've moved to the .NET Core configuration framework for my application settings. I use the same Config class in all the .NET Framework and .NET Core apps that make up NerdDinner. The Config class adds custom file locations for configuration providers:

public static IConfigurationBuilder AddProviders(IConfigurationBuilder config)
{
  return config.AddJsonFile("config/appsettings.json")
               .AddEnvironmentVariables()
               .AddJsonFile("config/config.json", optional: true)
               .AddJsonFile("config/secrets.json", optional: true);
} 

The configuration providers are listed in reverse-order of precedence. First, they're loaded from the config/appsettings.json file that is part of the application image. Then, any environment variables are merged in—adding new keys, or replacing the values of existing keys. Next, if a file exists at the path config/config.json its contents get merged in—overriding any existing settings. And lastly if a file exists at config/secrets.json then its values are merged in.

This pattern lets me use a hierarchy of configuration sources. The default values for the app are all present in the Docker image. At runtime, users can specify overrides with environment variables or environment variable files—which is easy for developers working on single Docker hosts. In a clustered environment, the deployment can use Docker config objects and secrets, which override the default values and any environment variables.

As a simple example, I can change the logging level for the new REST API. In the appsettings.json file in the Docker image, the logging level is set to Warning. The app writes information-level logs every time there's a GET request, so if I change the logging level in config, I'll be able to see those log entries.

I have the settings I want to use in a file called nerd-dinner-api-config.json:

{
 "Logging": {
  "LogLevel": {
   "Default": "Information"
  } 
 }
}

First, I need to store that as a config object in the swarm, so containers don't need access to the original file. I do that with docker config create, giving the object a name and the path to the source of the configuration:

docker config create nerd-dinner-api-config .configs
erd-dinner-api-config.json

You only need access to the file when you create the config object. Now the data is stored in the swarm. Any node in the swarm can get the config data and supply it to containers, and anyone with access to the Docker Engine can see the config data without needing that source file. docker config inspect shows you the contents of the config object:

> docker config inspect --pretty nerd-dinner-api-config
ID:                     yongm92k597gxfsn3q0yhnvtb
Name:                   nerd-dinner-api-config
Created at:             2019-02-13 22:09:04.3214402 +0000 utc
Updated at:             2019-02-13 22:09:04.3214402 +0000 utc
Data:
{
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  }
}