Hacker News new | ask | show | jobs
by kylequest 4373 days ago
I wouldn't call the part about configurations (in the post and in the 12 factor app reference) a best practice. Using environment variables is a hack that has negative side effects including security side effects.

This statement is just silly: "A good goal is that the application can be open sourced at any time without compromising any credentials." It's silly because the use of environment variables doesn't prevent anybody from putting them in a shell script that gets committed to git...
2 comments
curun1r 4372 days ago
I think they made a mistake by making the "gets configuration parameters from the environment" specific to a UNIX/system environment. You can accomplish the same effect in a much more elegant manner using a tool like etcd or consul.

But the important part is really that the deployable unit pulls its configuration from the environment where it's deployed. There are a ton of ways to accomplish this...environment variables are one way, etcd/consul is another, you can use something language-specific like JNDI or you can even use a file with configs in a well-known location, but you really need to be deploying the same artifact to QA, E2E testing, production and whatever other environments you might have.

link
njharman 4373 days ago
You're reversing the "goal" and "practice". It's not that Environment Vars allow you to "open source / credentials".

It's (goal) "be able to open source any time without compromising any credentials". One method (practice), use Environment Vars. Evars being a poor choice in your and somewhat my opinion, does not translate into the goal being poor. It's a laudable goal.

link
kylequest 4373 days ago
Being able to open source code without compromising any credentials is a great goal, but using environment variables doesn't really accomplish it UNLESS your code only runs on a PaaS, which will always supply all of your app's env vars, but it's unrealistic for a number of reasons.

First, there'll be extra vars that your PaaS won't fully manage, so you'll have to keep track of them yourself and then later configure the PaaS environment, so your app can access them. Second, for non-PaaS applications/deployments you still need to manage the environment variables.

The variables don't magically appear by themselves :-) They need to be stored somewhere... This "somewhere" is likely to be the git repo (for the app), so you are back to square one on this.

link