2

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 Jun 23 '17 at 12:10
3

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.

0

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, privacy policy and cookie policy

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