Announcing rkt v0.5, featuring pods, overlayfs, and more
1–10 of 33 posts
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#2I'm still wondering what the appc spec has more than Docker (and vice-versa). At the moment, I know Docker and find it easy to use. Why would I use Rocket instead ?
Could anyone explain or link to non biased comparisons of the two, please ?
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#3I'm still wondering what the appc spec has more than Docker (and vice-versa). At the moment, I know Docker and find it easy to use. Why would I use Rocket instead ? Could anyone explain or link to non biased comparisons of the two, please ?
Rocket isn't trying to have more than Docker, it's explicitly trying to have less. Rocket was started because the authors thought that Docker was losing sight of it's original mission and becoming bloatware. I've not used Rocket at all, but I'm having to implement Docker in production. As an ops guy rather than a dev, I'm finding a lot of rough edges.
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.
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#4I'm still wondering what the appc spec has more than Docker (and vice-versa). At the moment, I know Docker and find it easy to use. Why would I use Rocket instead ? Could anyone explain or link to non biased comparisons of the two, please ?
Rocket isn't trying to have more than Docker, it's explicitly trying to have less . Rocket was started because the authors thought that Docker was losing sight of it's original mission and becoming bloatware. I've not used Rocket at all, but I'm having to implement Docker in production. As an ops guy rather than a dev, I'm finding a lot of rough edges. One example: I was away from the office a couple of days ago and…
> that image not found error is given as an auth error message!
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.
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#5I'm still wondering what the appc spec has more than Docker (and vice-versa). At the moment, I know Docker and find it easy to use. Why would I use Rocket instead ? Could anyone explain or link to non biased comparisons of the two, please ?
The enhancement I'm most looking forward to is the use of systemd for process management. Docker handles that itself, and can lose track if the process forks strangely and/or badly.
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#6Earlier quoted context omitted.
Rocket isn't trying to have more than Docker, it's explicitly trying to have less . Rocket was started because the authors thought that Docker was losing sight of it's original mission and becoming bloatware. I've not used Rocket at all, but I'm having to implement Docker in production. As an ops guy rather than a dev, I'm finding a lot of rough edges. One example: I was away from the office a couple of days ago and…
> that image not found error is given as an auth error message! 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.
If only there were a separate error code to specifically indicate an authentication problem that could be returned...
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#7Earlier quoted context omitted.
> that image not found error is given as an auth error message! 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.
If only there were a separate error code to specifically indicate an authentication problem that could be returned...
I'm all in favor of nitpicking some of Docker's awfulness, but returning a 400 for Bad Auth instead of 404 will leak information.
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#8As a very effective substrate for hosting containers, we at Terminal think a lot about which of the container mechanisms will win over the long term.
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).
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#9Earlier quoted context omitted.
> that image not found error is given as an auth error message! 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.
If only there were a separate error code to specifically indicate an authentication problem that could be returned...
Github don't use the error code because to do so would leak information about the names of private repositories.
Re: Announcing rkt v0.5, featuring pods, overlayfs, and more
#10It's weird seeing all the careful description of a Pod, which is just an explicit rollback of Docker's wishful thinking about single-process containers to something identical to what you'd get with LXC. Which just runs /sbin/init.
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.