Re:The Twelve-Factor App
by inferiorhuman on Thursday October 12, 2023 @01:40PM
(#37860338)
That sounds an awful lot like a .env file to me.
yup thats exactly what .env is, and tbh that doesn't change anything in the bigger picture
...no? It's the opposite.
A .env file allows you to go from knowing/assuming where a particular file is, to having environment variables.
What I'm describing is that you can go from being passed environment variables directly, to knowing where certain files are; which therefore allows those files to be mounted into a container-image in arbitrary places, rather than encoding brittle assumptions about config-file locations into the binary within the container-image — assumptions that usually get in the way during development, when you're not running the binary inside a container.
Re:The Twelve-Factor App
by inferiorhuman on Friday October 13, 2023 @12:34AM
(#37866715)
You still didn't understand my point. The thing that I'm talking about is using env-vars to point at config files that do not themselves contain env-vars, but rather are opaque app-specific config files, in formats like YAML or whatever-else.
1. create a Secret that defines the file as a key
2. mount that Secret into the container (.secret.secretName in the volume definition) under an arbitrary conventional path, e.g. /secrets
3. define an env-var that gives the path to the file; where the assumption when this env-var isn't defined is to find the file in the working directory. If your own code uses the file, it can read the path from this env-var; while if the core of your container is some opaque tool that doesn't know about the env-var but does take the file's path on the command-line, then you can wrap the tool in an entrypoint script that reads the env-var and passes it as a command-line arg to the tool.
IMHO, this approach is flexible but principle-of-least-surprise obeying for both development and production deployment.