3 ms·

I actually had this question earlier today. Given a config file per 'environment', with environment being an arbitrary identifier, what benefit do environment

I actually had this question earlier today. Given a config file per 'environment', with environment being an arbitrary identifier, what benefit do environment variables have over it? I've read some docs on 12 factor apps looking for an answer but didn't really find anything. Just curious what I'm overlooking

jaysh 7y ago
As long as your (production) config files are not checked in with the code, then little difference. The challenge then is: where do you store them? Environment variables had the early upside of being first class in any virtually any deployment strategy - from Bash wrappers, supervisord to Docker and Kubernetes - so it's pretty much plug and play. For example, Docker has config files, but they're mounted to a specific place in your container, so that means your application is now married to that location.
manigandham 7y ago
Env vars are universally supported, globally available, and simple to manage. Files mean yet another deployment artifact that has to be stored somewhere, and now tied to a location. Sometimes that location is communicated through an env var, and that point why not just set all config that way?
- AlphaSite 7y ago
  If you have something like k8s it becomes trivial to use files vs end vars.
  - manigandham 7y ago
    How so? You still have to edit the file, save it somewhere, then mount it as a volume and agree on a location.
    - yencabulator 7y ago
      The configuration file can be inline in the yaml, ConfigMaps take care of shuffling bytes around for you, and for a specific app it's config can always be at a fixed path.
paulddraper 7y ago
Env vars are easy and ubiquitous. 1. Bash, Python, C, Java...super easy to access; no libraries needed. 2. They automatically propagate through shell scripts and worker processes. 3. They are also super easy to specify when starting programs, in shell, docker, child process from programming languages, Lambda functions, etc. 4. They can easily exist independently of other env variables on the same system. 5. The model is dead simple. Key-value. Simplicity is a feature. If you need to specify something complex (e.g. hundreds of tuned timeouts), consider using files or code for the heavy parts and env vars to select parts.
- lostcolony 7y ago
  Thanks! I had thought of about 3 of those, but they aren't really wins for most of my deployment environments (and some of the downsides still are major downsides for me; one thing I love about config files is I can provide a readme or schema in the same place to define what all the config params are and what they do). For #4, what do you mean? If running in a container it's not really an issue, but if I'm loading a couple of different dependencies/apps in the same container, or running without containers, name collisions have always been a concern. Set up a chroot, or start renaming things (i.e., "PORT" conflicts really quickly). Or are you saying supply them in the shell, or...?
  - paulddraper 7y ago
    > For #4, what do you mean? I mean that one process can have COLOR=blue and another can have COLOR=red with no conflict. PORT=123 COLOR=blue ./myapp PORT=456 COLOR=red ./myapp Yes you can chroot, run in containers, use only relative file paths, etc. There aren't any irremovable differences between env vars and files; env vars are basically /proc/ files with widespread runtime support.

jaysh 7y ago

As long as your (production) config files are not checked in with the code, then little difference. The challenge then is: where do you store them? Environment variables had the early upside of being first class in any virtually any deployment strategy - from Bash wrappers, supervisord to Docker and Kubernetes - so it's pretty much plug and play. For example, Docker has config files, but they're mounted to a specific place in your container, so that means your application is now married to that location.

manigandham 7y ago

Env vars are universally supported, globally available, and simple to manage. Files mean yet another deployment artifact that has to be stored somewhere, and now tied to a location. Sometimes that location is communicated through an env var, and that point why not just set all config that way?

AlphaSite 7y ago
If you have something like k8s it becomes trivial to use files vs end vars.
- manigandham 7y ago
  How so? You still have to edit the file, save it somewhere, then mount it as a volume and agree on a location.
  - yencabulator 7y ago
    The configuration file can be inline in the yaml, ConfigMaps take care of shuffling bytes around for you, and for a specific app it's config can always be at a fixed path.

paulddraper 7y ago

Env vars are easy and ubiquitous. 1. Bash, Python, C, Java...super easy to access; no libraries needed. 2. They automatically propagate through shell scripts and worker processes. 3. They are also super easy to specify when starting programs, in shell, docker, child process from programming languages, Lambda functions, etc. 4. They can easily exist independently of other env variables on the same system. 5. The model is dead simple. Key-value. Simplicity is a feature. If you need to specify something complex (e.g. hundreds of tuned timeouts), consider using files or code for the heavy parts and env vars to select parts.

lostcolony 7y ago
Thanks! I had thought of about 3 of those, but they aren't really wins for most of my deployment environments (and some of the downsides still are major downsides for me; one thing I love about config files is I can provide a readme or schema in the same place to define what all the config params are and what they do). For #4, what do you mean? If running in a container it's not really an issue, but if I'm loading a couple of different dependencies/apps in the same container, or running without containers, name collisions have always been a concern. Set up a chroot, or start renaming things (i.e., "PORT" conflicts really quickly). Or are you saying supply them in the shell, or...?
- paulddraper 7y ago
  > For #4, what do you mean? I mean that one process can have COLOR=blue and another can have COLOR=red with no conflict. PORT=123 COLOR=blue ./myapp PORT=456 COLOR=red ./myapp Yes you can chroot, run in containers, use only relative file paths, etc. There aren't any irremovable differences between env vars and files; env vars are basically /proc/ files with widespread runtime support.