4 ms·

In my experience, sourcing config from env variables seems like the best thing to do because you can completely ignore where the app is running in favor of inje

In my experience, sourcing config from env variables seems like the best thing to do because you can completely ignore where the app is running in favor of injecting whatever you want in any environment of your choosing and your app no longer needs to care about that. The implication is that business logic must not include the content of your config or where it is sourced from. It must simply use the values in the config. This way my apps could give less of a fart if I run it as a container in kube, in nomad, in local on localhost, in a devcontainer, in a directory with vars loaded using direnv, in vercel/netlify and so on. This also allows incredible flexibility in how that config is sourced as long as you simply dump them into the env vars. Want to load secrets from a .env file on local? Sure. Want to load secrets from Vault on production? Run a simple script to load vault secrets onto the env and run your app.

dalyons 3y ago
yeah this is the actual point - it makes the code/app totally portable & decoupled from config. I find it significantly better than having to have the app code choose different config based on interrogating facts about its runtime (eg am i in prod? use this value. am i in test? use this)
- twic 3y ago
  Everything you both wrote is spot on - but there's nothing about it which means you have to use environment variables! All of those mechanisms could be used with any other means of delivering the config at the point of process invocation - a config file, command line arguments, YAML to standard input, whatever. Personally, i would pick a config file over environment variables any day: easier to manually inspect and tweak, easier to give structure to, doesn't get implicitly passed down to subprocesses, can be secured with familiar file permissions, etc.
  - stackskipton 3y ago
    Problem with config files is you are forced to process it properly in pipeline so it can be delivered during deploy AND depending on your runtime environment, you might have to redeploy to change things. Environment variables exist on just about EVERY runtime, changed without requiring a pipeline run. However, subprocess is interesting but I've never run into subprocess that is not sharing a config. Where I worked, if you have subprocess that can't see those configs, you create a new service.
    - twic 3y ago
      I'm not sure what you're saying about pipelines. Ultimately, every app process is started by some manager. It's just as easy for that manager to create a config file as it is to set environment variables. If your point is that existing managers support setting environment variables but not creating config files, then sure. But that isn't a fundamental truth, it's just working with the tools you have.
      - aniforprez 3y ago
        Say you have a GitHub Action that pushes a container with your app and deploys to a Kubernetes cluster. Where is your config file going in this step? How do you inject that YAML/HCL/JSON file into the app to configure your app? It just seems far easier to have your kube config inject the env variables from your kube file and that way you don't have to worry during deployment how to add that file and you don't check it into the source. This applies to basically any way you deploy your app, especially containerised ones. Unless you're running your app in an EC2 machine where you can go in and easily edit the file (not that you can't do it in a container), it just seems like extra steps. I've found the happy medium to be sourcing default configs from a file that can all be overridden through env variables
        twic 3y ago
        Makes sense. But this is exactly what i was saying: the tooling you're using makes it easy to set environment variables, and doesn't make it easy to add config files, so in this case, environment variables are easier to use than config files. But there's no fundamental reason for that to be the case. You could imagine a very nearby parallel universe where Kubernetes config files don't let you set environment variables, but do let you inject files. In this universe, you can see other deployment approaches that make config files easier (Puppet and suchlike). And if you're building something from scratch, you can make the choice.
        aniforprez 3y ago
        Well... yeah but in the universe we live in, env variables are the most convenient, interoperable way of configuring apps and work on almost every platform. I guess I could work on a way to sit and dump config files into my apps but what's the point when env vars work well and are convenient to use right now?

dalyons 3y ago

yeah this is the actual point - it makes the code/app totally portable & decoupled from config. I find it significantly better than having to have the app code choose different config based on interrogating facts about its runtime (eg am i in prod? use this value. am i in test? use this)

twic 3y ago
Everything you both wrote is spot on - but there's nothing about it which means you have to use environment variables! All of those mechanisms could be used with any other means of delivering the config at the point of process invocation - a config file, command line arguments, YAML to standard input, whatever. Personally, i would pick a config file over environment variables any day: easier to manually inspect and tweak, easier to give structure to, doesn't get implicitly passed down to subprocesses, can be secured with familiar file permissions, etc.
- stackskipton 3y ago
  Problem with config files is you are forced to process it properly in pipeline so it can be delivered during deploy AND depending on your runtime environment, you might have to redeploy to change things. Environment variables exist on just about EVERY runtime, changed without requiring a pipeline run. However, subprocess is interesting but I've never run into subprocess that is not sharing a config. Where I worked, if you have subprocess that can't see those configs, you create a new service.
  - twic 3y ago
    I'm not sure what you're saying about pipelines. Ultimately, every app process is started by some manager. It's just as easy for that manager to create a config file as it is to set environment variables. If your point is that existing managers support setting environment variables but not creating config files, then sure. But that isn't a fundamental truth, it's just working with the tools you have.
    - aniforprez 3y ago
      Say you have a GitHub Action that pushes a container with your app and deploys to a Kubernetes cluster. Where is your config file going in this step? How do you inject that YAML/HCL/JSON file into the app to configure your app? It just seems far easier to have your kube config inject the env variables from your kube file and that way you don't have to worry during deployment how to add that file and you don't check it into the source. This applies to basically any way you deploy your app, especially containerised ones. Unless you're running your app in an EC2 machine where you can go in and easily edit the file (not that you can't do it in a container), it just seems like extra steps. I've found the happy medium to be sourcing default configs from a file that can all be overridden through env variables
      - twic 3y ago
        Makes sense. But this is exactly what i was saying: the tooling you're using makes it easy to set environment variables, and doesn't make it easy to add config files, so in this case, environment variables are easier to use than config files. But there's no fundamental reason for that to be the case. You could imagine a very nearby parallel universe where Kubernetes config files don't let you set environment variables, but do let you inject files. In this universe, you can see other deployment approaches that make config files easier (Puppet and suchlike). And if you're building something from scratch, you can make the choice.
        aniforprez 3y ago
        Well... yeah but in the universe we live in, env variables are the most convenient, interoperable way of configuring apps and work on almost every platform. I guess I could work on a way to sit and dump config files into my apps but what's the point when env vars work well and are convenient to use right now?