
CoreOS is building a container runtime, Rocket - kelseyhightower
https://coreos.com/blog/rocket/
======
otoburb
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 operating model of being capable of running their infrastructure on and with Docker.

* Rocket is CoreOS's answer to stay true to the "simple composable building block" mantra.

~~~
higherpurpose
> 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."

I wonder if that comes from the partnership with Microsoft.

~~~
krschultz
They raised $55 million [1], so you have to believe their ambitions are to
extract as much rent from the container ecosystem as possible. That's not a
bad thing, but it's behind a lot of their moves.

[1]
[http://www.crunchbase.com/organization/docker](http://www.crunchbase.com/organization/docker)

~~~
Alupis
Docker's MO is to become "that thing that is on all servers" so that when they
flip the switch and start monetizing off support and tertiary services, people
will be more-or-less locked in.

It has indeed surprised me how quickly a normally-slow-to-accept-new-things
community has adopted Docker (even well before it was considered "stable").

~~~
simtel20
> how quickly a normally-slow-to-accept-new-things community

I think you're referring to the sysadmin community - but I think the driver
for this has been the search for deployment nirvana. Deployment is a much more
fragmented field, so it makes sense that a good solution would find fertile
ground.

~~~
vcarl
Absolutely. Not only does it simplify deployment, you also get the ability to
quickly spin up a new development environment. That means it's easy to dip a
toe in and slowly increase how much you use it.

------
sentiental
I have been concerned that Docker's scope was expanding too far for a while
now, so I'm glad to see an alternative that might work appear on the horizon.
That said, I am somewhat concerned that CoreOS has a suspiciously similar
business model to where Docker would probably like to be.

It's in a business's best interest, and exceedingly common practice, to "land
and expand" with something clear and compelling, and following that add
features to compete with alternative solutions. I don't think there's anything
inherently altruistic about CoreOS that would keep Rocket lean in the long-
run, especially as they begin migrating their various tools away from Docker
containers.

~~~
rafikk
I had the same initial reaction, but I think there's good reason to trust the
CoreOS folks to remain faithful to the project's goals. Containerization
(although foundational) is one part of CoreOS's platform. It's easy to see
where the boundaries fall, e.g. I expect systemd and fleetd to keep their
respective functionality and not overlap with Rocket.

It become pretty clear once dotCloud became Docker Inc. that they intended to
capitalize on the "Docker" brand to sell an integrated orchestration platform.
CoreOS already has enterprise customers for their operating system and related
components. They seem like the perfect team to take this challenge on.

~~~
Alupis
I think it's also crucial users have more than one viable container option.

------
bjt
I had just landed LXC container support in Velociraptor [1] when Docker was
announced last year. It uses Supervisor to launch LXC containers and run your
app inside. I thought long and hard about switching to Docker, but their
decision to remove standalone mode [2] would have meant replacing all of
Velociraptor's Supervisor integration with Docker integration instead. With
Docker being such a moving target over that time span, it just seemed like a
bad move.

Since then I've been mulling writing my own standalone 'drydock' utility that
would just start a single container and then get out of the way (as opposed to
the Docker daemon that insists on being the parent of everything). I'm
optimistic that Rocket could be that thing.

Question though: Does Rocket have any concept of the image layering that
Docker does? That still seems to me like a killer feature.

[1]
[https://bitbucket.org/yougov/velociraptor/](https://bitbucket.org/yougov/velociraptor/)
[2]
[https://github.com/docker/docker/issues/503](https://github.com/docker/docker/issues/503)

~~~
philips
Yes, the app-container spec has the concept of dependent filesets. See:

[https://github.com/coreos/rocket/blob/master/app-
container/S...](https://github.com/coreos/rocket/blob/master/app-
container/SPEC.md#fileset-images)
[https://github.com/coreos/rocket/blob/master/app-
container/S...](https://github.com/coreos/rocket/blob/master/app-
container/SPEC.md#fileset-manifest)

What do you think of the filesets concept?

~~~
bjt
I'm still digesting the Go-like syntax for vanity URLs and how that works
here. If a fileset manifest lets you specify the URLs where the layers can be
fetched from, then I like it.

Does Rocket just 'cp' files on top of each other to implement layering? It'd
be nice to not require a bunch of copies of the same files. I thought that the
hard link implementation in Docker's new overlayfs support was a smart idea.

~~~
philips
Yes, all of this was designed with overlayfs in mind. I am waiting anxiously
for Linux Kernel 3.18 to land, this is a huge step forward for Linux and years
in the making.

~~~
sophacles
Cool! The idea of filesets is very nice - there are some very interesting
workflow ideas buried in there. I've been looking forward to a mainstream
unioning filesystem for a while too - and I hope rocket does some serious
exploration (or enables it) of how to take advantage of them fully in _both_
development and deployment. (And while I'm at it, testing too).

My personal wish-list down this path includes:

* options in the relevant manifests on which layer is writable ... if I'm doing development on libfoo which is used by several different apps, let me make that layer writable so I can rapidly iterate integration tests and (bad practice) live coding on testing/dev servers.

* tools to help me smash a dev layer or 3 into a single fileset (and similarly dissect a layer into a few new filesets during a refactoring)

* the ability to use filesets and overlays in a way similar to package management is now, but with extended features that are similar to python's virtualenv.

One of the things I see as a boon of the filesets _as described_ is: I can
update parts of my system without having to rebuild the whole dang app silo
from the get go. Combining this with some of the above features looks like it
could be useful for making "thin" images - where I can build all my code in
one place, and port only the binaries to the staging and deployment images,
just by doing a few fileset/overlay tricks. (no more complicated scripts)

------
_mikz
I hope Rocket will be more stability oriented than Docker. After runing few
hundreds containers on machine for almost a year know I would not chosen
Docker again. Docker has stability issues all the time and it is taking months
to solve them.

Offering strace logs to developers without feedback and finally it was fixed
by someone from outside the project.
[https://github.com/docker/docker/issues/7348](https://github.com/docker/docker/issues/7348)

Allocating ports pops now and then every odd docker release:
[https://github.com/docker/docker/issues/8714](https://github.com/docker/docker/issues/8714)

Even stupidest things like allowing to have more dockerfiles in one folder.
[https://github.com/docker/docker/issues/2112](https://github.com/docker/docker/issues/2112)

Docker has own agenda and it is clearer and clearer.

~~~
darkarmani
> Even stupidest things like allowing to have more dockerfiles in one folder.

Wow. That issue has been open for a long time.

~~~
drewcrawford
I've been involved in that ticket since the dark ages. There's a philosophical
disconnect between how (some) people want to use Docker and how the
maintainers want it to be used, and it comes to a head in that thread.

~~~
narrowrail
For anyone else trying to follow along (and still evaluating docker at a
distance), start with this comment in that thread:

[https://github.com/docker/docker/issues/2112#issuecomment-39...](https://github.com/docker/docker/issues/2112#issuecomment-39763037)

It gets quite interesting, and it's still going 14 months later...

------
yannisp
Docker just posted a blog response

[http://blog.docker.com/2014/12/initial-thoughts-on-the-
rocke...](http://blog.docker.com/2014/12/initial-thoughts-on-the-rocket-
announcement/)

~~~
cheshire137
Hacker News thread:
[https://news.ycombinator.com/item?id=8683276](https://news.ycombinator.com/item?id=8683276)

------
bketelsen
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.

~~~
justinsb
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.

~~~
ecnahc515
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/dns + etcd for service discovery.

Networking? Need very basic bridged networking, and flannel will handle
communication on a single host, or multihost.

Deployment? Use fleet.

Not that all these are 100% perfect like I've made them out to be, but any
individual component could be swapped out if you want.

~~~
spb
The thing I like about the link model is that they hide your containers from
other containers and only expose the connections you want (I think using
iptables?)

I'd like a tool that makes this linking easier outside of Docker, but for now
this is one of the features I like about it (although holy moly do Docker
links have a lot of baggage you have to bring along for the ride, like giving
everything names).

~~~
vishvananda
Shameless self plug, but not sure if you saw my project that does something
along these lines:

[https://github.com/vishvananda/wormhole](https://github.com/vishvananda/wormhole)

~~~
spb
From the docs, it looks like that has a dependency on Docker, which kind of
defeats the purpose. If I'm stuck with Docker, I'm better off just sticking
with links: I'm looking for something that could work with systemd-nspawn,
etc.

------
vito
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.

~~~
rst
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.

~~~
gizzlon
> _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._

hm.. I don't think that's a given at all! There's been many issues with
setuid-root programs. And I've seen that the OpenBSD guys favor privilege
separation by breaking breaking up daemons into several parts that communicate
using a very strict set of commands. For example a dockerd that does most of
the work, but talks to another daemon (dockerd-root) when it needs to do
anything privileged.

OpenSMTPD example:
[https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd...](https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd/#slide-26)

OpenSSH: Initial efort, 2002:
[http://www.citi.umich.edu/u/provos/ssh/privsep.html](http://www.citi.umich.edu/u/provos/ssh/privsep.html)

[http://www.openbsd.org/papers/openssh-measures-
asiabsdcon200...](http://www.openbsd.org/papers/openssh-measures-
asiabsdcon2007-slides.pdf) \- Page 16 ->

------
degio
I found reading these comments very interesting.

From one point of view, I'm thinking "why did coreos need to be so
aggressive?", and "boy, what a gift Solomon Hykes did to coreos by mismanaging
this thing so badly", and "man, all of these guys look sort of immature to
me".

From the other point of view, I'm respecting docker and coreos even more, as
open source projects and as a companies, because it feels like there are real
people behind them.

If this is the new wave of enterprise companies, I really like it. These are
people like us, that engage with us and sometimes screw up, without hiding it.
They are doing great things, and the fact that they are a bit immature is
actually great.

I'm an entrepreneur myself, I've done enterprise software my whole life, and I
always thought it's a shame that companies in this space are so distant from
their users and have such little humanity.

Looks like things are changing.

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

[1]:
[https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be4...](https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be493a05bee915474b75e/stage1/container.go)

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

------
darren0
Rocket is tied to systemd, that will definitely spawn some interesting
discussions.
[https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...](https://github.com/coreos/rocket/blob/9b79880d915f63e73891088fa3b7c32e98870914/stage1/init.go#L29)

~~~
philips
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.

~~~
darren0
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.

~~~
cbsmith
You may be shocked to discover that socket activation is actually a pretty old
idea, and can even be found on non-Linux platforms. systemd embraces it in a
pretty big way, but I can't see a problem getting the app containers to work
with one of the other socket activation models.

~~~
darren0
And you may be surprised that I ran socket activation well over 15 years ago,
so yes I'm well aware of the approach. The comment is more around the fact
that in CoreOS's post they seems to harp on the security of a daemon process
running as root that is responsible for spawning containers. What I'm saying
is that with socket activation you will essentially have that again. Rocket
can only work around it today because they have systemd as PID 1 running as
root doing the socket activation.

~~~
cbsmith
With capabilities there is no need to have privileges beyond port binding and
(possibly) userid assignment, no?

------
shykes
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 the behavior
and language in this post and in the accompanying press campaign. If you're
going to compete, just compete! Slinging mud accomplishes nothing and will
backfire in the end.

3) if anyone's interested, here is a recent exchange where I highlight
Docker's philosophy and goals. Ironically the recipient of this exchange is
the same person who posted this article. Spoiler alert: it tells a very
different story from the above article.

[https://twitter.com/solomonstre/status/530574130819923968](https://twitter.com/solomonstre/status/530574130819923968)
(this is principle 13/13, the rest should be visible via Twitter threading)

EDIT: here is the content of the above twitter thread:

1) interface to the app and developer should be standardized, and enforced
ruthlessly to prevent fragmentation

2) infrastructure should be pluggable and composable to the extreme via
drivers & plugins

3) batteries included but removable. Docker should ship a default, swappable
implementation good enough for the 80% case

4) toolkit model. Whenever it doesn't hurt the user experience, allow using
one piece of the platform without the others.

5) Developers and Ops are equally important users. It is possible and
necessary to make both happy.

6) If you buy into Docker as a platform, we'll support and help you. If you
don't, we'll support and help you :)

7) Protect the integrity of the project at all cost. No design decision in the
project has EVER been driven by revenue.

8) Docker inc. in a nutshell: provide basic infrastructure, sell services
which make the project more successful, not less.

9) Not everyone has a toaster, and not everyone gets power from a dam. But
everyone has power outlets. Docker is the outlet

10) Docker follows the same hourglass architecture as the internet or unix.
It's the opposite of "all things to all people"

11) Anyone is free to try "embrace, extend extinguish" on Docker. But
incentives are designed to make that a stupid decision

12) Docker's scope and direction are constant. It's people's understanding of
it, and execution speed, that are changing

13) If you USE Docker I should listen to your opinion on scope and design. If
you SELL Docker, you should listen to mine.

~~~
spb
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 frivolous and ill-considered, and nobody would know on what points the
fork would be aiming to distinguish itself.

This statement needs to be made, the way it _was_ made, for the same reasons
_any_ project announcement is made: it needs to announce _that_ it exists, and
_why_ it exists. It's the same as Docker's "debut" blog post(s).

Every schism needs its 95 Theses, and the odds favor the ones who can read
them, understand them, and take them into consideration.

\---

Disclaimer (re
[https://twitter.com/kenperkins/status/539528757711622145](https://twitter.com/kenperkins/status/539528757711622145)):
I make edits to my comments after posting, usually posting a line or two then
fleshing them out over time. If I make a change that conflicts with a
statement in an earlier revision, I'll note it: otherwise I'm pretty much just
composing live.

~~~
biot
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 images, uploading, downloading, and eventually even overlay
       networking, all compiled into one [big and nasty] monolithic binary running
       primarily as root [how insecure is that?] on your server. The standard
       container manifesto was removed [those flip-floppers!]. We should stop
       talking about Docker containers, and start talking about the Docker
       Platform [since we can focus attention on our efforts that way]. It is not
       becoming the simple composable building block we had envisioned [which puts
       our offerings at a disadvantage]."
    
      "We still believe in the original premise of containers that Docker
       introduced, so [unlike those silly Docker people] we are doing something
       about it."
    

Later on, they specifically say:

    
    
      "the Docker process model ... is fundamentally flawed"
      "We cannot in good faith continue to support Docker’s broken security model..."
    

All these may be valid criticisms, but even ignoring my potentially off-base
annotations it's difficult to read their announcement as anything other than
"Docker is broken and can't be fixed". It's reminiscent of political attack
ads which focus on the shortcomings of your opponent rather than the strengths
of your own platform.

~~~
vacri
_" 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.

------
bastichelaar
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 Solomon will respond to this...

~~~
philips
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.

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

~~~
cbsmith
Forking, not shelling out, no?

------
peterwwillis
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 filesystem
        Fetching the specified ACIs
        Unpacking the ACIs and copying each app into the stage2 directories
    

Questions:

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

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?

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?

~~~
cbsmith
> 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.

------
andruby
Docker has responded on their blog.
[https://news.ycombinator.com/item?id=8683276](https://news.ycombinator.com/item?id=8683276)

------
jtchang
I don't see any mud slinging.

I've used Docker. And I am looking forward to Rocket. I will use both and I
will compare without prejudice.

I personally like the idea of Rocket and am looking forward to more blog posts
comparing the two!

------
HorizonXP
As a heavy user of CoreOS and docker, I'm interested to see how this plays
out.

My problems with docker have been the security model, for which the only
recourse I've had is to use the USER keyword in my Dockerfiles. Furthermore,
networking has been a pain point, which I've had to resolve by using host
networking to access interfaces.

Let's see how rocket deals with these issues and others. I pay for CoreOS
support, so I'm glad to see that they're addressing this.

------
teekert
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 current containers (given name with current ip
addr) in them?

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)

Somehow I though CoreOS and Docker would be figuring this out together. I hope
somehow that the knowledge I now have will remain relevant, I was planning a
hosting service for sports clubs based on drupal8.

Ah well, we are at the beginning of an era, I should have expected this. I'm
very curious, who knows, the container space is far from filled, we'll be
seeing many distros. There will be Gentoo's, there will be Ubuntu's. It's
going to be nice.

~~~
etcet
> 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.

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

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

------
jambay
it's a very exciting time for Linux Containers. it's been a fun to watch the
evolution from BSD jails to lxc to docker, but the rate of innovation and
usefulness is certainly accelerating. it sure seems like rocket's approach
will be much less of a black box than docker images/registry, which should
make it much more approachable to people trying to understand what linux
containers are all about.

------
jtolds
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?

~~~
kentonv
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...](https://blog.sandstorm.io/news/2014-08-19-why-not-run-docker-
apps.html)). 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.)

