Kubernetes / containderd / docker apps are much more convenient to configure through ENV vars, as they easily pass through the sandbox layer (whatever that may be) files are not so easy to make work.
Because that's how prod works devs want to be able to recreate prod to run locally, hence the cambrian explosion of tools like this.
It's a shame that running modern software requires carefully packaging a virtual environment and then injecting a bunch of ugly global env vars.
I still think Docker shouldn't exist. Programs should simply bundle their dependencies. Running a program should be as simple as download, unzip, run. No complex hierarchical container management needed.
> Programs should simply bundle their dependencies.
awww. i don't think it's OK in any way to download libc6/msvcrt as many times as I download __any__ software. even more, is there a strong difference between dependency and runtime environment? if sensible people does not bundle the whole python distribution to a "stuff.py" then why bundle libopenssl.so to a webserver application?
IMO, a saner approach would be just not to confuse dependencies: appX depends on libY 1.9; appZ depends on libY 2.0; people are quick to declare that appX and appZ are incompatibe as they can not run on the same system due to "conflicting dependencies". but who said you have to seach libY in /usr/lib*/libY.so? if you need different versions of a lib, just install them in separate dirs and make your apps find the right one (eg. by setting RPATH or versioned .so filenames).
> is there a strong difference between dependency and runtime environment?
Programs should rely on the global runtime environment as little as possible
> if sensible people does not bundle the whole python distribution to a "stuff.py"
Unfortunately Python deployment is such a such an unmitigated disaster that it's a leading cause of Docker images.
Deploying a portable copy of Python is about 9 megabytes compressed. This is significantly preferable to multi-gigabyte Docker images.
> people are quick to declare that appX and appZ are incompatibe as they can not run on the same system due to "conflicting dependencies". but who said you have to seach libY in /usr/lib*/libY.so? if you need different versions of a lib, just install them in separate dirs and make your apps find the right one (eg. by setting RPATH or versioned .so filenames).
You make a strong and compelling argument as to why programs should bundle their dependencies and not rely on the system environment.
Users should not have to perform any witchcraft to launch a program. Download and run. No further steps should be necessary.
