Interesting takeaways from the post:<p>* Despite Brandon Philips (CoreOS CTO) serving on the Docker governance board, Docker has aggressively expanded their scope well beyond their original container manifesto.<p>* 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."<p>* CoreOS reaffirms their original operating model of being capable of running their infrastructure on and with Docker.<p>* Rocket is CoreOS's answer to stay true to the "simple composable building block" mantra.
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.<p>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.
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.<p>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.<p>Question though: Does Rocket have any concept of the image layering that Docker does? That still seems to me like a killer feature.<p>[1] <a href="https://bitbucket.org/yougov/velociraptor/" rel="nofollow">https://bitbucket.org/yougov/velociraptor/</a>
[2] <a href="https://github.com/docker/docker/issues/503" rel="nofollow">https://github.com/docker/docker/issues/503</a>
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.<p>Offering strace logs to developers without feedback and finally it was fixed by someone from outside the project. <a href="https://github.com/docker/docker/issues/7348" rel="nofollow">https://github.com/docker/docker/issues/7348</a><p>Allocating ports pops now and then every odd docker release: <a href="https://github.com/docker/docker/issues/8714" rel="nofollow">https://github.com/docker/docker/issues/8714</a><p>Even stupidest things like allowing to have more dockerfiles in one folder.
<a href="https://github.com/docker/docker/issues/2112" rel="nofollow">https://github.com/docker/docker/issues/2112</a><p>Docker has own agenda and it is clearer and clearer.
Docker just posted a blog response<p><a href="http://blog.docker.com/2014/12/initial-thoughts-on-the-rocket-announcement/" rel="nofollow">http://blog.docker.com/2014/12/initial-thoughts-on-the-rocke...</a>
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.
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?<p>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.
I found reading these comments very interesting.<p>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".<p>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.<p>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.<p>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.<p>Looks like things are changing.
Looking at the code[1] this seems to be a simple wrapper around systemd-nspawn[2]<p>[1]: <a href="https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be493a05bee915474b75e/stage1/container.go" rel="nofollow">https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be4...</a><p>[2]: <a href="http://lwn.net/Articles/572957/" rel="nofollow">http://lwn.net/Articles/572957/</a>
Rocket is tied to systemd, that will definitely spawn some interesting discussions. <a href="https://github.com/coreos/rocket/blob/9b79880d915f63e73891088fa3b7c32e98870914/stage1/init.go#L29" rel="nofollow">https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...</a>
Hi, I created Docker. I have exactly 3 things to say:<p>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.<p>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.<p>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.<p><a href="https://twitter.com/solomonstre/status/530574130819923968" rel="nofollow">https://twitter.com/solomonstre/status/530574130819923968</a> (this is principle 13/13, the rest should be visible via Twitter threading)<p>EDIT: here is the content of the above twitter thread:<p>1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation<p>2) infrastructure should be pluggable and composable to the extreme via drivers & plugins<p>3) batteries included but removable. Docker should ship a default, swappable implementation good enough for the 80% case<p>4) toolkit model. Whenever it doesn't hurt the user experience, allow using one piece of the platform without the others.<p>5) Developers and Ops are equally important users. It is possible and necessary to make both happy.<p>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 :)<p>7) Protect the integrity of the project at all cost. No design decision in the project has EVER been driven by revenue.<p>8) Docker inc. in a nutshell: provide basic infrastructure, sell services which make the project more successful, not less.<p>9) Not everyone has a toaster, and not everyone gets power from a dam. But everyone has power outlets. Docker is the outlet<p>10) Docker follows the same hourglass architecture as the internet or unix. It's the opposite of "all things to all people"<p>11) Anyone is free to try "embrace, extend extinguish" on Docker. But incentives are designed to make that a stupid decision<p>12) Docker's scope and direction are constant. It's people's understanding of it, and execution speed, that are changing<p>13) If you USE Docker I should listen to your opinion on scope and design. If you SELL Docker, you should listen to mine.
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...
So here's my take on this. From the docs on github:<p><pre><code> 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
</code></pre>
Questions:<p>Don't all these steps seem like a lot of disk, cpu and system-dependency-intense operations just to run an application?<p>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?<p>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?
Docker has responded on their blog. <a href="https://news.ycombinator.com/item?id=8683276" rel="nofollow">https://news.ycombinator.com/item?id=8683276</a>
I don't see any mud slinging.<p>I've used Docker. And I am looking forward to Rocket. I will use both and I will compare without prejudice.<p>I personally like the idea of Rocket and am looking forward to more blog posts comparing the two!
As a heavy user of CoreOS and docker, I'm interested to see how this plays out.<p>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.<p>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.
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?<p>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)<p>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.<p>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.
Has libcontainer[1] been considered as a minimal Docker alternative?<p>[1] <a href="https://github.com/docker/libcontainer" rel="nofollow">https://github.com/docker/libcontainer</a>
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.
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?
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.
This may be a noob question,<p>I'm looking into using containers for ui applications. I need to access GPU within the application. is this doable with Rocket or Docker?<p>Also does Rocket have to be used with CoreOS?
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.
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.
Every open source project starts off so well, then the "founders" decide they want to be gazillionaires, and it's all downhill from there.<p>Sad.
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?<p>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.
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.
I fail to see how Rocket is going to end any better than Docker.<p>It's already tied to systemd-nspawn (though arguably you could make this pluggable to support other process babysitters).<p>Infact, Rocket as it stands is just a wrapper around systemd-nspawn and little else.<p>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.<p>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.<p>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.
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.
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.
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.
The first thing that popped into my mind when I read this is <a href="http://xkcd.com/927/" rel="nofollow">http://xkcd.com/927/</a>
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
>>>
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.
>>><p>What does "timing" of the announcement mean?
I've excited for competition but unfortunately the post seems a bit confused in its message.<p>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.<p>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: <a href="https://github.com/docker/docker/commit/0db56e6c519b19ec16c6fbd12e3cee7dfa6018c5#diff-04c6e90faac2675aa89e2176d2eec7d8R12" rel="nofollow">https://github.com/docker/docker/commit/0db56e6c519b19ec16c6...</a>.<p>Competition is good but this was a bit weak in its first appearance.
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.
I'd like to highlight the following analysis:<p>"Why Docker and CoreOS’ split was predictable" <a href="http://bit.ly/1zMLYSt" rel="nofollow">http://bit.ly/1zMLYSt</a>
Docker has a new competitor (wired.com)
<a href="https://news.ycombinator.com/item?id=8682794" rel="nofollow">https://news.ycombinator.com/item?id=8682794</a>
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!