3 ms·

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

by q3k 6y ago

> 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 of seeming the simplest and most pragmatic solution at first, but becoming a an untyped, underdocumented hairball after some time in more complex software. Furthermore, as long as environments have existed in UNIX and UNIX-like derivatives, their usage to configure the bulk of the behaviour of most services/programs are relatively new. The more old-school the service you deploy somewhere, the more likely it has a file-driven config. Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files.

emodendroket 6y ago
Sure, but everyone understands that option and knows the pitfalls. This is kind of the core of the “worse is better” mindset, which somehow seems to have disappeared from the collective consciousness even though Unix is bigger than ever.
bayindirh 6y ago
> 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 language has nice config file libraries out of the box. Instead these variables are added as a convenience feature for some frequent scenarios where tool needs to adapt itself to the environment it needs to run in, just before starting or needs to be run repeatedly with small, transient changes to the config. > Furthermore, as long as environments have existed in UNIX and UNIX-like derivatives, their usage to configure the bulk of the behaviour of a service/program are relatively new. 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. The reason for that the variable had a great deal of effect in the behavior of the program (which was generally scientific) and making multiple runs without modifying a file very effective. You need these runs to conduct research BTW, and you're on a cluster and jobs run long and whatnot. TBH, most of these applications also had configuration files or "sensible defaults" and they either created their default files if there was none. And if there was a file, the environment variable was acting as an override. So I had experimental software, fixed most of the parameters in the file and tried some other things by overriding some parameter(s) with an environment variable. Nothing was abused or misused. > Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files. 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.
- q3k 6y ago
  > 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.
  - bayindirh 6y ago
    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 https://news.ycombinator.com/item?id=26660409
ekimekim 6y ago
> 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.
- GoblinSlayer 6y ago
  For automation you will store them in a file anyway, but then how is it different from a bind mount?
  - KptMarchewa 6y ago
    More usually, in k8s configmap.

by q3k 6y ago

emodendroket 6y ago

Sure, but everyone understands that option and knows the pitfalls. This is kind of the core of the “worse is better” mindset, which somehow seems to have disappeared from the collective consciousness even though Unix is bigger than ever.

bayindirh 6y ago

> 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 language has nice config file libraries out of the box. Instead these variables are added as a convenience feature for some frequent scenarios where tool needs to adapt itself to the environment it needs to run in, just before starting or needs to be run repeatedly with small, transient changes to the config. > Furthermore, as long as environments have existed in UNIX and UNIX-like derivatives, their usage to configure the bulk of the behaviour of a service/program are relatively new. 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. The reason for that the variable had a great deal of effect in the behavior of the program (which was generally scientific) and making multiple runs without modifying a file very effective. You need these runs to conduct research BTW, and you're on a cluster and jobs run long and whatnot. TBH, most of these applications also had configuration files or "sensible defaults" and they either created their default files if there was none. And if there was a file, the environment variable was acting as an override. So I had experimental software, fixed most of the parameters in the file and tried some other things by overriding some parameter(s) with an environment variable. Nothing was abused or misused. > Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files. 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.

q3k 6y ago
> 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.
- bayindirh 6y ago
  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 https://news.ycombinator.com/item?id=26660409

ekimekim 6y ago

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

GoblinSlayer 6y ago
For automation you will store them in a file anyway, but then how is it different from a bind mount?
- KptMarchewa 6y ago
  More usually, in k8s configmap.