This flies in the face of pretty much every opinion I've heard from experienced developers in the past 5 years. Once someone said, "You should be using ENV for configuration" I started doing it, and I found it to be a better solution than I previously had. I am also open to dedicated config files, whether they set ENV vars or not.
I'm open to the idea that ENV is not the only way, and I certainly believe that there are situations where other solutions are warranted, but my opinion right now is that this is wrong, and I perceive this also to be the prevailing opinion in our industry.
Yes. If you package software up for deployment on some server (i.e. you use something like Docker), environment variables are the easiest/only configuration mechanism at your disposal. Packages that don't support this, need some workarounds (e.g. dockerize to template some config file using environment variables) to be packaged up; which is annoying and extra work. Decent server software comes prepackaged in docker form these days. Which means environment variables are the way you control those unless you want to force your users to create their own docker containers just so they can fiddle with config files, which is a bit user hostile.
Dedicated configuration files only make sense if you assume a writable file system is there. Which is a broken assumption on many containerized environments. There is a lot of legacy software that works that way of course. Some software allows doing configuration via config files and then allows overriding keys in those files with some naming convention via environment variables. That's a good compromise since that allows you to package up sane defaults that you override as needed via the environment. It does not have to be an either or type thing.
Another common pattern is to allow overriding configuration via commandline arguments, which you can then gather in an environment variable and inject via docker. I do this a lot with JVM based software where we have a lot of -D options to override specific configuration value defaults via docker. Less clean than just having dedicated environment variables in the docker file but it works.
> Dedicated configuration files only make sense if you assume a writable file system is there.
I disagree. It's pretty typical in containerized environments (in my experience) to pass in (eg. mount) a config generated by whatever configuration management system into a container for it to load its configuration from.
This has the following advantages over env var configs:
- support for more complex expressions than string -> string maps (eg., configuring an IP blocklist)
- less chance of mistakes stemming from typos (eg., 'FOO_LODGIR' instead of a 'FOO_LOGDIR' in an environment variable will likely be silently ignored by a service, while a 'lodgir' key in a config file will cause an error in most serious config parsers that I've seen)
- working against a schema - if you use something like openapi, json-schema or protobuf/prototext to define your config format, you can use this schema to check/generate the config from other code, and even use it as an automatic source of documentation for the configuration format
- hot reloads of configs - once started with env vars, the env vars cannot be (easily) changed, while files can easily
be changed (on mutable FS, or from an external source like ConfigMaps/Secrets in k8s), watched and reloaded from, or even used as a signal that the software should restart
I'm open to the idea that ENV is not the only way, and I certainly believe that there are situations where other solutions are warranted, but my opinion right now is that this is wrong, and I perceive this also to be the prevailing opinion in our industry.