3 ms·
Even putting secrets aside, the environment is a crappy place for config data. It's got a maximum size cap, is trivially introspectable by via any process that
by zbentley 1mo ago
Even putting secrets aside, the environment is a crappy place for config data.
It's got a maximum size cap, is trivially introspectable by via any process that can read `/proc`, and sucks at representing hierarchical or structured data beyond k=v.
The proliferation of tools that come up with all sorts of contortions to encode e.g. JSON-ish structures into the environment is evidence that this ain't a great way to go. I hope we're moving towards a container-orchestrator-by-default future; mounting structured data into pseudo-files at runtime is a really nice alternative.
- locknitpicker 1mo ago> It's got a maximum size cap, It's ok, it's a kv store. > is trivially introspectable by via any process that can read `/proc`, It's ok, containerized apps are expected to run in isolated environments where you are the only one with access to this info. > and sucks at representing hierarchical or structured data beyond k=v. It's ok, it's a KV store. If it isn't, you are doing something terribly wrong. Virtually all config systems developed in the past decade follow this pattern, where multiple config providers are applied hierarchically and env vars are the last chain in the chain of responsibility that overrides all other providers. It works well.