Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

Post reply on HN
Print view View original

231–240 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#231

Post by e12e »

shykes wrote: post #87

Hi, I created Docker. I have exactly 3 things to say: 1) Competition is always good. Lxc brought competition to openvz and vserver. Docker brought competition to lxc. And now tools like lxd, rocket and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing. 2) "disappointed" doesn't even begin to describe how I feel about…

I see a lot of words in your post, but for the life of me, I can't figure out what part of the linked story you feel is "mud slinging", nor what "langauge" or "behaviour" you're so disappointed about? AFAIK docker has had a crappy security story from the start, by design. Perhaps Docker is now, or proceeding to, leverage more of LXC/namespaces for "proper" security -- but the argument against a monolithic daemon makes perfect sense.

Security and convenience are always at odds: I don't see it as a problem that tools lean one way or the other: It does make me a bit worried if they lean one way or the other by accident -- which is what you seem to imply with your comment. I take it you're trying to "defend" docker -- but I don't know against what, nor do I understand your arguments.

Perhaps you could take a deep breath, and try again? I'm sure you really do have something to say on the matter, that is worth reading.

Re: CoreOS is building a container runtime, Rocket

#232

Post by cbsmith »

lambdaops wrote: post #204
philips wrote: post #27

Earlier quoted context omitted.

FWIW, part of the design difference is that rocket doesn't implement an API. When you do `rkt run` it is actually executing under that PID hierarchy; there is no rktd that forks the process. This is a design goal so that you can launch a container under the control of your init system or other process management system.

That's really too bad, because the only way for me to spawn containers programmatically is shelling out.

Forking, not shelling out, no?

Re: CoreOS is building a container runtime, Rocket

#233

Post by cbsmith »

bcantrill wrote: post #78
tachion wrote: post #66

Earlier quoted context omitted.

I second that. At the begining Docker people were mentioning adding FreeBSD Jails support, what seemed to me an awesome thing, a platform independent containerization middleware, but recently they just seemt to forget about it and they're doing only linux-centric things - what a shame.

Yes, but the Docker Remote API allows for a great deal of implementation freedom -- including running on a different OS substrate. We're doing this with sdc-docker[1] to run Docker on top of SmartOS and in a SmartOS container, and the Docker folks have been incredibly supportive. Despite the rhetoric, Rocket appears to be much more bound to the OS platform than Docker -- and given @philips' comment that "part of the…

It depends on how you look at it. The Docker Remote API provides an abstraction on the OS substrate and definitely binds you a lot more to Docker and their model. The "rocket doesn't implement an API" means all that it isn't really doing much more than kicking off the container and using the existing OS substrate to manage everything else.

I can see where for SmartOS & Windows the Docker approach is more flexible. If someone has already settled on Linux, but they have their own ideas about how to manage containers within Linux that have nothing to do with CoreOS, the Rocket model is going to leave them much more flexibility.

Re: CoreOS is building a container runtime, Rocket

#234

Post by mrkurt »

justinsb wrote: post #215
techdragon wrote: post #213

Earlier quoted context omitted.

The Unix model works great at the network later. Otherwise I couldn't be building a complete, multi tenant, docker container as a service / infrastructure as a service, cloud. Built on top of an end to end SDN.

Interesting. Which SDN are you using?

We're doing something like that on top of Open vSwitch, OpenFlow, and vxlan.

Re: CoreOS is building a container runtime, Rocket

#235

Post by cbsmith »

peterwwillis wrote: post #85

So here's my take on this. From the docs on github: The first step of the process, stage 0, is the actual rkt binary itself. This binary is in charge of doing a number of initial preparatory tasks: Generating a Container UUID Generating a Container Runtime Manifest Creating a filesystem for the container Setting up stage 1 and stage 2 directories in the filesystem Copying the stage1 binary into the container filesyst…

> Don't all these steps seem like a lot of disk, cpu and system-dependency-intense operations just to run an application?

I'm not sure I follow. At least compared to using Docker it doesn't seem much different at all in terms of overhead.

> Why is this thing written in Go when a shell script could do the same thing while being more portable and easier to hack on?

Go runs on more platforms than Linux containers, so I don't think Go is going to be a limiting factor. If you think shell script programming is going to lead to more robust and efficient software... ;-)

> Why are they saying this thing is composable when they just keep shoving features (like compilation, bootstrapping, configuration management, deployment, service autodiscovery, etc) into a single tool?

They aren't a single tool? They've architected it so that those different components are quite separable, particularly the ACI is really, really separable from the rest.

Re: CoreOS is building a container runtime, Rocket

#236

