Does anyone not remember what it was like to fight shared library versioning conflicts? Do you want to be handling the GitHub issues attached to people screwing up that kind of thing in 2017 because their distribution or OS X package manager randomly changed?
Docker is ultimately a non-solution that papers over the problems of traditional system package managers, language-specific package managers, and the myriad of software (mostly Java) that no one actually knows how to build from source. Containers do not compose. There are many runtime environments to consider, and Docker can't handle anything but containers. You need to use some other software to manage the host system at the very least. Furthermore, the container images have no useful provenance for users to inspect. It's a security nightmare.
Functional package management is the real solution here. Software like GNU Guix and Nix solve real problems. They remove global state (/usr), enable reproducible builds, allow unprivileged package management, support transactional upgrades and roll backs, deduplicate software system-wide for all users, handle full-system configuration in a declarative way, eliminate the need to trust any particular provider of binaries, and more.
>Does anyone not remember what it was like to fight shared library versioning conflicts?
Using Docker to solve this problem is like using a sledgehammer to drive a nail.
It's interesting that you saythis--I would say almost the exact opposite here: most of the Java applications are the best-behaved on systems I deal with, both in terms of execution (it's in the Maven repo) and in terms of process control (cgroups are nice for, like, a Ruby app, but here I've got -Xmx). The poorly behaved ones seem to be ones that don't use standard tools, and maybe I've been lucky but for me that's all third-party and mostly open-source stuff; a lot of new-hotness stuff (Kafka, I am looking at you, I love you but you are a pain in the behind to deploy) can't just be run straight out of the Maven repository with a bash script or whatever.
About the only place I use containerization at all (and I don't use Docker, for reasons I've described elsewhere around here) is for Ruby or Python applications where otherwise I do end up with stuff thrown all over the place and multiple versions of the runtime fighting for supremacy. I'd love to use Guix/Nix, but it's a hard fight to win in a corporate environment.
> Using Docker to solve this problem is like using a sledgehammer to drive a nail.
I wish to upvote this eleven times. I can but do so only once.
I don't know how large or flexible your organization is, but I've been driving hard at my company (which is a bit shy of 100 employees) for using nix, and it's working. When I started advocating for it there was no small amount of skepticism, but we started off just using it for a very small and specific use case, and from there it has slowly but steadily gained acceptance from other developers (most of whom have no particular interest in FP) as a real solution to innumerable problems that we have w.r.t. package management. If you're interested in Guix/Nix, I'd encourage trying to get permission to use it to solve a specific problem.
Does that not qualify as "hack-it-'till-it-works", the worst kind of computer activity, especially when one is stuck trying to reverse engineer what the guy before did? Can you think of what implications "doing whatever is necessary to make it work" has for lifecycle management?
Nope, because on Solaris and illumos based systems like SmartOS, OS libraries are backwards compatible. As long as I build on an ancient version of Solaris 10, the Solaris ABI guarantees me that my applications will continue to run unmodified on the latest, ultramodern SmartOS. So no unnecessary pain.
I am not sure where this question is going, though.
Between nspawn, LXC, the various BSD systems, and a few others I forget, we have plenty of choice for containerization.
And Dockerfiles are both poor at being universal enough to serve as blueprints, and at being flexible enough to be useful by themselves.