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

111–120 of 296 posts

Re: Don’t use environment variables for configuration

#111

Post by q3k »

bayindirh wrote: post #94
q3k wrote: post #88

Earlier quoted context omitted.

> 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…

> I disagree. Very often, the 'easiest' option wins, not the one that necessarily is the 'best', especially in the long term. Thank you for your disagreement and discussion, honestly. Actually, I think using environment variables are a burden. Needs more documentation, more explicit warnings, a lot of handling, etc. So, environment variables are not the easiest way out there. Especially when almost any programming la…

> This is not what I see in my career. Bulk of the applications we installed and ran used some forms of environment variables for runtime configuration of the tool/application.

I think we might have different backgrounds and considerations as to what counts as 'oldschool'? Maybe I shouldn't have extrapolated this to pre-2000... So, my experience comes from working with the following 'mood' of services:

  Postfix, Exim, qmail, slapd, PostgreSQL, MySQL, FreeRADIUS, Apache, Nginx, ...
All of which have their own config file/files, format, etc. All of these system-wide services, not user applications. And I think that's the main difference? I tend to deal with software that is deployed in isolated environments, be it by root users on production server, or by whoever in a containerized environment. And not deployed on an interactive systems, to then be started/reconfigured by users running on the same system.

> I've never seen it TBH, and if that's not documented well, it would be a big bag of fun for the users of that code.

Check out the list above on Dockerhub. I'm not sure all of them are dockerized in this way, but at least a handful of them are.

Re: Don’t use environment variables for configuration

#112

Post by RBerenguel »

nickjj wrote: post #49
RBerenguel wrote: post #35

Earlier quoted context omitted.

That's not what I'm saying, what you mention can be done indeed. What I say is that if you are in a machine with an already running docker container, one you don't have the corresponding `run` command of (i.e. you _can't docker run_ for whatever reason), changing the environment variables of that container is tricky.

You could always run the `env` command inside of the container to get all of the set environment variables. Then you can define, reconstruct and run your container with whatever args you want. But yeah the env_file approach is the way to go here. I've been using Docker in production since 2015 and never ran into your use case. I always had an .env file ready to go that was loaded in with env_file and always had contr…

I have been using Docker in production since 2015 as well, and I've had to do this more than once. To each their own.

Re: Don’t use environment variables for configuration

#113

Post by nyanpasu64 »

maccard wrote: post #73
Aeolun wrote: post #47

Earlier quoted context omitted.

> a command line build tool used by individuals that takes arguments and caches them in a per-project file That is literally one of the worst ideas I’ve ever heard of. And I’ve heard many bad ideas recently.

What's the alternative? That's how make, cmake, msbuild, ninja,docker, and basically every other build tool I'm aware of works

CMake does that and is a truly demented implementation, mixing user-specified initial state (supplied the first time you run CMake and carried on to future argument-less invocations), derived state, and cached compiler locations and versions in a single CMakeCache.txt file. Edit CMakeLists.txt? Time to delete CMakeCache.txt! Upgrade your compiler? Time to delete CMakeCache.txt!

I haven't used Meson all that much, but I recall it's a bit better than CMake but I still ran into a similar issue at one point.

Re: Don’t use environment variables for configuration

#114

Post by llimllib »

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…

