<p>One could use the same docker-compose file for dev, test, acceptance and production (DTAP) systems. Things that deviate per environment, e.g. passwords could be defined in an .env file.</p>

<p>If .env files are not a solution for some reason then one could create different docker-compose files, e.g. docker-compose.override (dev), docker-compose.test, docker-compose.acc and docker-compose.prd.</p>

<p>I personally prefer the first option, e.g. using .env files and a docker-compose.override for dev. </p>

CC BY-SA 4.0
2020-11-12T10:06:46.533Z
Although this answer already has some years on its shoulds, coming by it just now and seeing that it's the accepted answer I just want to add: Before you consider running docker-compose in production, think about running even a 1-node swarm so you have access to the "deploy" key in your docker-compose file. Compose itself was really not meant to run a prod environment.
Worp
CC BY-SA 3.0
2017-10-03T22:01:52.077Z
2017-10-03T22:01:52.077Z
030
<p><a href="https://saltstack.com/" rel="nofollow noreferrer">SaltStack</a> is great at generating these kinds of files based on metadata you feed to it via "pillars" as Salt itself uses YAML files heavily. Salt uses a <a href="http://jinja.pocoo.org/" rel="nofollow noreferrer">Jinja templating engine</a> (though others are also available). </p>

<p>Similarly, <a href="https://puppet.com/" rel="nofollow noreferrer">Puppet</a> also uses YAML heavily and is able to do the same using an <a href="https://docs.puppet.com/puppet/5.3/lang_template_erb.html" rel="nofollow noreferrer">ERB</a> template. </p>

<p>If you find that some of this metadata are things like a listening IP address or a hostname, these systems automatically generate variables such as this using <a href="https://docs.puppet.com/facter/" rel="nofollow noreferrer">facter</a> facts or salt <a href="https://docs.saltstack.com/en/latest/topics/grains/" rel="nofollow noreferrer">grains</a> respectively which can further reduce the amount of metadata you need to suply.</p>

<p><a href="https://www.chef.io/chef/" rel="nofollow noreferrer">Chef</a> is probably also capable of this, though I am not familiar with that configuration management system.</p>

CC BY-SA 3.0
2017-10-04T15:28:59.763Z
2017-10-04T15:28:59.763Z
James Shewey
<p>Currently I find myself managing a set of embarassingly similar YAMLs for environment profiles. I see there a scaling trouble if there will be <em>lots</em> of dynamic environments (i.e. fluid acceptance test configurations, with disposable environments you can do that!)</p>

<p>Has anybody done a working implementation to build YAMLs dynamically on scale based on some generic represenation ( kind of CasC level 2 beyond some naive scripting), or if this makes no sense, why and which way is to prefer then.</p>

CC BY-SA 3.0
2017-06-23T12:10:58.663Z
Do you already use [variable substitution](https://docs.docker.com/compose/compose-file/compose-file-v2/#variable-substitution) in your compose files? If they really are "embarassingly similar", that might be an option.
Hexaholic
<docker-compose>
Dynamic YAMLs for Docker Compose
Ta Mu
# Dynamic YAMLs for Docker Compose

(Asked by: username_0 on 2017-06-23)

Currently I find myself managing a set of embarassingly similar YAMLs for environment profiles. I see there a scaling trouble if there will be *lots* of dynamic environments (i.e. fluid acceptance test configurations, with disposable environments you can do that!)

Has anybody done a working implementation to build YAMLs dynamically on scale based on some generic represenation ( kind of CasC level 2 beyond some naive scripting), or if this makes no sense, why and which way is to prefer then.

**Tags:** docker-compose

> **Comments:**
> **username_1**: Do you already use [variable substitution](https://docs.docker.com/compose/compose-file/compose-file-v2/#variable-substitution) in your compose files? If they really are "embarassingly similar", that might be an option.  

---

## 2 answers

### Answer by username_2 on 2017-10-03. Score: 3 | Accepted answer

One could use the same docker-compose file for dev, test, acceptance and production (DTAP) systems. Things that deviate per environment, e.g. passwords could be defined in an .env file.

If .env files are not a solution for some reason then one could create different docker-compose files, e.g. docker-compose.override (dev), docker-compose.test, docker-compose.acc and docker-compose.prd.

I personally prefer the first option, e.g. using .env files and a docker-compose.override for dev.

> **Comments:**
> **username_3**: Although this answer already has some years on its shoulds, coming by it just now and seeing that it's the accepted answer I just want to add: Before you consider running docker-compose in production, think about running even a 1-node swarm so you have access to the "deploy" key in your docker-compose file. Compose itself was really not meant to run a prod environment.  

---

### Answer by username_4 on 2017-10-04. Score: 1

[SaltStack](https://saltstack.com/) is great at generating these kinds of files based on metadata you feed to it via "pillars" as Salt itself uses YAML files heavily. Salt uses a [Jinja templating engine](http://jinja.pocoo.org/) (though others are also available).

Similarly, [Puppet](https://puppet.com/) also uses YAML heavily and is able to do the same using an [ERB](https://docs.puppet.com/puppet/5.3/lang_template_erb.html) template.

If you find that some of this metadata are things like a listening IP address or a hostname, these systems automatically generate variables such as this using [facter](https://docs.puppet.com/facter/) facts or salt [grains](https://docs.saltstack.com/en/latest/topics/grains/) respectively which can further reduce the amount of metadata you need to suply.

[Chef](https://www.chef.io/chef/) is probably also capable of this, though I am not familiar with that configuration management system.


---

