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

211–220 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#211

Post by thockingoog »

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.

This was a key principle of LMCTFY, too, FWIW.

Re: CoreOS is building a container runtime, Rocket

#212

Post by etcet »

teekert wrote: post #113

Hmm, I played around with CoreOS for the past weeks, it was nice, I'm getting the hang of it. What is constantly difficult though is that there is no cross linking of containers (mysql database accessible from user@172.ip.add.r while the Nginx/PHP-fpm docker is looking for a specific mysql ip addr). Restarting containers from images changes both IPs. Not handy. Why not always share a common /etc/hosts with all curren…

> I was also having some issues with php5-fpm in a docker, it doesn't seem designed for it (it gets the file paths communicated from Nginx, not the files so dockers need to sync files)

The volume that your site code is on needs to be linked to the php-fpm container. Typically you would host this volume on a data container and use --volumes-from $ctid when starting the php-fpm container.

Re: CoreOS is building a container runtime, Rocket

#213

Post by techdragon »

justinsb wrote: post #31
bketelsen wrote: post #2

Great news. I'm not a fan of Docker's new monolithic approach to containerization. Things like orchestration and networking should not be included in docker, but rather pluggable.

I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration. The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.

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.

Re: CoreOS is building a container runtime, Rocket

#214

Post by vacri »

biot wrote: post #162
spb wrote: post #92

Earlier quoted context omitted.

I think you're reading too much - or too little - into this if you think they're "slinging mud". Any fork is going to list its reasons for the fork- if they didn't have issues with how Docker is heading, why would they be making the fork in the first place? If they just quietly gave an ambiguous non-disparaging statement like "we're forking because we're unhappy with the direction Docker is taking", it would seem fri…

I don't have a horse in this race, but from what I read this is the part that can be construed as "slinging mud". I've put some [read between the lines] comments in square brackets: "Unfortunately, a simple re-usable component is not how things are playing out. Docker [much to our dismay] now is building tools for launching cloud servers, systems for clustering, and a wide range of functions: building images, running…

"Docker is broken and can't be fixed"

Or, taking the announcement as intended, "We were interested in the direction Docker started in, they have since pivoted. We were more interested in the direction than Docker itself".

Yes, there is some mild-mannered disparagement in the announcement, but it's hard to characterise it as 'slinging mud', and it's not really fair to disparage it with the name-calling you're injecting.

Re: CoreOS is building a container runtime, Rocket

#215

Post by justinsb »

techdragon wrote: post #213
justinsb wrote: post #31

Earlier quoted context omitted.

I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration. The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.

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?

Re: CoreOS is building a container runtime, Rocket

#216

Post by mikerichards »

frostmatthew wrote: post #164
hobofan wrote: post #157

Earlier quoted context omitted.

There is no switch to flip. You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git.

> You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git. A much more accurate analogy would be you are not "locked in" by Oracle if you are using MySQL . It may be true today, but no guarantee that will always be the case.

Despite the attempt of some to move goal posts, you're still guaranteed that you won't be locked in by Oracle even tomorrow. You still have the source code for the version you're running right?

Re: CoreOS is building a container runtime, Rocket

#217

Post by mikerichards »

SEJeff wrote: post #95
loudmax wrote: post #22

Earlier quoted context omitted.

Fragments? Certainly. Dies? Linux has been fragmented from its inception. If you include the world's Android phones, Linux probably runs on more computers than any other kernel or OS. Rocket will not kill Linux, containers, or docker. In the worst case, it will kill CoreOS, and even that's unlikely.

Likely not even close. Just about every single washing machine, refrigerator, microwave, digital stove, etc, runs a variant of an open source operating system called Tron, or the more common ITron variant. http://en.wikipedia.org/wiki/TRON_project Tron has been around since the mid 80s I believe and Linux was first released in the early 90s.

Interesting, I had never hear of (I)Tron

Re: CoreOS is building a container runtime, Rocket

#218

Post by curun1r »

ecnahc515 wrote: post #40
justinsb wrote: post #31

Earlier quoted context omitted.

I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration. The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.

Interestingly enough, with flannel, docker's advanced networking capabilities become pretty trivial, and communication across hosts is also pretty trivial. I think all in all, CoreOS has built out a ton of tools to make using Docker easier, and they're all very well defined, and compossible. I'd even say that a lot of docker's features could be completely removed by using some of these tools. Links? Nah just use ips/…

The problem with the CoreOS tools is that they're pretty tightly coupled. We looked into using fleet to manage our deployments. Unfortunately, it relies on a minor feature of etcd and cannot work with Consul, our corporate standard. Flannel? Yep, again, tightly coupled with etcd.

I like some of the ideas behind the CoreOS tools, but until they start playing well with others, they're a non-starter for me. I'm not interested in tools that try to lock me into other, inferior, tools.

Re: CoreOS is building a container runtime, Rocket

#219

Post by darren0 »

philips wrote: post #42
darren0 wrote: post #36

Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...

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.

The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.

Re: CoreOS is building a container runtime, Rocket

#220

Post by frostmatthew »

mikerichards wrote: post #216
frostmatthew wrote: post #164

Earlier quoted context omitted.

> You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git. A much more accurate analogy would be you are not "locked in" by Oracle if you are using MySQL . It may be true today, but no guarantee that will always be the case.

Despite the attempt of some to move goal posts, you're still guaranteed that you won't be locked in by Oracle even tomorrow. You still have the source code for the version you're running right?

Sure...as long as I don't care about security patches, bug fixes, performance improvements, or new features.
Post reply on HN