<p>we do this with .conf files and loading them via compose</p>

<p>env_file: /path/to/our.conf</p>

<p>they can also be used with </p>

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

<p>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</p>

CC BY-SA 3.0
2017-05-16T21:17:52.983Z
2017-05-16T21:17:52.983Z
Zagurim
<p>(I reviewed this <a href="https://devops.stackexchange.com/questions/977/where-should-i-put-my-application-configuration">question</a> but the one answer doesn't offer practical solutions.)</p>

<p>The general wisdom when it comes to containers appears to be:</p>

<p><strong><em>"Make them immutable and identical."</em></strong></p>

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

<p>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.</p>

<p>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:</p>

<ol>
<li>Store environment-specific configurations on a mounted volume, and make the volume mapping a deployment variable</li>
<li>Use configuration service such as in the <a href="https://docs.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store" rel="nofollow noreferrer">External Configuration Store</a> pattern</li>
</ol>

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

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

CC BY-SA 3.0
2017-05-12T07:18:46.787Z
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
CC BY-SA 3.0
2017-05-12T19:16:19.123Z
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
<deployment><configuration><environments><containers>
Where to Store Container Configuration
Dave Swersky
# Where to Store Container Configuration

(Asked by: username_0 on 2017-05-11)

(I reviewed this [question](https://devops.stackexchange.com/questions/977/where-should-i-put-my-application-configuration) 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](https://docs.microsoft.com/en-us/azure/architecture/patterns/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?

**Tags:** deployment, configuration, environments, containers

> **Comments:**
> **username_1**: 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.  
> **username_2**: 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).  

---

## 1 answers

### Answer by username_3 on 2017-05-16. Score: 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


---

