Where to Store Container Configuration

(I reviewed this question but the one answer doesn't offer practical solutions.)

The general wisdom when it comes to containers appears to be:

"Make them immutable and identical."

I take this to mean that every container for a given application function (a web server, for example) should be bit-for-bit identical. The code, the internal config, and the file system should be built the same way every time for a given version.

This begs the question: where to store the config that makes a given app container a DEV, TEST, QA, or PROD container? If the environment config is stored inside the container, that makes them different. This seems to run contrary to the identical/immutable goal.

A better model would be to somehow keep environment-specific configuration outside the container. There are two methods I can think of to do this:

• Store environment-specific configurations on a mounted volume, and make the volume mapping a deployment variable

• Use configuration service such as in the External Configuration Store pattern

My particular use case is for .NET web applications, where the web.config is a file stored with the application.

Both options appear to have potential pros and cons. Is one of these options better, or am I missing a potential best option?

we do this with .conf files and loading them via compose

env_file: /path/to/our.conf

they can also be used with

docker run --env-file /path/to/our.conf ourcontainer:version

In some cases we use the variables defined in our conf files directly, meaning the code we are running reads them direct, in others we need to modify other files on a per environment basis so we use sed or other tools to make changes to a file we have turned into a template

StackExchange DevOps Q#1152, answer score: 1