Docker Considered Harmful (2016)(catern.com)
catern.com
Docker Considered Harmful (2016)
http://catern.com/posts/docker.html
51 comments
The way I see it, Docker adds complexity. The more your systems are complex the more brittle they are.
who cares when it saves days by the dozens. Even if docker burned all the hard drive in my home right now for some reason, the amount of time gained when I get an user reporting a bug on $OLD_UBUNTU where I can just run `docker run -it ubuntu:14.04` and start reproducing in a couple seconds, that would still be worth it.
I somehow broke ruby on my Mac so I can’t use cursor keys in irb. No big problem, just do a quick
docker run -it —-rm ruby
Like with any layer of abstraction, you can't mention the complexity it adds without also mentioning the complexity it removes.
It has encouraged people to move to a more immutable architecture, which makes many types of common problems easier to solve.
It has encouraged people to move to a more immutable architecture, which makes many types of common problems easier to solve.
Adding complexity you don't need is a bad thing, but the alternative presented is what exactly? Build packages of my software for each distribution my customers use, and tell them to write custom scripts that will bootstrap chroots on each production machine, install the software in there with the distro's package manager, then set up systemd unit files that will run those with systemd-nspawn?
Goodness gracious, again with those "zombie processes"... I think one of the biggest UNIX design flaws is the PID management (the most appalling part is the need for PID 1 to constantly be reaping the orphaned children). Why does no other OS need such a silly contraption? Why file descriptors don't need such treatment? Oh, right, because they're per-process, not system-wide.
“Considered harmful” considered harmful. Using this phrase all over the place is not clever. It’s just as obnoxious as the uninspired *gates.
I flag most "Considered Harmful" articles. I hate the articles, and I hate the vicious discussions they inspire.
That’s a good policy indeed. Thanks for the suggestion, I’ll try to do the same. Sometimes the discussions have some interesting bits, but there usually is a lot of smugness and finger pointing.
Was it considered... (resisting the urge) overused in 2016 as well? Where is the cutoff date in your opinion?
My personal cutoff is after the first one ;)
And even that one wasn’t very constructive.
Copying a (voluntarily controversial) phrase to put on one’s rant on the new technology du jour is lazy.
Copying a (voluntarily controversial) phrase to put on one’s rant on the new technology du jour is lazy.
The author doesn't show any ways in which docker is harmful. His entire argument seems to be "you can do docker without docker by using the appropriate system calls". But why would I? Docker makes it way easier and has a ton of value-adds like compose, the hub, the layering mechanism etc.
Yeah, I got that impression too.
The value of Docker for me is the ecosystem, not the technical implementation.
The value of Docker for me is the ecosystem, not the technical implementation.
I'm already counting the seconds until somebody links to "the Dropbox comment".
Seems to hit a very similar mark.
Seems to hit a very similar mark.
Not only that, but you can say "Docker" now and people know what you're talking about. If you say "namespaces and cgroups and chroot and btrfs" you're going to have to spend a lot more time explaining exactly what it is that you're doing (unless you just say "I'm doing Docker 'by hand'").
Articles like this are excellent for learning how something is fundamentally implemented, if you are willing to ignore the original intent, which is to discourage people from using the resulting abstraction. I feel sad at how it comes across as angrily reductionist ("it's just X + Y + Z!")...totally missing how the result is more than the sum of its parts.
Docker is a win because they have mainstreamed self-contained, "vm-like" applications that achieve native performance. The collective developer mind can now neatly wrap up the idea of an application into an execution environment that can be easily shared and distributed.
But again, these posts are useful because in the reductionist ranting, the author often lifts the curtain on how these abstractions really work, and that alone is useful to teach.
Docker is a win because they have mainstreamed self-contained, "vm-like" applications that achieve native performance. The collective developer mind can now neatly wrap up the idea of an application into an execution environment that can be easily shared and distributed.
But again, these posts are useful because in the reductionist ranting, the author often lifts the curtain on how these abstractions really work, and that alone is useful to teach.
> The collective developer mind can now neatly wrap up the idea of an application into an execution environment that can be easily shared and distributed.
I think we used to call that a 'binary', but I'm old.
I think we used to call that a 'binary', but I'm old.
Isn't the reliance on dynamic linking what got us into this mess in the first place? System-wide dependencies are a bad idea. apt-get / brew / yum should not be your software's packaging / dependency system, but that's what a large portion of C/C++ software does.
Docker is a strong solution to the problem of dependency conflicts between different software packages. It's what allows me to run software that only works with gcc 7 while my system is on gcc 8.
Docker is a strong solution to the problem of dependency conflicts between different software packages. It's what allows me to run software that only works with gcc 7 while my system is on gcc 8.
This is what I think too. Linux ecosystem mostly depends on dynamic linking, in a way that statically compiling all the dependencies is not easy. The flag "-static" isn't magic, so building a static binary from a project without official static linking support is hard.
Recently, I just tried to build a php binary for a system I don't have root access. Since that system don't have many things that are required to build php, I decided to build a static binary on my computer. Then, its dependencies are really complicated to compile with static linking, so I still can't get it work.
Recently, I just tried to build a php binary for a system I don't have root access. Since that system don't have many things that are required to build php, I decided to build a static binary on my computer. Then, its dependencies are really complicated to compile with static linking, so I still can't get it work.
That’s just one part of Docker. The other part is the security aspects; you cannot “escape” the container (easily). This cannot be achieved with plain static linking, but you’ll need cgroups etc for that.
Docker just combined these concepts elegantly in a way that “clicked” with many people, and was fairly pragmatic.
The only major complaint I have about docker is its client/server model, it just makes so many things more complicated. It seems podman is doing great work in this area though.
Docker just combined these concepts elegantly in a way that “clicked” with many people, and was fairly pragmatic.
The only major complaint I have about docker is its client/server model, it just makes so many things more complicated. It seems podman is doing great work in this area though.
> Isn't the reliance on dynamic linking what got us into this mess in the first place?
Dynamic linking was a terrific solution to code size issues... 30 years ago. Back at the dawn of 32-bit computing, it was typical to see a multi-user machine with 1MB of RAM, for everyone to share.
Also, back then, systems weren't so well connected, and library releases happened once a year or so. Security wasn't as big a concern.
I can't help but think that if we (as an industry) had moved towards a Nix-like package system, we might not have gone down the container route. You just specify which exact versions of which libraries your application depends on, that's it.
Dynamic linking was a terrific solution to code size issues... 30 years ago. Back at the dawn of 32-bit computing, it was typical to see a multi-user machine with 1MB of RAM, for everyone to share.
Also, back then, systems weren't so well connected, and library releases happened once a year or so. Security wasn't as big a concern.
I can't help but think that if we (as an industry) had moved towards a Nix-like package system, we might not have gone down the container route. You just specify which exact versions of which libraries your application depends on, that's it.
Agreed, but also curious: what's to stop software packages from statically linking everything? Does it require re-writing or redesigning code, or is it just a matter of flipping a compiler flag?
You are old! We have a lot more than two developers now.
Sure but now you can compose multiple binaries across many runtimes into a portable unit.
We run docker on top of aws. So a vm-ish thing on top of a vm. I don't understand why we don't just build custom VM images, which is what I did back when I was handling backend stuff. Now I just observe with a kind of befuddled expression as we experience various live issues that end up being docker caused...
Mirage OS is exploring this idea (building custom VM imagine instead of just a docker container).
VM images typically require more storage, ram and cpu than a container.
I know I can run dozens of docker containers but prob nowhere near the same number of VMs
I know I can run dozens of docker containers but prob nowhere near the same number of VMs
but why run dozens (!) of docker containers vs. having all those things in a single vm image? convenience? security somehow?
(genuine question, not rhetorical or trolling.)
(genuine question, not rhetorical or trolling.)
So many points, but they all miss the point.
He links to about 20 different tools/services with the attitude of "docker is just doing all this stuff that already existed!" as if that's a bad thing.
But it's not. It's the whole freaking point.
Docker took a bunch of existing tools and consolidated them into a single general tool, which acts as a foundation to build on.
Hell, they picked a shipping container as a logo for a fucking reason. We also shipped all the same goods before a shipping container was invented, but it was slow, inefficient, and required custom solutions for each port/ship/good. Shipping containers solved that by providing a single foundation upon which you can standardize and extend.
Docker does the same thing.
This is a bad article.
He links to about 20 different tools/services with the attitude of "docker is just doing all this stuff that already existed!" as if that's a bad thing.
But it's not. It's the whole freaking point.
Docker took a bunch of existing tools and consolidated them into a single general tool, which acts as a foundation to build on.
Hell, they picked a shipping container as a logo for a fucking reason. We also shipped all the same goods before a shipping container was invented, but it was slow, inefficient, and required custom solutions for each port/ship/good. Shipping containers solved that by providing a single foundation upon which you can standardize and extend.
Docker does the same thing.
This is a bad article.
"High level languages considered harmful. ASM already does all these things."
Abstraction layers are fundamental to software development, and not a bad thing.
Abstraction layers are fundamental to software development, and not a bad thing.
Heh, that raises a very good point. "Considered harmful" snowclones to the effect of, "This higher-level abstraction is bad because you can get the same general effect, only with more flexibility, by hacking together lower-level constructs," are running directly counter to the principle Dijkstra was advancing in "Go To Statement Considered Harmful." His ultimate conclusion was, "The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. One can regard and appreciate the clauses considered as bridling its use."
I'll pile on: this is a bad article. It's considered harmful. It's also just a set of arbitrary opinions positioned as information. It is not information. It is just noise.
Opinions considered harmful. "It is just noise"
[deleted]
Sure, I was creating chroot's manually with a bunch of bash scripts and rsyncing around filesystems like nobody's business... but it wasn't something you could replicate across organizations and even environments. It was all hand picked and meticulously developed.
Docker (and the many, nice alternatives) standardize the format and build nice features on top. It abstracts away the lower-level stuff.
Neat to know about if you're interested in how it all works... doesn't mean it's harmful.
Docker (and the many, nice alternatives) standardize the format and build nice features on top. It abstracts away the lower-level stuff.
Neat to know about if you're interested in how it all works... doesn't mean it's harmful.
Docker doesn't run on windows 10 without virtualization enabled in the bios. The computer a purchased last year didn't have support for this feature and there is no way to run docker.
Out of curiosity, what hardware? I thought pretty much everything since 2015 supported virtual machine extensions.
You need Windows 10 Pro to enable Hyper-V and/or WSL2.
Nothing to do with the BIOS, because now pretty much every CPU has the VT-x extension.
Nothing to do with the BIOS, because now pretty much every CPU has the VT-x extension.
VT-x can be disabled via BIOS (and was e.g. on my machine. I cannot guarantee that was the case out-of-the-box).
How is a cpu/motherboard from last year does not support virtualization? What?
Many studies proved that most images on docker hub have serious vulnerabilities:
https://www.researchgate.net/publication/315468931_A_Study_o...
This is really bad, yet unsurprising, when you bundle together hundreds of MBs of packages into each image.
https://www.researchgate.net/publication/315468931_A_Study_o...
This is really bad, yet unsurprising, when you bundle together hundreds of MBs of packages into each image.
Docker may actually simplify some stuff and the author doesn't do a great job of describing why it's bad.
Docker might be bad because it creates an abstraction to something you might have to go digging around in anyway so the abstraction is leaky.
That abstraction also has complexity in it's own right. There are a lot of docker-related issues - e.g. how to dockerize data stores - so there is non-trivial complexity cost incurred when reaching for docker.
The argument could be that we've added a layer of complexity without much gained.
The same sorts of issues are there when you make the choice of AWS - abstractions that are themselves complex that, at the same time, are leaky.
An abstraction where I have to understand the layers underneath is not very useful.
Docker might be bad because it creates an abstraction to something you might have to go digging around in anyway so the abstraction is leaky.
That abstraction also has complexity in it's own right. There are a lot of docker-related issues - e.g. how to dockerize data stores - so there is non-trivial complexity cost incurred when reaching for docker.
The argument could be that we've added a layer of complexity without much gained.
The same sorts of issues are there when you make the choice of AWS - abstractions that are themselves complex that, at the same time, are leaky.
An abstraction where I have to understand the layers underneath is not very useful.
Not interested. I don't want `while true; do sleep 1000;tar czf Backups.tar.gz ~ && rsync Backups.tar.gz backup-server:~/ && notify "Backups done"; done`, I want Dropbox.
Docker is great stuff. Don't know how they're going to make money but I'm happy the tech exists.
Docker is great stuff. Don't know how they're going to make money but I'm happy the tech exists.
This reads a lot like a "how docker works under the hood" blog post, from the perspective of somebody who could have written the tool but didn't (read: not your typical docker user even back then), and dressed up with the then-popular "considered harmful" meme. It completely misses the point that docker unified these concepts in a way that made it accessible to people to whom `man 7 namespaces` is completely unreadable and uninteresting until they have some working "but why" motivation and experience.
Over almost 10 years of experience, I've learned 10x more due to tools like docker where first it made things accessible and useful, which drives me to learn more about how things work, to the point where _eventually_ I might have learned enough to write my own toy docker clone. None of that would have happened if I didn't find the tech interesting, which wouldn't have happened if it hadn't allowed me to run a few databases easily, without port conflicts, without more than a few commands and a pretty basic understanding of linux I had at that point.
Accessibility is the gateway to understanding. And try not to forget how you got to wherever you are, while also realizing that others may have different easier paths thanks to technology paved by those who did have the understanding you might already have.
Over almost 10 years of experience, I've learned 10x more due to tools like docker where first it made things accessible and useful, which drives me to learn more about how things work, to the point where _eventually_ I might have learned enough to write my own toy docker clone. None of that would have happened if I didn't find the tech interesting, which wouldn't have happened if it hadn't allowed me to run a few databases easily, without port conflicts, without more than a few commands and a pretty basic understanding of linux I had at that point.
Accessibility is the gateway to understanding. And try not to forget how you got to wherever you are, while also realizing that others may have different easier paths thanks to technology paved by those who did have the understanding you might already have.
So, I have a serious love-hate relation with Docker, and lately it's mostly been hate, but this article still doesn't speak to me at all.
It seems to come from the same place that used to lead so many fledgling software companies to decide to write their own in-house CRM or bug tracker instead of buying a commercial product. Yes, the commercial product is big and complicated and takes time to learn and implements a hundred features you don't need. Yes, the absolute minimum implementation will take no time to hack together. But this is a trap. All that stuff you thought was just window dressing will inevitably prove to be critically important to someone at your company. A 90% solution will not work for the long haul, and rolling your own will inevitably send you down a path that ends in tears, blood, and the endless quagmire of implementing the last 10% of needed features that proverbially take 90% of the effort. And then 99%. And then 99.9%.
It seems to come from the same place that used to lead so many fledgling software companies to decide to write their own in-house CRM or bug tracker instead of buying a commercial product. Yes, the commercial product is big and complicated and takes time to learn and implements a hundred features you don't need. Yes, the absolute minimum implementation will take no time to hack together. But this is a trap. All that stuff you thought was just window dressing will inevitably prove to be critically important to someone at your company. A 90% solution will not work for the long haul, and rolling your own will inevitably send you down a path that ends in tears, blood, and the endless quagmire of implementing the last 10% of needed features that proverbially take 90% of the effort. And then 99%. And then 99.9%.
[deleted]
“Docker Considered Harmful (2016)”
2016 opinion, yes?
Did I miss something?
Why, what, how, who, is it considered, harmful?
2016 opinion, yes?
Did I miss something?
Why, what, how, who, is it considered, harmful?
Only when I got to the 5th section did it make some sort of argument, which ended up being about Docker not using an init system to manage daemons, and the usual problem this brings to badly-written images (process reaping). Ignoring the fact that plenty of daemon managers exist, and are used both with and without Docker, like supervisord.