~~~
jtolds
kentonv ftw

------
gexla
That's open source. The early implementation of an idea is broken. Someone
creates an alternative which fixes the problems. The alternative often doesn't
gain the same traction and the original continues as the broken dominant
implementation. But the alternative is also broken, but maybe in different
ways. As design decisions pile on, the broken spreads. In the end, we again
learn that software sucks. It will always suck. For people who don't like
reinventing the wheel (or relearning the reinvention) stick with the "good
enough" and focus on building cool stuff.

------
billconan
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?

~~~
pron
I'm interested: why do you need a container for a UI application? It would be
better for your users if it could run as a simple process.

~~~
tedreed
Not the parent poster, but needing GPU isn't necessarily the same as having
UI. You can use GPU for a variety of general purpose math (Example: mining
bitcoins, or doing stuff like Folding@Home), or for offline rendering.

~~~
billconan
yes, I understand offline rendering. I'm looking into egl off screen
rendering. But due to historical reason, the current gpu drivers (NVIDIA) need
x server.

------
justinsb
This looks very interesting - it'll be really useful to have something like
Docker that isn't so monolithic - it should be much more composable in new
ways.

------
mwcampbell
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.

~~~
philips
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.

~~~
mwcampbell
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, if it catches on.

~~~
cpuguy83
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.

