5

I just moved into the Ruby on Rails world and with it I am being introduced to much more liberal use of environment variables than what I have been exposed to in the past. Specifically, it appears like there's an accepted convention to store third party API keys and secret tokens as environment variables.

NOTE: this is not a RoR-specific question. I only mention it to illustrate a point of view.

I certainly see the benefit of this approach; the largest of which is that one codebase can be identically deployed to multiple servers without changing code or fear that the the app will be using the wrong resource. However, I am wary about jumping on the band wagon.

First, the approach doesn't seem scalable on my development work station (laptop), or on servers. If I am working on 10 different websites, and each are using Amazon S3 (for instance), I need 10 different EVs. Management will be difficult:

  • naming collisions are a distinct possibility (especially if I am working on legacy projects that I dont have complete control over);
  • visibility is murky (which EVs exist on the target machine? which have been or can be decommissioned?);
  • no version control (who changed the EV? when? why?)

Second, one of the main selling-points as I understand it, is that using EVs takes the sensitive data out of the repository where prying eyes could see it. This only seems like it should be an issue for public repositories, which I have none. All my repos are private, often because of contractual issues like NDA or ownership rights.

How does all of this play out in real life scenarios? Is this approach better for some situations than others? Are there other pros that outweigh my concerns here?

3

Environment variables are a set of key/value pairs for configuring... the environment (meaning things that pertain directly to the operating system, such as shared folder locations, for example).

As an application configuration tool, I've never been a big fan of environment variables or registry settings, preferring configuration files for all of the same reasons you have already stated.

Configuration files give you:

  1. Complete control of the format used to store the settings
  2. The ability to store objects, with the help of serialization
  3. The ability to store complex structures such as trees, etc.
  • Interesting answer; I've always held the opinion that all configuration is or should be environment-related. Externalizing anything is often (unintentionally) a way of circumventing the Continuous Integration and testing process. I don't necessarily agree with the RoR designers, but I think their approach of using environment variables may be a way of trying to prevent programmers from arbitrarily putting important business logic into configuration - in other words, "think long and hard before you decide that X should be soft-coded". – Aaronaught Oct 5 '13 at 18:02
  • I don't see how that wouldn't still be a problem in environment variables. – Robert Harvey Oct 5 '13 at 18:11
  • Environment variables can obviously still be abused, but by being harder to use they are also harder to abuse. Also consider that sysadmins will probably control the environment variables, not developers, so bad or unexpected configurations have an extra chance to get caught. Again, not saying that's the whole story or that it's some kind of panacea, but there is a certain logic to it. – Aaronaught Oct 5 '13 at 18:15
2

The environment variables should be stored in version control and managed with a system themselves. puppet, chef, etc are all designed to handle this and will avoid many of the issues you mentioned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.