CoreOS is building a container runtime, Rocket • Hacker News Board

Re: CoreOS is building a container runtime, Rocket

#61

Post by jzxcv » Mon, Dec 01, 2014, 7:58 PM UTC

mwcampbell wrote: post #49

philips wrote: post #45

Earlier quoted context omitted.

Right now there is a `actool build` subcommand that will build an ACI given a root filesystem. That tool is used to build the validation ACI's and the etcd ACI. It is rough right now and we will make it simpler to use overtime; and as rkt gets better people can run the build tool from inside of a container given source code.

Nice. It occurs to me that since an ACI is just a tarball, the build process is decoupled from the runtime engine, unlike in Docker. I've found the Docker build process to be unsuitable for creating minimal images (though I've read that nested builds plus layer squashing will fix this). It'll be interesting to watch the exploration of different build tools and processes that Rocket's decoupled approach will enable, i…

> Nice. It occurs to me that since an ACI is just a tarball, the build process is decoupled from the runtime engine, unlike in Docker.

Yep, this is _exactly_ one of our design goals. ACIs are trivially buildable and inspectable with standard Unix tools.

Re: CoreOS is building a container runtime, Rocket

#62

Post by MyDogHasFleas » Mon, Dec 01, 2014, 8:00 PM UTC

tveita wrote: post #47

23david wrote: post #35

Earlier quoted context omitted.

This is great news, particularly for Enterprise customers adopting containers. IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities. But crucially, they also crossed the business models of many startups (including CoreOS, Weave, Flocker, etc.) that rely on Docker maintaining an Open Platform. So this is an entirely logical response. I'll b…

What is Docker's 'new' direction? I don't see any related announcements on their blog besides adding support on new platforms.

I attended Docker Global Hack Day #2 on Oct 30 from Austin. A talk was given on an active Docker project for host clustering and container management, which was non-pluggable, and made no reference to and used none of the code from CoreOS's etcd/fleet/flannel projects.

This was where I first started worrying about CoreOS and Docker divergence.

Re: CoreOS is building a container runtime, Rocket

#63

Post by andruby » Mon, Dec 01, 2014, 8:00 PM UTC

Docker has responded on their blog. https://news.ycombinator.com/item?id=8683276

Re: CoreOS is building a container runtime, Rocket

#64

Post by otoburb » Mon, Dec 01, 2014, 8:00 PM UTC

bastichelaar wrote: post #25

Docker's main focus is to "get people agree on something". And they are doing great in getting traction and adoption. But if everyone starts to create their own flavor of containers, we still don't get portability across servers and clouds. It would be better IMHO if Rocket implements the Docker API, or if they collaborate together in creating a minimal standard. Then everyone would benefit. I'm really curious how So…

Docker's initial response: https://blog.docker.com/2014/12/initial-thoughts-on-the-rock...

Re: CoreOS is building a container runtime, Rocket

#65

Post by pron » Mon, Dec 01, 2014, 8:02 PM UTC

Looking at the code[1] this seems to be a simple wrapper around systemd-nspawn[2]

[1]: https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be4...

[2]: http://lwn.net/Articles/572957/

Re: CoreOS is building a container runtime, Rocket

#66

Post by tachion » Mon, Dec 01, 2014, 8:02 PM UTC

teacup50 wrote: post #56

philips wrote: post #42

Earlier quoted context omitted.

It isn't tied to systemd. The stage1 that is in the current prototype uses systemd to monitor and fork processes but we would love to see other stage1's that configure other process runners. For example configure and run a qemu-kvm filesystem as the container. Also, even though it is using systemd to monitor and fork processes a design goal is to run on all Linux's that have a modern Kernel.

What about non-Linux platforms (FreeBSD, Mac OS X with a kext)? One thing that I believe Docker has failed at is in taking a purely declarative approach to image definition; rather than specifying the packages that are assembled/inserted to create the container, Docker ships around non-portable Linux binaries.

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.

Re: CoreOS is building a container runtime, Rocket

#67

Post by tedchs » Mon, Dec 01, 2014, 8:04 PM UTC

Has libcontainer[1] been considered as a minimal Docker alternative?

[1] https://github.com/docker/libcontainer

Re: CoreOS is building a container runtime, Rocket

#68

Post by rst » Mon, Dec 01, 2014, 8:04 PM UTC

vito wrote: post #39

The post mentions not having a daemon running as root, but then you have to run `rkt` as root anyway. Won't this just mean that instead of having a single implementation of a Rocket daemon running as root, there is now one custom one every time it needs to be automated? It's great to see this problem broken up into reusable pieces though. It totally makes sense to function without a daemon, especially out of the box.

There actually is a significant difference between having 'rkt' as a setuid-root process that's invoked from the command line, and having a docker server always running waiting for commands. There are more ways for a potential attacker to get at the server. So, Rocket at least looks like they're trying to shrink the attack surface.

Re: CoreOS is building a container runtime, Rocket

#69

Post by bgwhn » Mon, Dec 01, 2014, 8:04 PM UTC

billconan wrote: post #54

This may be a noob question, I'm looking into using containers for ui applications. I need to access GPU within the application. is this doable with Rocket or Docker? Also does Rocket have to be used with CoreOS?

Certainly. The kernel can simply pass through the device, although you lose some of the security of containerization that way. There may be issues with multiple containers sharing the same GPU though.

Re: CoreOS is building a container runtime, Rocket

#70

Post by wmf » Mon, Dec 01, 2014, 8:08 PM UTC

billconan wrote: post #54

This may be a noob question, I'm looking into using containers for ui applications. I need to access GPU within the application. is this doable with Rocket or Docker? Also does Rocket have to be used with CoreOS?

GNOME is working on sandboxing + application packaging that's basically containers under a different name. http://blogs.gnome.org/aday/2014/07/10/sandboxed-application... http://blogs.gnome.org/uraeus/2014/07/10/desktop-containers-... http://www.superlectures.com/guadec2013/sandboxed-applicatio...