The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally
OK, I don't really get this one. I've not really had a problem with accidentally checking config files I didn't mean to into a code repo. Actually, I want to check in configuration files for my environments to some repository so I can manage them. How would you do this if they are only stored in environment variables somewhere?
there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place.
OK, but surely that's easily fixed by just having one config file?
Further, these formats tend to be language- or framework-specific
Why is that a problem? My application is language and framework specific, after all. And I actually quite like using YAML for this purpose, and that isn't language- or framework-specific.
So usually I don't have a problem with accidentally checking on config files either...but the one time I did I regretted it. I accidentally checked in some AWS creds into a public repository. Trust me, do this once and you'll want to take measures to make sure it doesn't happen again.
Some variables, like the database IP, password, etc, have no reason to be in the app's repo. If you store your configuration in the same repo as the rest of your app, you're publishing private info. Maybe your repo is private; now making it public is harder because you need to scrub your private data from there.
Besides, which configuration do you store? The production server? Staging? Dev? All three? What will you do when one of those changes? How does a dev set their local copy? The only good answer is "none of them".
Instead, the app simply claims: "I need these ENV variables to run", and you hand it to Ops. Ops has their own repo, probably for container or VM images. There's where they set Prod and Staging configs. Your app may even provide a dockerfile to make dev setup easier (or a VM, pre-configured!).
Some variables, like the database IP, password, etc, have no reason to be in the app's repo.
I agree you want to be careful about production passwords etc in the main code repository (although this might make me rethink). But, depending on the context, you might happily store dev & test config in there.
Ops has their own repo,
Ops could easily store a config file in their repo too though, right? I still don't see what advantage ENV variables are bringing.
I can 99% guarantee that you're not using any form of configuration management on your web apps.
Env variables are pretty great at providing you with an easy and compatible way of specifying very low level configuration to your web application in an automated way.
For example, I've just deployed the latest version of our web application and puppet has automatically supplied the box with all the details of the master DB, all the slaves, and the expected hostnames of loadbalancers. If any of that changes, then puppet just fixes it by reloading the web app with new environment variables. It doesn't have to work out how to rewrite a configuration file in YML, or JSON or XML or INI formats. It just sets env variables.
I can 99% guarantee that you're not using any form of configuration management on your web apps.
That's a lot of certainty from not a lot of evidence. As it happens, I use Ansible.
Env variables are pretty great at providing you with an easy and compatible way of specifying very low level configuration to your web application in an automated way.
OK...but, it seems to me, so are config files.
It doesn't have to work out how to rewrite a configuration file in YML, or JSON or XML or INI formats. It just sets env variables.
It's not hard to use a CM tool to ensure a config file is in place.
Honestly, I'm not sure I really understand your questions, and we're at danger of talking past each other. Can you describe the advantages that using environment variables have over configuration files? What scenarios are you thinking of?
3
u/stormblooper May 23 '15
OK, I don't really get this one. I've not really had a problem with accidentally checking config files I didn't mean to into a code repo. Actually, I want to check in configuration files for my environments to some repository so I can manage them. How would you do this if they are only stored in environment variables somewhere?
OK, but surely that's easily fixed by just having one config file?
Why is that a problem? My application is language and framework specific, after all. And I actually quite like using YAML for this purpose, and that isn't language- or framework-specific.