Could anyone explain or link to non biased comparisons of the two, please ?
One example: I was away from the office a couple of days ago and one of the devs had to push to our staging servers instead of me. He logged in, and couldn't pull the image from dockerhub. Error message said the image was not found, which was demonstrably wrong, because he could pull it to his own machine. You just have to know that "image not found" can mean both "image not found" and "you haven't run 'docker login' yet" - that image not found error is given as an auth error message!
There's stuff like this all through Docker, and I can see where the Rocket guys are coming from - Docker is spread too thin trying to do too much. Lots of corners get cut.
404s are pretty common for that. Github, for example, returns "not found" pages for repos you can't access.
Edit - however the login process is quite awkward, though set for improvement.
People tend to wrap it with supervisord which does a better job at tracking child processes.
I must say however, I dont like the pod concept too much. That locks you in a bit.
Additionally and in a different register, the deployment systems, while these work fine when you have to the time to do things right, dont work so well in practice.
All companies that I know of which have 1k employes or less (ie most) basically dont update anything automatically because the redeployment might still fail. And of course, manual labor costs a lot of human resources.
We still need a better way to separate the system update process from the deployment, settings, and app.
They didn't make it up, it's straight from Kubernetes. Presumably the Docker team will wind up incorporating something similar soonish, as well.
That said, it's basically a fancy pants way of saying "we are going to run multiple processes in the same namespace", and if you're using runit like so many people are, you're already doing it.
The amount of wasted development effort caused by Docker's willful intransigence on this is sort of staggering. The teams I work with using docker are still tripping over new nonsense that would have been solved by... I don't know, using systemd... after almost a year of trying to work through the kinks.
Docker's design decisions make sense if you're shipping statically linked, standalone binaries everywhere. Which I suspect docker.io and many other people are doing. But that's also sort of a boring edge case where you don't even need filesystem namespaces except for cleanliness.
My personal opinion is that the winner will be the group that successfully gets Enterprises to change their workload design. I also don't think that Rocket is necessarily a superior format to Docker, but I think they're both dealing with the recognition that any big change in Enterprise behavior represents an opportunity for value capture.
There's a real question as to where any of these abstraction layers fit in if Docker wins (and there's some possibility docker is going to win). If that's the case, coreos doesn't want to look back a few years down the road and wish they'd been working on a container format.
It's 2015. One of the battlegrounds for enterprise dollars is containers. It's going to be a delightful thing to watch.
It's also worth noting that many companies have their own cgroups implementations which are neither docker or rocket based. I rather like the position of dispassionate observer in this war (at Terminal we run all of the containers and also apps without containers).
See for example Garden (née Warden)[0][1], which is the basic building block of Cloud Foundry.
[0] https://github.com/cloudfoundry-incubator/garden [1] http://blog.pivotal.io/cloud-foundry-pivotal/features/cloud-...
