2

(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:

  1. Store environment-specific configurations on a mounted volume, and make the volume mapping a deployment variable
  2. 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?

Improve this question
2
  • Yet another way (with docker) is to setup environment variables at container spin up, and have the inner conf files referencing those variables. I can't tell if it would makes sense in azure.
    – Tensibai
    Commented May 12, 2017 at 7:18
  • It's largely a matter of personal preference. Personally, I prefer the external configuration store (I use Consul mostly), because it provides for the option of live configuration updates without a redeploy (assuming the app has reasonable cache lifetimes on config values).
    – Adrian
    Commented May 12, 2017 at 19:16

1 Answer 1

Reset to default
1

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.