~~~
ash
Yes, but the actual container image that is being distributed can only be
created by Docker. The ability to import is nice, but irrelevant here.

------
smegel
Every open source project starts off so well, then the "founders" decide they
want to be gazillionaires, and it's all downhill from there.

Sad.

~~~
pekk
The vast majority of open source projects, even if you just take the popular
ones, never end up being companies run by "founders" who want to be
gazillionaires.

------
72deluxe
Out of curiosity (as I haven't been using virtualized servers or anything for
a number of years, and used to use ESXi on the racks back then, for Windows +
Linux), is Docker that widely used?

Reading up on it, I can't see how it is massively different to OpenVZ? Given
Docker's youth, is anyone still using OpenVZ over it? And why? I'm interested.

------
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.

------
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.

------
bkeroack
Forget the interpersonal back-and-forth. My suspicion is that this is due
largely because CoreOS (the company) does not their product completely
dependent on another for-profit company's platform (Docker). It's just smart
business.

------
mbreese
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.

~~~
lambdaops
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).

~~~
mbreese
I'm not saying that Rocket will support this, I just hope it does! I really
want users to be able to spawn a container themselves without requiring
special privileges.

------
darren0
I wonder if Ubuntu LXD will participate in this?

~~~
bboreham
LXD is another competitor to Docker, as I understand it, so it will
participate in the fight, for sure.

