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

41–50 of 296 posts

Re: Don’t use environment variables for configuration

#41

Post by j1elo »

RBerenguel wrote: post #18
j1elo wrote: 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.

Yes, that was my point actually, although I might have expressed it poorly:

The article says that one problem of using env vars is that you might set it for one run, but then forget to set it for the next one. This could be problematic if the program is stateful. So I wanted to make the passing comment, while talking about containers, that a container will "remember" the initially set env vars, so if you stop and start the process, the variables would persist across executions.

Re: Don’t use environment variables for configuration

#42

Post by RBerenguel »

j1elo wrote: post #41
RBerenguel wrote: post #18

Earlier quoted context omitted.

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.

Yes, that was my point actually, although I might have expressed it poorly: The article says that one problem of using env vars is that you might set it for one run, but then forget to set it for the next one. This could be problematic if the program is stateful. So I wanted to make the passing comment, while talking about containers, that a container will "remember" the initially set env vars, so if you stop and sta…

Indeed, that's actually an awesome feature because guarantees the container will work as it was running upon a restart.

Problem is when you have an environment variable you want to change for some reason without triggering a redeployment/release/whatever, with a configuration file in a volume you can change it and restart (of course this breaks the premise of "restart keeps full state", but I can live with file modifications, with docker at least you can keep them at least "triggered externally"). With an environment variable the only option I have found is stopping docker, digging into the container configuration, changing said variable and starting docker again (lovingly called "Indy swap" when we've had to do it, luckily it's less than once a year).

Re: Don’t use environment variables for configuration

#43

Post by yokaze »

kerny wrote: post #39
mrkeen wrote: post #37

Earlier quoted context omitted.

Any third party code in our system can just read whatever's in the environment and POST it to some remote server.

Any third party code can just read your credentials file and POST it to remote server.

File permissions allow finer granularity of access control. Environment variables are visible to any user in the system.

Re: Don’t use environment variables for configuration

#44

Post by fps_doug »

yokaze wrote: post #43
kerny wrote: post #39

Earlier quoted context omitted.

Any third party code can just read your credentials file and POST it to remote server.

File permissions allow finer granularity of access control. Environment variables are visible to any user in the system.

Unset them after right after evaluation.

Re: Don’t use environment variables for configuration

#45

Post by nyanpasu64 »

IMO, the author is writing from the perspective of Meson, a command line build tool used by individuals that takes arguments and caches them in a per-project file, whereas most of the negative replies are commenting from the perspective of sysadmins deploying software into homogeneous servers or Docker containers. Would make be a better program if MAKEFLAGS was not an environment variable? (IDK.) Would Git be a better program if the project directory was passed as an argument rather than as inherited state (the cwd)? (IDK.) Would less or nano be a better program if file paths were passed in as environment variables rather than arguments? (no.)

Re: Don’t use environment variables for configuration

#46

Post by mrkeen »

kerny wrote: post #39
mrkeen wrote: post #37

Earlier quoted context omitted.

Any third party code in our system can just read whatever's in the environment and POST it to some remote server.

Any third party code can just read your credentials file and POST it to remote server.

That's not where the credentials are stored.

Re: Don’t use environment variables for configuration

#47

Post by Aeolun »

nyanpasu64 wrote: post #45

IMO, the author is writing from the perspective of Meson, a command line build tool used by individuals that takes arguments and caches them in a per-project file, whereas most of the negative replies are commenting from the perspective of sysadmins deploying software into homogeneous servers or Docker containers. Would make be a better program if MAKEFLAGS was not an environment variable? (IDK.) Would Git be a bette…

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

Re: Don’t use environment variables for configuration

#49

Post by nickjj »

RBerenguel wrote: post #35
jpgvm wrote: post #28

Earlier quoted context omitted.

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.

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 control over being able to run the container with whatever command I see fit.

And in cases where I have no control over how things are run (like Heroku), environment variables still work because a ton of hosting platforms expect you to set and read them for various configuration.

And you can also commit an example env file to git with no secrets so developers can `cp .env.example .env` to get going in 1 second.

The environment variable pattern is incredibly standard in the world of web dev.

Re: Don’t use environment variables for configuration

#50

Post by junon »

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

Post reply on HN