(for default values, make sure you consider safety too! for example a debug option that might show PII is likely to be most useful to most people using the program, but shouldn't default to on because if it were on in prod the consequences would be serious)

Re: Don’t use environment variables for configuration

#115

Post by celeritascelery »

MrWiffles wrote: post #103

Or you could store your config as an environment variable in JSON, like Cloud Found does. I mean, JSON is really just one big string after all...

Now every program and script needs a full JSON parser and to all agree where this JSON is located in the system.

Re: Don’t use environment variables for configuration

#116

Post by zabzonk »

bayindirh wrote: post #108
zabzonk wrote: post #99

Earlier quoted context omitted.

> These methods are being used for decades and well understood with all their advantages and disadvantages. Just because something has been used for decades does not make it good - for example, avoidable mutable state. And it certainly does not make it well-understood - as a consultant the number of brain frying environment variable configurations I've had to deal with which no permies could tell me anything about de…

> Just because something has been used for decades does not make it good. I'm not calling this is good with the persistence of the original author. I tell that it's one of the realities that we have, and instead of burning it with torches, why not build better conventions around it with better attitude and language? Maybe we can try: "Instead of burying all config under environment variables, why not try doing it lik…

> "Instead of burying all config under environment variables, why not try doing it like this?", and slowly build something better, step by step

Use named files, that can be version controlled and documented, but are under direct access from the actual program and can be reported as an error if (for example) they are not found.

Re: Don’t use environment variables for configuration

#117

Post by hardwaresofton »

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…

My guess for this is that some people have not had the good fortune of seeing software that followed this pattern and how nice it is.

I thought it was common knowlegse that if really wanted to do configuration right on a given project, you do all 4 (with some library support) and you write your code to gracefully handle the right piece of configuration from the appropriate "override level" (again usually with the support of a good library).

See also: Domain Driven Design[0] which (if you ignore the consultant-fodder and jargon that comes with it) is probably one of the best written guides of how you should abstract systems, just like the gang of four book is a good introduction to structures in program/algorithm implementation you're likely to see in real life.

[0]: https://en.wikipedia.org/wiki/Domain-driven_design

Re: Don’t use environment variables for configuration

#118

Post by bayindirh »

q3k wrote: post #111
bayindirh wrote: post #94

Earlier quoted context omitted.

> I disagree. Very often, the 'easiest' option wins, not the one that necessarily is the 'best', especially in the long term. Thank you for your disagreement and discussion, honestly. Actually, I think using environment variables are a burden. Needs more documentation, more explicit warnings, a lot of handling, etc. So, environment variables are not the easiest way out there. Especially when almost any programming la…

> This is not what I see in my career. Bulk of the applications we installed and ran used some forms of environment variables for runtime configuration of the tool/application. I think we might have different backgrounds and considerations as to what counts as 'oldschool'? Maybe I shouldn't have extrapolated this to pre-2000... So, my experience comes from working with the following 'mood' of services: Postfix, Exim,…

I've further clarified my PoV here [0], but it won't hurt to reiterate. I'd be happy in fact.

> I think we might have different backgrounds and considerations as to what counts as 'oldschool'?

Most probably. All of the software you mentioned (maybe except Exim4) is actively used in our environments, quite a few of them are in very vanilla configs, and some of them are customized to the point of abuse. However, it's worth mentioning that all of the software you mentioned are in support roles in our scenario, they're the so-called side dish which we configure once and leave alone for a very long time.

> Maybe I shouldn't have extrapolated this to pre-2000...

I've started with a C64, please. :)

> All of these system-wide services, not user applications. And I think that's the main difference?

Yes, the tools I've talked about are userspace programs, and are not daemons 99.999% of the time. So you need to run it many times with small differences, and reconfiguring/regenerating file is a lot of work, but as I said, they all have configs and env variables are convenience overrides most of the time.

> Check out the list above on Dockerhub.

Will take a look, thanks. Wanted to learn docker in depth for a long time, but had no notable project to force me to use it. Maybe someday.

[0]: https://news.ycombinator.com/item?id=26660409

Re: Don’t use environment variables for configuration

#119

Post by lmilcin »

ben0x539 wrote: post #72
lmilcin wrote: post #32

Never trust an advice expressed in an absolute.

Well, infer that it's not absolute but rather ironically depends on the kind of environment you're developing software for. <:)

What I mean is that when an advice is expressed in absolute it tends to be a radical view on the problem.

Radicals tend to dismiss things that don't agree with their world view and I am always wary of this. And you should to. I don't mean radicals can't be right. What I mean is you should be cautious about it.

Post reply on HN