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

201–210 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#201

Post by losnggenration »

pquerna wrote: post #195
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

In theory, OVF is the 'answer' for Virtual Machines -- but its failure has been in adoption -- if you can't get Amazon and OpenStack to adopt it, what's the point? Before Rocket/ACI there wasn't even a contender for Containers. Now there is a published spec. Start there. Iterate.

I don't disagree, but OVF is an ANSI[1] & ISO[2] standard. Like you said, Amazon & OpenStack have chosen not to adopt it.

[1] http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS+469-20...

[2] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_det...

Re: CoreOS is building a container runtime, Rocket

#202

Post by Rapzid »

otoburb wrote: post #9

Interesting takeaways from the post: * Despite Brandon Philips (CoreOS CTO) serving on the Docker governance board, Docker has aggressively expanded their scope well beyond their original container manifesto. * CoreOS believes the Docker runtime is now too unwieldy and "fundamentally flawed"; the unwritten word that really sprung to mind was that Docker was getting "greedy." * CoreOS reaffirms their original operatin…

CoreOS doesn't mind using systemd...

Re: CoreOS is building a container runtime, Rocket

#203

Post by nwmcsween »

The underlying software coreos relys on is a tightly coupled implementation defined api, then arguing that docker isn't following the "Unix philsolphy" is hilarious I wont touch coreos due to this. I also won't touch docker due to its NIH syndrome of reinventing things, poorly.

Re: CoreOS is building a container runtime, Rocket

#204

Post by lambdaops »

philips wrote: post #27
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…

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.

Re: CoreOS is building a container runtime, Rocket

#205

Post by jpgvm »

I fail to see how Rocket is going to end any better than Docker.

It's already tied to systemd-nspawn (though arguably you could make this pluggable to support other process babysitters).

Infact, Rocket as it stands is just a wrapper around systemd-nspawn and little else.

They harp on about this new ACI format but it isn't really anything new and fails to solve the problems that currently face Docker format, which is a sufficient amount of metadata to properly solve the clustered application and networking problems.

I am all for things that do one thing and do them well, but right now Rocket is just systemd-nspawn which is just a more platform specific LXC in my opinion.

Note: I don't necessarily agree with everything Docker is doing either, I just don't think Rocket is a productive way to fix it.

Re: CoreOS is building a container runtime, Rocket

#206

Post by lambdaops »

mbreese wrote: post #8

I'm all for a new container runtime if it lets me start containers as a non-root user. Allowing non-root users to start containers would open up a whole new level of applications, particularly on multi-tenant HPC-style clusters.

Yes, finally! I've been working around this by making users inside the containers that people launch jobs on, but it would be much easier if they could do it individually in their own namespace (not using a docker group either).

Re: CoreOS is building a container runtime, Rocket

#207

Post by Rapzid »

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.

"Looks like" is usually about as far as people get when they start down this road. If they make it down the road, they arrive at mess. Just look at what OpenStack has been through :)

So then, I guess docker could just run the two servers, one internal as root and one public as not? That's a pretty quick fix.

Re: CoreOS is building a container runtime, Rocket

#208

Post by [deleted] »

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.

[deleted]

Re: CoreOS is building a container runtime, Rocket

#209

Post by sandGorgon »

monatron wrote: post #175
sandGorgon wrote: post #86

Earlier quoted context omitted.

I think it is a great stand for Docker. Very recently (IMHO in 1.3), it merged the functionality of Fig into Docker. I think Docker orchestration and coreos can coexist - if I had to use COREOS to use the goodness of Docker, then systemd-nspawn would come and eat Docker's lunch. I wish that Docker bless one of Ansible/Chef as the official orchestration base and take it forward. I really don't want to earn something D…

Fig functionality was not merged into Docker's 1.3 release. Ansible/Chef orchestration IMHO solves a very different problem than container orchestration.

You're right - I was referencing this bug here (https://github.com/docker/docker/issues/8637), but seems it was not merged into mainline.

I agree that Chef and Ansible are different than container orchestration today - especially, when you look at low level stuff like networking, mounts, etc... But I guess what I was saying is that it is not hard to add these features to them.

They already have a specification format that works well and check for idempotency at its core. Unless you mean something like etcd is fundamental to container orchestration, which I don't believe it is (we run a couple of containers in production using Fig)

Post reply on HN