It's a better, more isolated mess - but for anyone trying to enforce configuration policy into all of the running services in their environment, untangling gortesquely basic shit like not granting superuser privs on a database to your webapps - which would never fly in a traditional distro package - becomes even more work than the old source tarballs with INSTALL.txt.
This is the entire value proposition of all successful technology. Dubious business practices notwithstanding, all successful yet imperfect technology is successful because more people found it let them be lazier than the competition. But in reality of course it's not laziness, it's efficiency. They can get on with other tasks sooner than before.
Indeed, and I use Docker myself to improve my own efficiency, and I've seen great stuff built with Docker that has been architected well.
However, it is painfully obvious that without the pressures that used to force most developers to keep their shit sane, there's now more workload for serious users that actually need to untangle this mess in order to support, secure and get stuff deployed.
The other security issue mentioned, piping curl into sh isn't really that big a deal. As long as you're a) using HTTPS and b) you resonably trust the source you were probably never going to read the script anyways.
I mean, when I first evaluated this app, it didn't even have a sane launcher script. Instead, ~15 lines of ruby config and a ruby script that I had to follow just to discover it was a weird, idiosyncratic way of executing "docker run".
Edit: I am not saying that Docker is somehow inherently flawed in this respect. It's solved a lot of problems for me and you can build great, well-architected stuff with it. But there is a trend to use it to wallpaper over poor development and deployment practices.
Now the nice thing about docker is you could have spent about 5 minutes to trivially docker run the app, decide if it's actually worth the effort, then untangle the mess beneath.
That's a net win in my eyes, though by the time I actually run something in production, I generally try and untangle the mess before I do. I also find it's easier to get help developers deliver something legible as sadly many of them often don't even know which packages they installed to get something running.
Listen, I'm not saying it's perfect. I specifically really don't like that Docker is basically root without Selinux (which is often turned off). I'm happy to see docker be replaced. I am however, not really interested in returning to puppet modules to handle dependencies when a container is, in my opinion, so much better.
There's a vast tectonic shift occurring and it couldn't come sooner -- "tinkering" with an increasingly complex environment of microservices, message queues, RPC servers, databases, caches, and so forth is headache-inducing and everybody knows it, as it detracts from actual application development.
I like the nest of snakes analogy, it's quite accurate. The twelve-factor application architecture[1] is here and many are moving towards it in one way or another, be it simply starting out writing unit tests or refactoring large applications into something easier to grok.
You'll need to learn OCaml (though in my mind, that's actually a major plus).
Caveat emptor: AFAIK, MirageOS is still undergoing heavy development. That said, I believe it is essentially functional at this point (pun not intended).
Kernel ABI stability has brought forth options like running docker containers on FreeBSD and Solaris/Illumos/SmartOS Standardised workflows around "containers" are breaking down the need to care what your container is on the inside. Imagine running statically compiled Go binaries that have been compiled against s CloudABI tool chain deployed to CloudABI native hosting with maximum flexibility.
I've got a notebook full of details about "Linux compatible" system designs. Throwing away the Linux kernel for fun and profit! It's closer than you think.
I am still hoping that something as radical as MirageOS will eventually take off, since we really seem to need it--at the very least, from a security perspective, if not a complexity one. Just by dumping C and Unix, and using a memory-safe language (such as OCaml) instead, we eliminate an entire class of exploits.
I will readily admit, though, that trying to force the entire world to use OCaml will surely be the fastest way to fail at this goal. Perhaps aggressively sandboxing is an adequate alternative, which would allow people to write code in environments sitting on stacks containing code from unsafe languages, without single exploits leading to entire system compromise.
When it gets interesting is when you invert the relationship, where you have multiple apps in Docker. Then the main server starts to look quite simple and bare, much easier to maintain. And then things like ECS start to make sense:
At that point, the OS becomes irrelevant except as a host for containers.
Docker seems to be moving forward really fast and gets a lot of hype which tend to make my old-school sysadmin self a bit suspicious, but I'd love to hear critique that is based on the actual usage. (N.B. I'm just about to start making my first Docker deployment)
Many people aren't ready to further abstract away from bare metal by adding a container layer for process management on top of the operating system which may be running inside a hypervisor. And there are situations where that's problematic. So it's not a great fit there either.
But having tried out Docker for some production deployments, I think that it (or some less goofy successor) is the way forward. You get a sealed box with all the necessary dependencies, and the box has just enough holes poked in it that you can connect up the bits you care about. It turns apps into appliances, not things you need expert craftspeople to lovingly install.
As much as I have enjoyed 25 years of doing everything on an OS whose conceptual model is a 70s university department minicomputer, this era is coming to a close. We already know it's a poor match for existing hardware and use cases because we now mostly run it in virtual servers. But "virtual server" is the new "horseless carriage". It's a phrase that tells us we are living in a future we don't yet fully understand.