This article is a year old, and was based on early development versions of Docker. It's not a good basis for discussion of the current version's pros and cons.
It's actually less than a year old -- but I think that point is more important...
the Docker.io team is forcing their way into the Linux community egregiously fast by being everywhere in every discussion always, sometimes even spreading fud about things their product might do in the future... and... their project is barely a year old now yet calls itself "enterprise ready". The Linux community really needs to pump the breaks on this one...
Maybe it's comforting to think that somehow the Docker people strong-armed the whole world (maybe they're part of the Lennart conspiracy), but realistically they're not that powerful. People are adopting Docker because they actually like it.
Except that a great many people are using it for the wrong reasons, mostly mistakenly thinking Docker somehow is providing huge security benefits to them, when it really is not. Docker (and all containers for the matter) are about application portability... the running applications can still modify your rootfs by design -- it is not a "super chroot" that some people think it is. The worst part is when Docker employees come on and start feeding this fire with promises about future features, etc, people read them as-if it's like that today.
"citation needed", solomon hykes (hn username: shykes) has been OVERLY forthright about container security. I could easily find a dozen posts showing so, but don't think you can find 2 to the contrary.
"""Docker will soon support user namespaces, which is a great additional security layer but also not a silver bullet!
When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly."""
You simply don't get any more authoritative than the guy who wrote docker.
I think most users of Docker would agree with you. We value the dependency management and portability. The fact that the software is running inside a container doesn't magically relieve the burden of ensuring the application is secure. I'll also say that you seem to have a little bit of an axe to grind in these posts. If your mission is to undo Docker's success in the market place, then I would begin with fresh research rather than resurrecting old articles.
No, it's more-or-less we haven't had this large codebase around long enough, and it is changing too rapidly to have uncovered all of the show-breaking bugs (not even mentioning the new ones that will be introduced).
People still don't use BtrFS because of the scare of losing data, and it's been around for years. But why has the same enterprise crowd bought into Docker being totally safe and bug free enough to put into production large scale?
Because they are two different things. BtrFS is a brand new filesystem. It's low level stuff where the tiniest bug can obliterate an enormous amount of data.
Docker is basically a bunch of glue code between several technologies that are getting quite old now. At a basic level, it creates LXC containers that, while not as old as BSD Jails, are quite reliable already. Same goes for cgroups and most everything else.
The only questionable thing imho is (surprise) AuFS. But that's not implemented by Docker either.
Not really, it is using all of the exact same kernel namespacing code that LXC has used. Would you consider LXC pretty battle tested? I certainly would. It has been in the kernel for years.
Now you mentioned earlier that Docker is not a "super chroot" (your words, not mine). Yes it is! You can break out of a chroot with root privilege inside the chroot, ditto for a linux container using LXC or when using docker without the right settings to drop capabilities.
Granted, this all changes when user namespace support is merged into the Linux kernel, but they've been working on that code for quite some time. Additionally, if you want to be pedantic, it Btrfs, not BtrFS. As other people have said, docker is really not a huge codebase. It is primarily glue code on existing and very well established functionality in the Linux kernel. Try to check your facts next time before spouting so much FUD.
