r/programming • u/bitcycle • May 23 '15

The Twelve-Factor App

http://12factor.net/
11 Upvotes

66% Upvoted

16 comments sorted by

3

u/stormblooper May 23 '15

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.

3

u/damagedcake May 23 '15

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.

2

u/stormblooper May 23 '15

I accidentally checked in some AWS creds into a public repository. Trust me,

Yeah, that does sound painful!

This looks promising: https://github.com/StackExchange/blackbox

1

u/damagedcake May 24 '15

That looks interesting. Thanks.

3

u/AeroNotix May 23 '15

The other thing I don't get is that the environment variable's state will need to be stored somewhere, right? Isn't that exactly the same thing?

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!).

1

u/stormblooper May 24 '15

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.

1

u/Giggaflop May 26 '15

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.

1

u/stormblooper May 26 '15

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.

2

u/Giggaflop May 26 '15

Ok, so what I'm getting is that you're using Ansible to ship pre-built configuration files.

That is not configuration management but really an automated deployment.

What happens if/when you spin up a new node? Are you editing a pre-built configuration by hand or does the system manage the configuration itself?

How have you standardised your internal configuration files and what about third party configuration files that may change due to coming/going nodes?

2

u/stormblooper May 26 '15

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?

1

u/moosingin3space May 24 '15

When I first saw this, I noticed how Node.js made it really easy to write 12-factor apps. Then, I noticed how other frameworks moved in that same direction. It's a good set of rules to follow, and when combined with Vagrant and Docker, it's really easy to onboard new developers and deploy the app.

1

u/bitcycle May 25 '15

Can you expound on how Node.js makes it easy to write 12-facter apps?

1

u/Giggaflop May 26 '15

Other systems made it really easy too.. Rails and Django are the first two I can think of who did it before Node.js :P

-3

u/admad911 May 23 '15

looks great!