12factor config approach with Docker

Question

Is there yet any native or commonly-accepted approaches to using environment variables to control Docker behaviour, i.e. in a 12factor manner?

The only language-agnostic method I've seen is to pollute the docker run command with -e variables. The most maintainable solution I've seen is using a combination of cat and sed to generate the CLI parameters using a .env file: https://twitter.com/DataKyle/status/422843345120296960

We currently use Vagrant for dev, a CI/CD hosted provider for test and deploy, plus AWS Elastic Beanstalk as the Staging and Production PAAS. Our app has over 100 configurable parameters, most of which are set to defaults, but each environment still needs to customise around 10-20 of those. It just seems too hacky to be running docker with a huge list of command-line variables like that.

Further, it doesn't allow you to take variables from the docker host (such as the CI provider's pre-installed Redis or Postgres credentials), without a further hack.

Is there a solution to this I haven't found? Or is this a missing piece for Docker? Or is this somehow philosophically against the Docker philosophy?

Answer 1

Docker 0.10.0 and newer (Apr 8, 2014) accepts docker run --env-file <filename>, which lets you feed docker's running environment with .env-like files.

Moreover, you can let dockers to interact further: --volumes-from can mount all volumes from the referenced container, and --link lets the container know the details of the referenced container's exposed ports.

While the Docker run reference is a bit weak at the moment, you can find all the details in the CLI reference's run section, as well as the container linking reference.

As of what to start from the container. Usually I recommend starting a shell script, which sets default environment variables (along the lines of : ${ENV:=default_value}), exports them, then execs a single executable. This executable can be the desired application in the foreground, or an init replacement like runit or supervisord.

I wouldn't recommend running sshd inside your docker, if it's not part of the system (for example, a container for gitlab should contain sshd, as it provides git repo access through ssh). For maintenance or debugging purposes I recommend using nsenter instead.