The article is not against env vars per se as the title suggests. Instead it makes a case against undocumented features and improper use of env vars. It also complains about env vars being plain strings but fails to recognize config files are just plain strings without the appropriate parser. What stops anyone from putting JSON arrays in env vars?
Don’t use environment variables for configuration
11–20 of 296 posts
Re: Don’t use environment variables for configuration
#12Author doesn't know about https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' environment (or rather, doesn't know about separation of such environments in the first place).
I don't know about https://12factor.net either.
But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.
Re: Don’t use environment variables for configuration
#13This post seems to ramble without much substance.
The best argument, perhaps only valid argument, is lack of an array type. Easy to work around. The rest seems misguided or ridiculous.
>There is no way to know which one of these is the correct form
What? Of course there is.
The author is also calling it mutable global state, and seems to reference an application becoming confused when ENV isn't set. This reads to me, perhaps incorrectly, that the author doesn't understand that envvars aren't and don't behave like shared global variables. That is, changing one won't affect running applications.
Re: Don’t use environment variables for configuration
#14Maybe I live under a rock, but I feel like command line utilities taking environment variable arguments just isn’t that common of a practice? The only examples I can think of are when an argument is more of a “global variable” that many different commands may find useful such as JAVA_HOME, GITHUB_TOKEN, etc. For web applications and docker containers, environment variables fit easily into the deployment process and f…
Examples I've used in the past few days, from memory - along the lines of:
LC_ALL=C foo
PAGER=cat man ls
TZ=UTC date
Re: Don’t use environment variables for configuration
#15Easy fix (if it's the shared, mutable state which bugs you):
* Create one class responsible for ingesting env vars at startup.
* Call it from main, and abort early with nice messages if it fails to read something.
* Now you have a nice (preferably immutable) class which guarantees the config is in a 'good state', and is self-documenting because it lists all the keys it uses to lookup env vars with.
Re: Don’t use environment variables for configuration
#16Maybe I live under a rock, but I feel like command line utilities taking environment variable arguments just isn’t that common of a practice? The only examples I can think of are when an argument is more of a “global variable” that many different commands may find useful such as JAVA_HOME, GITHUB_TOKEN, etc. For web applications and docker containers, environment variables fit easily into the deployment process and f…
Examples I've used in the past few days, from memory - along the lines of: LC_ALL=C foo PAGER=cat man ls TZ=UTC date
These are good examples but I think these fit under my “global argument” umbrella. Imagine if every Linux command had a different argument name for the pager?
Re: Don’t use environment variables for configuration
#17Moving from tokenising files to end vars was one of the best choices I ever made. Life is sooooo much easier using env vars
Re: Don’t use environment variables for configuration
#18I could agree with "don't only use environment variables for configuration", but at the same time, by all means do use environment variables to allow for easy overriding of configuration . I cannot but think of the large number of times that being able to quickly override some parameter with an env var has helped me achieve something which was not exactly intended by the original author. Also, env vars are the most c…
Changing a variable of an existing container without recreating or re-running the docker run command is tricky, though. With a configuration file mapped to an external folder it's "just" modifying the file and docker restart, with environment variables it's somewhat more convoluted. I don't think it is as clear-cut as the title suggest, each kind of configuration has its place.
Re: Don’t use environment variables for configuration
#19After years of struggling with config file in heterogenous production environments, I'll argue the opposite: environment variables are the BEST option to manage your configuration.
Re: Don’t use environment variables for configuration
#20Mixed feelings about this. I strongly agree with some, but also feel it's missing the point in a lot of places.
Environment vars should of course not be used to configure specific programs. Having an environment variable to specify the args with which to call a program is needless complication. Just pass it as an argument. Use a configuration file to configure the program.
Environment variables should (only) be used to describe the environment. That should primarily be variables that transcend individual programs. Things like proxy settings are perfect for environment variables. (Well, almost; see below.) Perhaps the location of the configuration file, if that can vary per system (which it probably should be able to; hard-coded locations can also be a problem).
But even then, environment variables can fail. I noticed that some Azure/Kubernetes-related commands on my work Macbook need to run with the proxy on, and others with the proxy off, so I created aliases to enable/disable this environment variable, which completely defeats the purpose of the environment variable. Maybe I should be able to configure this proxy per application after all. Or at least configure whether to use or ignore the proxy settings. And then there are applications that ignore the proxy env var for whatever reason, and require me to configure it specifically for that one program, again defeating the purpose of environment variables (I think npm does this).
But when we deploy our application to different environments, our deployment configuration does set specific env vars so the application knows how to behave in that environment. It's what environment variables are for. But they're not a great fit. For example, we're currently in the process of migrating from AWS to Azure, and some things need to be enabled or disabled there. So we set some environment variable to 'false', except that environment variables are always strings, and in javascript, 'false' evaluates to true. Json configuration might actually make more sense here.
So I don't think we can or should do without environment variables, but I think I agree they're overused, and often used badly.