Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t use environment variables for configuration

nibblestew.blogspot.com

Post reply on HN
Print view View original

141–150 of 296 posts

Re: Don’t use environment variables for configuration

#141

Post by miloignis »

Clearly we shouldn't use environment variables for everything - I agree with the do-it-in-layers comments of others - but I was compelled to point out he's got it exactly backwards. He suggests that environment variables are mutable global state, when they're not, then suggests actually mutable global configuration files. Surely in his scheme about adding numbers this is equivalent to setting the numbers to add in an entirely different source file!

Environment variables, on the other hand, are more like lexical scoping - you can shadow them, spawn a new shell with copies of them, override them for a single invocation and then have them go back, etc.

Re: Don’t use environment variables for configuration

#142

Post by hjek »

junon wrote: post #50

Oh this guy again. This guy created Meson and has a pattern of being 1) Quite toxic and 2) Entirely dogmatic when it comes to software design. He shows no interest in discussing design problems with Meson and asserts his viewpoints as truth and fact, resorting to snide comebacks instead of having thoughtful conversation. Doesn't surprise me he wrote an article like this. Completely misguided and isn't rooted in reali…

Okay, so when you write that this blog author, who made a post arguing how environmental variables are global mutable state, is quite toxic and resorting to snide comebacks instead of having thoughtful conversation, then that is just you engaging in thoughtful conversation about the issue (which is envvars), and not you making a toxic ad-hominem attack at all, right?

Re: Don’t use environment variables for configuration

#143

Post by hjek »

tedk-42 wrote: post #7

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

> Author [...] probably hasn't deployed something to a 'production' environment

I think you're wrong about that. The blog post author is also author of Meson, the build system.

Re: Don’t use environment variables for configuration

#144

Post by ajarmst »

This attitude is how we ended up with Active Directory. One assumes that the author doesn't spend much time in a command-line environment. The option to set defaults for one's normal working environment is obviously of value, and environment variables are hardly exclusive of configuration files (~/.bashrc, makefiles, ...). The theory that complex syntax and statelessness are inherently good and cost-free is naïve to the point of parody.

The author is correct that "this is the way we have always done it" isn't a good argument in and of itself to persist in a practice. However, they might be rewarded by a few minutes pondering a related idea: "if generations of people---many quite capable of modifying the system to use something else---persist in using something, it's possible they have a reason for doing so other than a deficit in competence or imagination."

Re: Don’t use environment variables for configuration

#145

Post by yrro »

bopbeepboop wrote: post #139
yrro wrote: post #131

Earlier quoted context omitted.

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

How do command line arguments or config files solve either problem?

Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials.

Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. And for the same reason, a child process that does the same won't inherit them in order to expose them.

Note that talking about preventing accidental exposure of credentials. Config files alone can't protect credentials from a malicious process that deliberately goes looking for them to leak them; for that additional measures have to be taken... but environment variables aren't part of the solution!

Re: Don’t use environment variables for configuration

#147

Post by barbazoo »

> For comparison using JSON configuration files this entire class os problems would not exist. Every application would read the data in the same way

The issue they mentioned earlier remains, as it's not specific to env vars. What if you don't supply a config file?

> The environment is now different. What should the program do? Use the old configuration that had the env var set or the new one where it is not set? Error out? Try to silently merge the different options into one? Something else?

I'm really not a big fan of using env vars for configuration but there are cases where it's a good choice, for example running docker compose and passing a .env file that becomes the configuration for the container.

I agree that it's not a very good way to configure an application in a "shared" environment. For instance, I'm not a fan of curl reading my HTTPS_PROXY env var and implicitly using that value. That should be controlled exclusively by a cli switch imho.

Re: Don’t use environment variables for configuration

#148

Post by ekimekim »

q3k wrote: post #88
bayindirh wrote: post #76

I have a pet peeve about this attitude. These methods are being used for decades and well understood with all their advantages and disadvantages. One day, someone comes and tells that it's bad and considered harmful , and happily tells the only right way to do it . A flame war ensues then. I'm all for moving things forward and evolution, but can't we take a milder stance and move forward in a more peaceful way? Attac…

> That thing wouldn't be a de-facto standard if it was too bad, right? I disagree. Very often, the 'easiest' option wins, not the one that necessarily is the 'best', especially in the long term. Environment variables for configurations are fast and easy, and work well on the happy path - but break down quite fast when dealing with more complex cases (eg. more complex types than strings). They have a treacherous way o…

> Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files.

This is a consequence of Docker's choice of the "image" as an abstraction layer. It's not trivial to say "run this image but with this config file added" (yes you could bind mount one in, or create a new derived image, but those are both harder and come with more pitfalls).

In most common docker usage, there are exactly two ways to influence the operation of the program contained within the image: Environment variables, and command line arguments.

Re: Don’t use environment variables for configuration

#149

Post by josephorjoe »

kmstout wrote: post #95

I was taught many moons ago that configuration, like ogres and onions, is best considered in layers: 1. default values: What will most users in most places find most useful/least infuriating? 2. configuration files (system-wide, then user): What will most users on this system want most of the time? What will this particular user want most of the time? 3. environment variables: How should this session (i.e., a potenti…

yeah, i don't get too worked up about "how" config values enter the application as long as i can easily see "where" they are initialized/validated.

an immutable config object/class created on startup that reads files/env vars/whatever and has appropriate assertions to ensure good values were used and crashes the app for missing/bad values usually keeps things sane.

an app where each subcomponent has its own config that it gets in its own way usually leads to confusion and delay

Re: Don’t use environment variables for configuration

#150

Post by intrepidhero »

yrro wrote: post #131
zajio1am wrote: post #106

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell). Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go. There are two realistic alternatives - confi…

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

Isn't storing credentials in environmental variables bad practice to begin with?
Post reply on HN