CoreOS is building a container runtime, Rocket

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

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/ [2] https://github.com/docker/docker/issues/503

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?

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

Talk of Docker cluster, which might include a network overlay layer a la weave