Post by losnggenration »

cbsmith wrote: post #228
losnggenration wrote: post #192

Earlier quoted context omitted.

I think it's called OVF[1]. It's just not as widely supported as it probably should be. [1] - http://en.wikipedia.org/wiki/Open_Virtualization_Format

Yeah, just try using OVF with containers and you'll discover how much of a round peg/square hole fit you are describing. VM's and containers are surprisingly different.

> Wouldn't it be cool if projects like Packer[1] didn't have to exist, because the image format of Virtual Machines was open and documented as an independent standard?

Is what I should have quoted in my reply. Nobody was talking about using one instead of the other. Though, it'd be easy enough to run, for instance, CoreOS from an OVF image to run containers from. Though, I feel like you and I are just stating the obvious at this point. Wouldn't you agree?

Re: CoreOS is building a container runtime, Rocket

#237

Post by kentonv »

jtolds wrote: post #32

Improving the security model of docker is mentioned. Docker is known to be currently unsafe to run untrusted containers. Does anyone know yet if Rocket plans to support running untrusted containers safely, ala sandstorm.io?

Unlikely. Doing that requires a willingness to break things (disabling vast swaths of the kernel API in order to reduce attack surface). Sandstorm is fine with breaking things because Sandstorm is all about rethinking the platform and that means apps already need to be tweaked in a number of ways (see: https://blog.sandstorm.io/news/2014-08-19-why-not-run-docker...). Docker and Rocket are very much designed to provide "Standard Linux" inside their containers, and be able to run standard Linux applications.

It looks like Rocket actually intends to be more conservative than Docker:

"Additionally, in the past few weeks Docker has demonstrated that it is on a path to include many facilities beyond basic container management, turning it into a complex platform. Our primary users have existing platforms that they want to integrate containers with. We need to fill the gap for companies that just want a way to securely and portably run a container."

So it's actually moving in the opposite direction, compared to Sandstorm.

(You of course know this already, but disclosure for others reading: I'm the lead dev of Sandstorm.)

Re: CoreOS is building a container runtime, Rocket

#238

Post by stephenr »

shykes wrote: post #110
rdtsc wrote: post #103

Earlier quoted context omitted.

> Hi, I created Docker. I have exactly 3 things to say: In line of making lists of things to say. I got 2. 1) Don't use Twitter for having long conversations and public fights. Just don't. No good will come out of it. Engaging in that is feeding the trolls and slinging mud, which you accuse the other party of doing. 2) Vis-a-vis "just compete!". How do you see this "competing" happening without an announcement like t…

> 1) Don't use Twitter for having long conversations and public fights. Just don't. No good will come out of it. I encourage you to read the twitter exchange I linked to. It predates all of this, and is not at all a fight. On the contrary it is a constructive exchange and I am using it to assert Docker's philosophy in a positive way > Vis-a-vis "just compete!". How do you see this "competing" happening without an ann…

> without resorting to a press campaign like this one

So, clearly stating their concerns about the direction your company has taken, and why they feel the need to create a competing solution is bad?

The only way that article can be considered "negative" is if your opinion is that Docker, Inc are the gods of containerisation and should be considered the be-all and end-all of solutions to container based software deployments etc.

Re: CoreOS is building a container runtime, Rocket

#239

Post by cbsmith »

losnggenration wrote: post #236
cbsmith wrote: post #228

Earlier quoted context omitted.

Yeah, just try using OVF with containers and you'll discover how much of a round peg/square hole fit you are describing. VM's and containers are surprisingly different.

> Wouldn't it be cool if projects like Packer[1] didn't have to exist, because the image format of Virtual Machines was open and documented as an independent standard? Is what I should have quoted in my reply. Nobody was talking about using one instead of the other. Though, it'd be easy enough to run, for instance, CoreOS from an OVF image to run containers from. Though, I feel like you and I are just stating the obv…

I would.

Re: CoreOS is building a container runtime, Rocket

#240

Post by [deleted] »

nsmartt wrote: post #194
peterwwillis wrote: post #187

Earlier quoted context omitted.

I'm sorry but you're incorrect. Mozilla's Firefox was originally called Phoenix, and it was created because Mozilla the browser was a dog-slow encumbered monstrosity of Netscape's attempt to create an all-in-one solution for the web. Firefox was essentially competing with Mozilla Suite, but it wasn't so much "competing" as filling a necessary role: a browser that didn't suck. Mozilla Suite was also not created to com…

Huh. I was basing my comment on the knowledge that Mozilla feared IE would become the way to browse the web. I should have double checked.

[deleted]
Post reply on HN