5 ms·
I think a lot of these issues were already nascent when CoreOS decided to fork Docker. People are asking for 'boring container infrastructure' -- and it's calle
by hosh 10y ago
I think a lot of these issues were already nascent when CoreOS decided to fork Docker. People are asking for 'boring container infrastructure' -- and it's called rkt. I remember the bruhaha at the time, with the Docker folks pissed at the CoreOS folks for doing so. That was Dec 2014. It looks like the way Docker handled the 1.12 release is shifting the sentiment.
For example: I ended up writing this to ask the Docker team for more transparency on this issue: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/148 https://forums.docker.com/t/file-access-in-mounted-volumes-e...
And they responded with an awesome reply addressing it: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/158 https://forums.docker.com/t/file-access-in-mounted-volumes-e... and it went a long way towards helping the community understand the issue what to do about helping.
However, there are also threads like these that asks for the same issue:
https://forums.docker.com/t/should-docker-run-net-host-work/14215 https://forums.docker.com/t/should-docker-run-net-host-work/...
https://forums.docker.com/t/access-host-not-vm-from-inside-container/11747/9 https://forums.docker.com/t/access-host-not-vm-from-inside-c...
https://forums.docker.com/t/explain-networking-known-limitations-explain-host/15205 https://forums.docker.com/t/explain-networking-known-limitat...
They kinda left the community in a limbo here, and quietly added a line in the documentation saying it won't happen. But without the transparency, we don't really know what's going on here.
Back then with the rkt split, the Docker design was to gear towards users so that there is as little friction as possible. It worked all right when it was just Docker Engine on Linux. Over time, due to differences in distros, you can see the container abstraction leaking here and there. Generally manageable.
In the 18 months since, it's becoming clearer that Docker is drunk on their story. Seems like more and more of the leaks from the abstraction are getting swept under the rug while they are trying to make a land grab for the orchestration. Yet Docker is doing it in a way that is sacrificing the goodwill from the community. It first starts with the third-party vendor relationships, but as you can see from these forum posts, it is starting to leak into the relationship with end-users as well -- the developers.
There's still time to turn the (ahem) ship around. But a big part of what is driving Kubernetes success isn't that their abstractions are brilliant, but rather, that project is very transparent and communicative of what they are doing and what they are intending with the community. I get Docker is trying to do that with Docker Swarm, yet I think they missed a critical part of why and how Kubernetes gained so much traction so quickly.