Re:Twelve-factor app development on Google Cloud
by lostcolony on Friday November 01, 2019 @10:51AM
(#21419423)
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...?
Re:Twelve-factor app development on Google Cloud
by paulddraper on Friday November 01, 2019 @11:24AM
(#21419773)
> 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
There aren't any irremovable differences between env vars and files; env vars are basically /proc/ files with widespread runtime support.
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.