Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-11-12T10:06:46.533Z
Answers: 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.
Answers: Worp
Answers: CC BY-SA 3.0
Answers: 2017-10-03T22:01:52.077Z
Answers: 2017-10-03T22:01:52.077Z
Answers: 030
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-04T15:28:59.763Z
Answers: 2017-10-04T15:28:59.763Z
Answers: James Shewey
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-06-23T12:10:58.663Z
Comments: 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.
Comments: Hexaholic
Tags: <docker-compose>
Title: Dynamic YAMLs for Docker Compose
UserDisplayName: Ta Mu
ThreadText: # 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.
  
  
  ---
  
  