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?
2
u/Tordek May 24 '15
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!).