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.

  • Do you already use variable substitution in your compose files? If they really are "embarassingly similar", that might be an option.
    – Hexaholic
    Commented Jun 23, 2017 at 12:10

2 Answers 2


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.

  • 1
    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
    Commented Nov 12, 2020 at 10:06

SaltStack 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 (though others are also available).

Similarly, Puppet also uses YAML heavily and is able to do the same using an ERB 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 facts or salt grains respectively which can further reduce the amount of metadata you need to suply.

Chef is probably also capable of this, though I am not familiar with that configuration management system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.