3 ms·

Seconded, but porque no los dos? I tend to put my applications' env vars in `/etc/environment`.

numbsafari 4y ago
It’s a good question and idea. I’ve been trending towards treating secrets and non-secrets differently. For non-secrets, I tend to have a config discovery mechanism that lets me read config from files, then from env, then from cli args as final fallback. This is mostly for ergonomics. I prefer to use files for deployed processes, and env vars or cli params when debugging or working interactively. Env vars are handy for cli args I’m going to be repeating a lot. But for secrets I’ve tended to only fetching those from files, but allowing the file location to be specified by env var or cli arg for quick changes. It sounds kinda complicated, but you write that logic into a library and then everything behaves the way you expect consistently.
- dfsdf4sds 4y ago
  For what it's worth at $dayjob (public company, 1B+ revenue) we do the exact same, although either I misunderstood you or we have the exact opposite priority: args always win, if they're not defined then env wins, then config file, then default config value in code which sometimes is an actual value, and sometimes it defaults to throwing an exception and never passing a readiness check, depending on the behavior of the config in question. This last one is mostly a relic of the past and we believe it's better to blow up if there's no default configuration value in the chart in all cases; it also makes it way easier not to have to chase defaults through the code. We use these for running locally and debugging as you say, but come deployment time we ship all applications as helm charts with default config values, store overrides and static secrets (with SOPS) in a different, company-global repo, and use kubernetes secrets to mount a tmpfs volume to pass them in to the application. There's no way to pass args or env there.
Parrot_NTheKing 4y ago
One pattern that we use at our company is that we have multiple env files, and we launch programs using `run_with_config <config-file> <command>`. The script loads environment variables from config-file and then launches command.
- zach_garwood 4y ago
  I like to do something similar with my personal projects: `set -o allexport && source /ect/environment && set +o allexport; command`

It’s a good question and idea. I’ve been trending towards treating secrets and non-secrets differently. For non-secrets, I tend to have a config discovery mechanism that lets me read config from files, then from env, then from cli args as final fallback. This is mostly for ergonomics. I prefer to use files for deployed processes, and env vars or cli params when debugging or working interactively. Env vars are handy for cli args I’m going to be repeating a lot. But for secrets I’ve tended to only fetching those from files, but allowing the file location to be specified by env var or cli arg for quick changes. It sounds kinda complicated, but you write that logic into a library and then everything behaves the way you expect consistently.

dfsdf4sds 4y ago
For what it's worth at $dayjob (public company, 1B+ revenue) we do the exact same, although either I misunderstood you or we have the exact opposite priority: args always win, if they're not defined then env wins, then config file, then default config value in code which sometimes is an actual value, and sometimes it defaults to throwing an exception and never passing a readiness check, depending on the behavior of the config in question. This last one is mostly a relic of the past and we believe it's better to blow up if there's no default configuration value in the chart in all cases; it also makes it way easier not to have to chase defaults through the code. We use these for running locally and debugging as you say, but come deployment time we ship all applications as helm charts with default config values, store overrides and static secrets (with SOPS) in a different, company-global repo, and use kubernetes secrets to mount a tmpfs volume to pass them in to the application. There's no way to pass args or env there.

Parrot_NTheKing 4y ago

One pattern that we use at our company is that we have multiple env files, and we launch programs using `run_with_config <config-file> <command>`. The script loads environment variables from config-file and then launches command.

zach_garwood 4y ago
I like to do something similar with my personal projects: `set -o allexport && source /ect/environment && set +o allexport; command`