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