------
retrack
Interesting what the CoreOS team is building. If the code becomes as neat as
some of the main parts of CoreOS, then this alone merits attention, we cannot
have to much security.

------
shrikrishna
The first thing that popped into my mind when I read this is
[http://xkcd.com/927/](http://xkcd.com/927/)

------
perlpimp
Great now people who were suppose to be living and working together are going
to be at odds with one another casualty being the end user. Also windows is
taking this platforming thing under their consideration too. Given their reach
and funding I think it would be smart to band together so it would not turn
out like it did in July 1993

------
meesterdude
awesome! this sounds like a great philosophical fork of docker, I'm excited to
see this grow.

------
shawn-butler
>>> While we disagree with some of the arguments and questionable rhetoric and
timing of the Rocket announcement, we hope that we can all continue to be
guided by what is best for users and developers. >>>

What does "timing" of the announcement mean?

~~~
retaliationfree
It's a well-orchestrated PR effort just days before Dockercon. The goal is to
get it into the press short-term memory, so they mention on their own in
Docker's own press announcements later in the week. It's corporate PR 101 -
pretty aggressive but effective.

------
mrmondo
Interesting that they're talking about security when CoreOS has always had
SELinux disabled?

------
codecraig
I've excited for competition but unfortunately the post seems a bit confused
in its message.

On one hand it talks about the original Docker manifesto and later says it was
removed, with the removal being a "bad" thing. However, it refers to Docker
not being simple as there are plans to add more and more features to it.

Including, "wide range of functions: building images, running images,
uploading, downloading, and eventually even overlay networking, all compiled
into one monolithic binary running primarily as root on your server". However,
in the original manifesto (that was removed), Docker announced/claimed those
features would/should exist:
[https://github.com/docker/docker/commit/0db56e6c519b19ec16c6...](https://github.com/docker/docker/commit/0db56e6c519b19ec16c6fbd12e3cee7dfa6018c5#diff-04c6e90faac2675aa89e2176d2eec7d8R12).

Competition is good but this was a bit weak in its first appearance.

------
pierreozoux
Would there be support for Socket Activation? (something that is still missing
on Docker..)

~~~
philips
Yes, we have prototyped doing socket activation with rocket already but the
patches haven't been merged. So, yes, the intention is to make socket
activation work.

------
craneca0
Interesting branding. "Rocket" is basically only one letter different from
"Docker". That can't be coincidental. Also has opposite implications - taking
off vs settling in.

~~~
pnathan
Rocket and Docker are both 6 letter words.

Can't be coincidental.

------
lgs
I'd like to highlight the following analysis:

"Why Docker and CoreOS’ split was predictable"
[http://bit.ly/1zMLYSt](http://bit.ly/1zMLYSt)

------
preillyme
Docker has a new competitor (wired.com)
[https://news.ycombinator.com/item?id=8682794](https://news.ycombinator.com/item?id=8682794)

------
medhacker
For those who are already familiar with the Rocket offering, can you ELI5 what
the differences are and what they may mean for container portability?

------
nstott
Congrats on the release, I look forward to seeing what you guys do with this

------
Wlinuxhv
really marked of your discussion to me ,a white to what is UNIX philosophy
,either the dockers !Guys from China longing for theway of LINUX or UNIX
culture!

------
gfunk911
Any plans to "support" Dockerfiles in any way?

------
make3
coreOs is the name of the apple operating systems department. feels weird to
read that around

------
lgas
Thank god.

------
xjlixd
good.

------
api
This is how Linux fragments, and ultimately dies as the Linux we know.

I'm not really making a value judgement, just an observation.

~~~
loudmax
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.

~~~
SEJeff
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](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.

~~~
mikerichards
Interesting, I had never hear of (I)Tron

