Live data from Hacker News

Don’t use environment variables for configuration

nibblestew.blogspot.com

21–30 of 296 posts

Re: Don’t use environment variables for configuration

#21
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).

To be fair, "configuration" means a somewhat different thing when we're talking about a user application vs a server. It's easy to forget on HN that some software engineers don't write web servers at all.

Having used the profiling tool TAU (subtle dig), I instantly understood what the author is driving at, and I somewhat agree for many use cases. I shouldn't have to fill my dotfiles with 10 new variables just to use a utility.

Re: Don’t use environment variables for configuration

#22
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).

It looks like the author is talking about command line tools that use env vars for things that should be arguments. In the comments on the page he admits that for example key credentials are valid usages for env vars.

Re: Don’t use environment variables for configuration

#23
I wish there was wider adoption of configuration services. Something like Enovy xDS protocol, but for general configurations.

Puppet & Co did it to some extent, but for the whole server. On boot it asks centralized service for a configuration, providing just server identity and some basic attributes (datacenter, rack, stage) and receives full server configuration. Implementing this pattern for a service itself, would make it easier to configure swarms of services.

I experimented with using Open Policy Agent, where it dispatches exact configuration based on client identity and quite liked the result. Only downside is that it requires polling.

Re: Don’t use environment variables for configuration

#26
post #6

I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…

I came here for this comment. I'm a developer and I have been using env vars for quite some time after I got burned numerous times by other options. I just can't see why I would use anything else.

Re: Don’t use environment variables for configuration

#27
"This is the way we have always done it so it must be correct!" != "This is the way we have always done and it works perfect for everybody!"

I want to use env vars because:

* I want to reuse builds and my systems have different behavior on different environments.

* I want to override the default config sometimes

* I don't want to expose sensitive configurations, and yet have them explicitly configure in my project configuration

The post it's very opinionated and lacking any valuable point IMO.

Re: Don’t use environment variables for configuration

#28
post #9

I 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.

You don't need to modify the Dockerfile to change environment variables at runtime.

Also if you specifically want to modify a file and re-run the container look at --env-file arg to docker run.

Re: Don’t use environment variables for configuration

#29
post #12
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).

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'.

Well, sure, you shouldn't be putting secrets or other sensitive data in environment variables. But garden-variety configuration is fine to put in env vars. Seems like whoever assigned you this task didn't really know what they were doing.

Re: Don’t use environment variables for configuration

#30
> Environment variables is exactly this: mutable global state. Envvars have some legitimate usages (such as enabling debug logging) but they should never, ever be used for configuring core functionality of programs

Doesn’t matter where configuration lives, the name itself suggests that it is by definition global mutable state, I mean that’s the whole point of it.

And it doesn’t matter if it’s used to configure core functionality (e.g feature toggles) or secondary functionality. The whole purpose is to do exactly that :)

Post reply on HN