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

71–80 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#71

Post by wmf »

MyDogHasFleas wrote: post #62
tveita wrote: post #47

Earlier quoted context omitted.

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.

But since the hack day there has been a pretty reasonable (IMO) GitHub discussion about the tradeoffs between out-of-box ease of use and customizability.

https://github.com/docker/docker/pull/8859

Re: CoreOS is building a container runtime, Rocket

#72

Post by api »

tree_of_item wrote: post #21
api wrote: post #12

This is how Linux fragments, and ultimately dies as the Linux we know. I'm not really making a value judgement, just an observation.

How does additional container management software fragment GNU/Linux?

Think a few steps ahead.

These aren't really containers. They're giant statically linked binaries, more or less. The actual operating system is now just a VM host for running containerized giant WIMPs (weakly interacting massive programs). Fast-forward a few years and the host can wither and die and be replaced with a proprietary or custom/fragmented management layer. Linux survives only as an internal pseudo-OS within each mega-binary "container."

Edit: what I was really getting at was that these technologies are patches for the inadequacy of the OS. The fact that we need containers at all stems from the difficulty of managing software installations, configuration, etc on the actual operating system.

Re: CoreOS is building a container runtime, Rocket

#73

Post by bastichelaar »

otoburb wrote: post #64
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...

Thanks!

Re: CoreOS is building a container runtime, Rocket

#74

Post by superuser2 »

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.

Docker's 'new' direction is to direct its attention towards solving the orchestration and management problems involved in actually running infrastructure on Docker.

A number of third parties had begun work on various (sometimes proprietary) orchestration and management systems for creating a reliable/scalable/easily manageable cluster with Docker as a building block. CoreOS is one. But Docker is pushing towards an official, open-source orchestration/management system that threatens to make all of those companies irrelevant.

Re: CoreOS is building a container runtime, Rocket

#75

Post by wmf »

mwcampbell wrote: post #44

How will App Container Images be built? I'm guessing that unlike Docker, the standard App Container build tool(s), if any, will be separate from Rocket.

Docker already supports alternative build systems via docker import.

Realistically, if the stack is broken into a dozen pieces then somebody will create a bundle with sensible defaults (let's call it "CoreOS") and then we'll be back in the same situation.

Re: CoreOS is building a container runtime, Rocket

#76

Post by jambay »

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?

no, rocket does not require coreos, just linux, see: https://github.com/coreos/rocket#trying-out-rocket

Re: CoreOS is building a container runtime, Rocket

#77

Post by FooBarWidget »

gtirloni wrote: post #53
mmcclure wrote: post #37

Earlier quoted context omitted.

I think this was the original model proposed by Docker. What we have now is (as other posters have mentioned), a Docker organization reasonably bent towards creating value for their investors, which means they need to start building things that, you know, make money. To clarify, I don't think there's anything inherently wrong with what Docker's doing, but it is at odds with an entirely open, pluggable system. It does…

I've not been following the discussions but if it's such a critical piece of the whole puzzle and it's in everybody's interest that it remains open, wouldn't a foundation, rather than a single private company, be the best venue for leading the project forward?

Then how do you fund that foundation? Good developers cost a ton of money. Marketing, organizing events, organizing conferences etc also costs a ton of money. I think something like Docker, especially given its growth and adoption rate, never would have been possible without VC funding. VCs wouldn't invest in a non-profit foundation.

Re: CoreOS is building a container runtime, Rocket

#78

Post by bcantrill »

tachion wrote: post #66
teacup50 wrote: post #56

Earlier quoted context omitted.

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.

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 design difference is that rocket doesn't implement an API"[2], this binding appears to be deliberate.

[1] https://github.com/joyent/sdc-docker

[2] https://news.ycombinator.com/item?id=8682798

Re: CoreOS is building a container runtime, Rocket

#79

Post by vito »

rst wrote: post #68
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.

Yep, setuid would make sense. Hopefully that's how people end up using it. (i.e. Rocket should document or distribute it that way)

Re: CoreOS is building a container runtime, Rocket

#80

Post by cpuguy83 »

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…

Docker can import any tarball as a rootfs for a container, essentially allowing you to use whatever build tool you want.

Dockerfiles/`docker build` is an implementation of a build system which uses the docker engine to make said rootfs.

Post reply on HN