1

I really like the ideas behind the Twelve Factors Manifesto. I am trying to apply them to a small microservice-style deployment for a Python/Django project. The Django project is packaged in a Docker container which is deployed via Docker Hub.

The one thing that I am trying to understand is how to deal with configuration files and environment variables. The common wisdom of 12 factor apps is that configuration should be stored as environment variables, and not in source control. I am thinking of implementing this using django-environ which checks the environment variables, and also a .env file for use in dev.

How do I set these environment variables in production, then?

  • In Docker, it is possible to declare environment variables as ENV in the Dockerfile (doc). So I can add this information there, but I check in the Dockerfile with the source code, so this would defeat the purpose.
  • I could create an additional .env file for production, and not check it into source control. I can copy this production .env file while building the image using the COPY command. But this means the developer will have access to the DB credentials.
  • Set up a custom build trigger, so that when the code is updated in the source control, a build trigger is issued. When the image is being built, this building node adds this .env file, and deploys to the server.

I feel like the third option is the only one that makes sense. But even in that case, the config items are still stored in a file, and not really in environment variables.

Any ideas how to go about this?

user1496984
  • 10,957
  • 8
  • 37
  • 46
  • When using docker containers in general, the workflow is passing the environment variables in the docker command, such as `docker run -e FOO=bar image`. Alternatively, you can read these from a file passing `--env-file file`. Also, I believe a custom build trigger would violate the wisdom as well, since you would have hard-coded the cnofiguration variables in a docker image. This also holds for the `COPY` command. Another possibility would be mounting a configuration file, but this should only be done if using environment variables is impossible. – Lukas Juhrich Oct 27 '15 at 18:24
  • See also http://stackoverflow.com/questions/25177402/12factor-config-approach-with-docker?rq=1 – ebullient Oct 29 '15 at 12:36
  • @Luke You mention as the last possibility that mounting a configuration file should be the last option. After doing some more reading about this, I am under the impression that that should be the best option, no? Have a `.env` file on the host, and mount that to the Docker imagine such that Django picks it up? – user1496984 Nov 03 '15 at 15:33
  • @user1496984 don't confuse using `.env` files with mounting configuration files! `.env` files (used via `--env-file`) are just a kind of “shorthand notation” for passing environment variables, while mounting a configuration file is actively adding something to the docker container (i.e. its filesystem). Using environment variables is the better (cleaner) option, since you leave the container itself untouched, and besides, that's what they are there for – providing information about the environment, i.e. with which parameters the app should be used. – Lukas Juhrich Nov 04 '15 at 00:12

0 Answers0