<p>As per <a href="https://12factor.net/config" rel="nofollow noreferrer">https://12factor.net/config</a>, configuration like this should be stored as environment variables.</p>

<blockquote>
  <p>The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.</p>
</blockquote>

<p>A service that you connect to is suitable to be defined as configuration, so the use of env vars is appropriate here.</p>

CC BY-SA 3.0
2017-11-17T21:53:27.530Z
2017-11-17T21:53:27.530Z
user2640621
<p>Imagine you have decided to abstract from exact service location.</p>

<p>Normally, you have a cody world with the service name=DNS.</p>

<p>Say, you have prototyped something with S3 compatible API like exoscale/pithos.</p>

<p>But then you think okay this was actually a mockup and now you go for real S3 in production.</p>

<p>Would you rewrite the stack, trick around with <code>${ENV_VARIABLES}</code> or is there some more elegant way to proceed?</p>

<docker><microservices><networking>
Dynamic service redirections in Docker
Ta Mu
# Dynamic service redirections in Docker

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

Imagine you have decided to abstract from exact service location.

Normally, you have a cody world with the service name=DNS.

Say, you have prototyped something with S3 compatible API like exoscale/pithos.

But then you think okay this was actually a mockup and now you go for real S3 in production.

Would you rewrite the stack, trick around with `${ENV_VARIABLES}` or is there some more elegant way to proceed?

**Tags:** docker, microservices, networking


---

## 1 answers

### Answer by username_1 on 2017-11-17. Score: 1 | Accepted answer

As per <https://12factor.net/config>, configuration like this should be stored as environment variables.

> The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

A service that you connect to is suitable to be defined as configuration, so the use of env vars is appropriate here.


---

