towerful@programming.dev 5 days ago
I really wish there was a way to enforce transparency of docker env vars.
I get that it’s impossible to make it a part of docker, env vars get parsed by code and turned into variables. There is no way that docker can enforce it, cause a null/undefined check with a default value is all that would be needed to subvert checks by docker, and every language uses a different way to check env vars (eg .env files, environment init scripts, whatever).
And even then, the env var value could be passed through a ridiculous chain of assignments and checks.
And, some of those ‘get env var’ routines could be conditional. Not all projects capture all env vars during some initial routine.
I’ve spent hours (maybe days) trawling through undocumented env vars trying to figure out their purpose, in order to leverage them in docker/k8s stacks.
I wish there was something.
Thankfully, a bit of time spent with a FOSS project and reviewing the code does shed light on hidden env vars.
And a PR or 2 gets comments and documentation updated.
Open source is awesome
PhilipTheBucket@ponder.cat 5 days ago
Yeah, I honestly just strongly dislike the whole Docker ethos. It was designed for one thing (deployment at scale), at which it excelled, and then everyone uses it for a different thing (reproducible one-off deployment), at which it is fine, basically, but just kind of the minimum set of capabilities to get the job done.
Nix can do what Docker does, in a much superior fashion (lower disk space, much better transparency, rollback ability, lack of towering chains of follow-on effects as you are talking about, and applications outside of mucking around with containerized images), but for some reason everyone uses Docker, and Nix is as far as I can tell unused outside of NixOS.
Whatever. When they make me king, it’ll be different, that’s all I can say.
theherk@lemmy.world 5 days ago
Nix and Docker / container runtimes are completely different animals. Each is good at what they do, but those are vastly different things, with some overlap. If you want to share a kernel but use fewer resources than a VM, containers can do that. If you want to go further and completely isolate, you can use microvm’s like firecracker.
I don’t follow what is wrong with that. Maybe you mean it’s use where people use it specifically as a package manager. I agree with that, but even then it has its handy place.
PhilipTheBucket@ponder.cat 5 days ago
Precisely. Containerization is great and Docker does it well. Sending someone a reproducible script that can set up your software package for them is great. Marrying the two concepts unnecessarily and using one specific tool which is designed primarily to do the first, to instead do the second, is the only real issue I’m taking with it.