20 ms·

CoreOS is building a container runtime, Rocket

bketelsen 12y ago
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.
- cpuguy83 12y ago
  This is exactly the model being proposed in Docker.
  - mmcclure 12y ago
    I think this was the original model proposed by Docker. What we have now is (as other posters have mentioned), a Docker organization reasonably bent towards creating value for their investors, which means they need to start building things that, you know, make money. To clarify, I don't think there's anything inherently wrong with what Docker's doing, but it is at odds with an entirely open, pluggable system. It doesn't make any sense for their business model to truly make it easy to just use their containers and none of the revenue-generating offerings.
    - gtirloni 12y ago
      I've not been following the discussions but if it's such a critical piece of the whole puzzle and it's in everybody's interest that it remains open, wouldn't a foundation, rather than a single private company, be the best venue for leading the project forward?
      - FooBarWidget 12y ago
        Then how do you fund that foundation? Good developers cost a ton of money. Marketing, organizing events, organizing conferences etc also costs a ton of money. I think something like Docker, especially given its growth and adoption rate, never would have been possible without VC funding. VCs wouldn't invest in a non-profit foundation.
- justinsb 12y ago
  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 12y ago
    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.
    - bananaoomarang 12y ago
      I think this is probably more indicative of the issue that Future Docker would like to be a CoreOS-competing platform, and has been edging towards that state. This is CoreOS' natural bounceback from that.
    - spb 12y ago
      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 12y ago
        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
justinsb 12y ago
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.
jambay 12y ago
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.
pierreozoux 12y ago
Would there be support for Socket Activation? (something that is still missing on Docker..)
- philips 12y ago
  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.
- thebeardisred 12y ago
  Absolutely!
mbreese 12y ago
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.
- carllerche 12y ago
  This would only be possible on very new linux kernels (that provide user namespacing)
- lambdaops 12y ago
  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 12y ago
    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.
otoburb 12y ago
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 12y ago
  > 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.
  - otoburb 12y ago
    Regardless of whether your comment was lightly sarcastic or not, I agree that the Docker VMWare[1] & Microsoft partnership announcements may have been conditional upon a committed Docker roadmap outlining some or all of the features that others (such as CoreOS) may feel should be broken out. Typically larger ecosystem players want to be assured that your offering will have a clearly defined role within their existing ecosystem that plays to your core brand and technical competency. [1] http://www.forbes.com/sites/benkepes/2014/08/25/vmware-gets-docker-love-announces-a-raft-of-integrations-and-partnerships/ http://www.forbes.com/sites/benkepes/2014/08/25/vmware-gets-...
  - outside1234 12y ago
    Wow, that is a random jump of logic. Answer: no.
  - krschultz 12y ago
    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
ossreality 12y ago
Woohoo! Docker is going off the rails trying to roll container orchestration into it. Kubernetes is arguably a "larger" project than docker, and docker is out of their depth thinking they can just roll such a feature in.
api 12y ago
This is how Linux fragments, and ultimately dies as the Linux we know. I'm not really making a value judgement, just an observation.
- gtaylor 12y ago
  That may be a little overly dramatic. There have been failed fragments/forks/derivatives, but there have also been some sweeping successes. It's too early to foretell the fate of Rocket. Containers are getting lots of attention, so I'm actually pretty happy to look at this as a potentially rewarding experiment. Worst case, it fails and we keep using Docker (or whatever else springs up).
- krschultz 12y ago
  There were many VM engines, now there are a few. I imagine the same thing will happen with container technology. Generally 1 technology stands out, then things fragment, then things coalesce into a tiny handful of solid solutions. Docker may or may not be the container engine that lasts a long time. There is a reason they raised a bunch of money. Clearly containers are going to be big, but is Docker the one that goes on to be dominant? Docker is trying through building features & biz dev, but it's far from over.
- tree_of_item 12y ago
  How does additional container management software fragment GNU/Linux?
  - api 12y ago
    Think a few steps ahead. These aren't really containers. They're giant statically linked binaries, more or less. The actual operating system is now just a VM host for running containerized giant WIMPs (weakly interacting massive programs). Fast-forward a few years and the host can wither and die and be replaced with a proprietary or custom/fragmented management layer. Linux survives only as an internal pseudo-OS within each mega-binary "container." Edit: what I was really getting at was that these technologies are patches for the inadequacy of the OS. The fact that we need containers at all stems from the difficulty of managing software installations, configuration, etc on the actual operating system.
meesterdude 12y ago
awesome! this sounds like a great philosophical fork of docker, I'm excited to see this grow.
sentiental 12y ago
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 12y ago
  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 12y ago
    I think it's also crucial users have more than one viable container option.
- altcognito 12y ago
  > I have been concerned that Docker's scope was expanding too far for a while now What features were recently introduced that it increased Docker's scope?
  - lclarkmichalek 12y ago
    Talk of Docker cluster, which might include a network overlay layer a la weave
lgas 12y ago
Thank god.
darren0 12y ago
I wonder if Ubuntu LXD will participate in this?
- bboreham 12y ago
  LXD is another competitor to Docker, as I understand it, so it will participate in the fight, for sure.
HorizonXP 12y ago
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.
bastichelaar 12y ago
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 12y ago
  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 12y ago
    That's really too bad, because the only way for me to spawn containers programmatically is shelling out.
    - cbsmith 12y ago
      Forking, not shelling out, no?
  - thockingoog 12y ago
    This was a key principle of LMCTFY, too, FWIW.
  - deleted 12y ago
    [deleted]
  - fss 12y ago
    In case you change your mind, I just created this awesome project: https://github.com/fsouza/go-rocketclient https://github.com/fsouza/go-rocketclient
- 12y ago
jtolds 12y ago
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 12y ago
  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-apps.html https://blog.sandstorm.io/news/2014-08-19-why-not-run-docker...). 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 12y ago
    kentonv ftw
vito 12y ago
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 12y ago
  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.
  - vito 12y ago
    Yep, setuid would make sense. Hopefully that's how people end up using it. (i.e. Rocket should document or distribute it that way)
  - makomk 12y ago
    > 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. Wrong. With a server, the only thing an attacker has control over is its input. With a setuid-root binary, they still have control over its input, but they also have control over the entire environment under which it executes, including many things that developers generally assume an attacker can't control. Setuid binaries are incredibly scary from a security perspective and much harder to get right than servers.
  - Rapzid 12y ago
    "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.
darren0 12y ago
Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e73891088fa3b7c32e98870914/stage1/init.go#L29 https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...
- robszumski 12y ago
  The great part of having a spec separate from the runtime is that Rocket can use systemd, but other compatible tools won't have to.
  - tknaup 12y ago
    This part is super important for Rocket support in Mesos and other things that run containers.
- philips 12y ago
  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.
  - teacup50 12y ago
    What about non-Linux platforms (FreeBSD, Mac OS X with a kext)? One thing that I believe Docker has failed at is in taking a purely declarative approach to image definition; rather than specifying the packages that are assembled/inserted to create the container, Docker ships around non-portable Linux binaries.
    - tachion 12y ago
      I second that. At the begining Docker people were mentioning adding FreeBSD Jails support, what seemed to me an awesome thing, a platform independent containerization middleware, but recently they just seemt to forget about it and they're doing only linux-centric things - what a shame.
preillyme 12y ago
Docker has a new competitor (wired.com) https://news.ycombinator.com/item?id=8682794 https://news.ycombinator.com/item?id=8682794
mwcampbell 12y ago
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 12y ago
  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 12y ago
    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.
    - jzxcv 12y ago
      > 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. Yep, this is _exactly_ one of our design goals. ACIs are trivially buildable and inspectable with standard Unix tools.
    - cpuguy83 12y ago
      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 12y ago
billconan 12y ago
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 12y ago
  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.
  - billconan 12y ago
    I actually need gpu, not the ui. I need it to do scientific computation. Video streaming service is another case. gpu has better video encoding capabilities. I previously heard that docker has trouble loading device drivers.
  - tedreed 12y ago
    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 12y ago
      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.
- pipeep 12y ago
  Certainly. The kernel can simply pass through the device, although you lose some of the security of containerization that way. There may be issues with multiple containers sharing the same GPU though.
  - billconan 12y ago
retrack 12y ago
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.
yannisp 12y ago
Docker just posted a blog response http://blog.docker.com/2014/12/initial-thoughts-on-the-rocket-announcement/ http://blog.docker.com/2014/12/initial-thoughts-on-the-rocke...
- cheshire137 12y ago
  Hacker News thread: https://news.ycombinator.com/item?id=8683276 https://news.ycombinator.com/item?id=8683276
- lew21 12y ago
  Thanks, Docker team, this made me 100% sure I support Rocket.
andruby 12y ago
Docker has responded on their blog. https://news.ycombinator.com/item?id=8683276 https://news.ycombinator.com/item?id=8683276
pron 12y ago
Looking at the code[1] this seems to be a simple wrapper around systemd-nspawn[2] [1]: https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be493a05bee915474b75e/stage1/container.go https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be4... [2]: http://lwn.net/Articles/572957/ http://lwn.net/Articles/572957/
tedchs 12y ago
Has libcontainer[1] been considered as a minimal Docker alternative? [1] https://github.com/docker/libcontainer https://github.com/docker/libcontainer
mrmondo 12y ago
Interesting that they're talking about security when CoreOS has always had SELinux disabled?
bjt 12y ago
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 12y ago
  Yes, the app-container spec has the concept of dependent filesets. See: 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 https://github.com/coreos/rocket/blob/master/app-container/S... What do you think of the filesets concept?
  - bjt 12y ago
    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 12y ago
      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.
peterwwillis 12y ago
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 12y ago
  > 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.
shykes 12y ago
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 12y ago
  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.
bkeroack 12y ago
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.
teekert 12y ago
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 12y ago
  > 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.
gfunk911 12y ago
Any plans to "support" Dockerfiles in any way?
craneca0 12y ago
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.
- ash 12y ago
  And if you read "Docker" backwards you'll get "Rocket". Somewhat.
- pnathan 12y ago
  Rocket and Docker are both 6 letter words. Can't be coincidental.
deleted 12y ago
[deleted]
jtchang 12y ago
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!
smegel 12y ago
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 12y ago
  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.
nstott 12y ago
Congrats on the release, I look forward to seeing what you guys do with this
make3 12y ago
coreOs is the name of the apple operating systems department. feels weird to read that around
codecraig 12y ago
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/0db56e6c519b19ec16c6fbd12e3cee7dfa6018c5#diff-04c6e90faac2675aa89e2176d2eec7d8R12 https://github.com/docker/docker/commit/0db56e6c519b19ec16c6.... Competition is good but this was a bit weak in its first appearance.
_mikz 12y ago
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 12y ago
  > Even stupidest things like allowing to have more dockerfiles in one folder. Wow. That issue has been open for a long time.
  - drewcrawford 12y ago
    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.
    - darkarmani 12y ago
      I saw your articulate response in that thread. Thank you for that response. I don't need multiple dockerfiles right now, but if i invest more into docker, I will. I think your responses might have convinced shykes that the need won't be going away. There was a similar disconnect on data volumes a while ago that took some convincing before the discussion moved forward. It has always been trivial in OpenVZ to bind mount into a container (ie: share a very large read-only mount between containers).
    - narrowrail 12y ago
      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-39763037 https://github.com/docker/docker/issues/2112#issuecomment-39... It gets quite interesting, and it's still going 14 months later...
degio 12y ago
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.
gexla 12y ago
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.
nwmcsween 12y ago
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 12y ago
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.
medhacker 12y ago
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?
xjlixd 12y ago
good.
perlpimp 12y ago
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
72deluxe 12y ago
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.
shrikrishna 12y ago
The first thing that popped into my mind when I read this is http://xkcd.com/927/ http://xkcd.com/927/
lgs 12y ago
I'd like to highlight the following analysis: "Why Docker and CoreOS’ split was predictable" http://bit.ly/1zMLYSt http://bit.ly/1zMLYSt
shawn-butler 12y ago
>>> 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 12y ago
  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.
Wlinuxhv 12y ago
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!
Wlinuxhv 12y ago
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!

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.

cpuguy83 12y ago
This is exactly the model being proposed in Docker.
- mmcclure 12y ago
  I think this was the original model proposed by Docker. What we have now is (as other posters have mentioned), a Docker organization reasonably bent towards creating value for their investors, which means they need to start building things that, you know, make money. To clarify, I don't think there's anything inherently wrong with what Docker's doing, but it is at odds with an entirely open, pluggable system. It doesn't make any sense for their business model to truly make it easy to just use their containers and none of the revenue-generating offerings.
  - gtirloni 12y ago
    I've not been following the discussions but if it's such a critical piece of the whole puzzle and it's in everybody's interest that it remains open, wouldn't a foundation, rather than a single private company, be the best venue for leading the project forward?
    - FooBarWidget 12y ago
      Then how do you fund that foundation? Good developers cost a ton of money. Marketing, organizing events, organizing conferences etc also costs a ton of money. I think something like Docker, especially given its growth and adoption rate, never would have been possible without VC funding. VCs wouldn't invest in a non-profit foundation.
justinsb 12y ago
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 12y ago
  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.
  - bananaoomarang 12y ago
    I think this is probably more indicative of the issue that Future Docker would like to be a CoreOS-competing platform, and has been edging towards that state. This is CoreOS' natural bounceback from that.
  - spb 12y ago
    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 12y ago
      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

justinsb 12y ago

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.

jambay 12y ago

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.

pierreozoux 12y ago

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

philips 12y ago
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.
thebeardisred 12y ago
Absolutely!

mbreese 12y ago

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.

carllerche 12y ago
This would only be possible on very new linux kernels (that provide user namespacing)
lambdaops 12y ago
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 12y ago
  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.

otoburb 12y ago

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 12y ago
> 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.
- otoburb 12y ago
  Regardless of whether your comment was lightly sarcastic or not, I agree that the Docker VMWare[1] & Microsoft partnership announcements may have been conditional upon a committed Docker roadmap outlining some or all of the features that others (such as CoreOS) may feel should be broken out. Typically larger ecosystem players want to be assured that your offering will have a clearly defined role within their existing ecosystem that plays to your core brand and technical competency. [1] http://www.forbes.com/sites/benkepes/2014/08/25/vmware-gets-docker-love-announces-a-raft-of-integrations-and-partnerships/ http://www.forbes.com/sites/benkepes/2014/08/25/vmware-gets-...
- outside1234 12y ago
  Wow, that is a random jump of logic. Answer: no.
- krschultz 12y ago
  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

ossreality 12y ago

Woohoo! Docker is going off the rails trying to roll container orchestration into it. Kubernetes is arguably a "larger" project than docker, and docker is out of their depth thinking they can just roll such a feature in.

api 12y ago

This is how Linux fragments, and ultimately dies as the Linux we know. I'm not really making a value judgement, just an observation.

gtaylor 12y ago
That may be a little overly dramatic. There have been failed fragments/forks/derivatives, but there have also been some sweeping successes. It's too early to foretell the fate of Rocket. Containers are getting lots of attention, so I'm actually pretty happy to look at this as a potentially rewarding experiment. Worst case, it fails and we keep using Docker (or whatever else springs up).
krschultz 12y ago
There were many VM engines, now there are a few. I imagine the same thing will happen with container technology. Generally 1 technology stands out, then things fragment, then things coalesce into a tiny handful of solid solutions. Docker may or may not be the container engine that lasts a long time. There is a reason they raised a bunch of money. Clearly containers are going to be big, but is Docker the one that goes on to be dominant? Docker is trying through building features & biz dev, but it's far from over.
tree_of_item 12y ago
How does additional container management software fragment GNU/Linux?
- api 12y ago
  Think a few steps ahead. These aren't really containers. They're giant statically linked binaries, more or less. The actual operating system is now just a VM host for running containerized giant WIMPs (weakly interacting massive programs). Fast-forward a few years and the host can wither and die and be replaced with a proprietary or custom/fragmented management layer. Linux survives only as an internal pseudo-OS within each mega-binary "container." Edit: what I was really getting at was that these technologies are patches for the inadequacy of the OS. The fact that we need containers at all stems from the difficulty of managing software installations, configuration, etc on the actual operating system.

meesterdude 12y ago

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

sentiental 12y ago

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 12y ago
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 12y ago
  I think it's also crucial users have more than one viable container option.
altcognito 12y ago
> I have been concerned that Docker's scope was expanding too far for a while now What features were recently introduced that it increased Docker's scope?
- lclarkmichalek 12y ago
  Talk of Docker cluster, which might include a network overlay layer a la weave

lgas 12y ago

Thank god.

darren0 12y ago

I wonder if Ubuntu LXD will participate in this?

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

HorizonXP 12y ago

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.

bastichelaar 12y ago

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 12y ago
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 12y ago
  That's really too bad, because the only way for me to spawn containers programmatically is shelling out.
  - cbsmith 12y ago
    Forking, not shelling out, no?
- thockingoog 12y ago
  This was a key principle of LMCTFY, too, FWIW.
- deleted 12y ago
  [deleted]
- fss 12y ago
  In case you change your mind, I just created this awesome project: https://github.com/fsouza/go-rocketclient https://github.com/fsouza/go-rocketclient
12y ago

jtolds 12y ago

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 12y ago
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-apps.html https://blog.sandstorm.io/news/2014-08-19-why-not-run-docker...). 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 12y ago
  kentonv ftw

vito 12y ago

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 12y ago
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.
- vito 12y ago
  Yep, setuid would make sense. Hopefully that's how people end up using it. (i.e. Rocket should document or distribute it that way)
- makomk 12y ago
  > 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. Wrong. With a server, the only thing an attacker has control over is its input. With a setuid-root binary, they still have control over its input, but they also have control over the entire environment under which it executes, including many things that developers generally assume an attacker can't control. Setuid binaries are incredibly scary from a security perspective and much harder to get right than servers.
- Rapzid 12y ago
  "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.

darren0 12y ago

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

robszumski 12y ago
The great part of having a spec separate from the runtime is that Rocket can use systemd, but other compatible tools won't have to.
- tknaup 12y ago
  This part is super important for Rocket support in Mesos and other things that run containers.
philips 12y ago
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.
- teacup50 12y ago
  What about non-Linux platforms (FreeBSD, Mac OS X with a kext)? One thing that I believe Docker has failed at is in taking a purely declarative approach to image definition; rather than specifying the packages that are assembled/inserted to create the container, Docker ships around non-portable Linux binaries.
  - tachion 12y ago
    I second that. At the begining Docker people were mentioning adding FreeBSD Jails support, what seemed to me an awesome thing, a platform independent containerization middleware, but recently they just seemt to forget about it and they're doing only linux-centric things - what a shame.

preillyme 12y ago

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

mwcampbell 12y ago

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 12y ago
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 12y ago
  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.
  - jzxcv 12y ago
    > 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. Yep, this is _exactly_ one of our design goals. ACIs are trivially buildable and inspectable with standard Unix tools.
  - cpuguy83 12y ago
    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 12y ago

billconan 12y ago

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 12y ago
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.
- billconan 12y ago
  I actually need gpu, not the ui. I need it to do scientific computation. Video streaming service is another case. gpu has better video encoding capabilities. I previously heard that docker has trouble loading device drivers.
- tedreed 12y ago
  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 12y ago
    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.
pipeep 12y ago
Certainly. The kernel can simply pass through the device, although you lose some of the security of containerization that way. There may be issues with multiple containers sharing the same GPU though.
- billconan 12y ago

retrack 12y ago

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.

yannisp 12y ago

Docker just posted a blog response http://blog.docker.com/2014/12/initial-thoughts-on-the-rocket-announcement/ http://blog.docker.com/2014/12/initial-thoughts-on-the-rocke...

cheshire137 12y ago
Hacker News thread: https://news.ycombinator.com/item?id=8683276 https://news.ycombinator.com/item?id=8683276
lew21 12y ago
Thanks, Docker team, this made me 100% sure I support Rocket.

andruby 12y ago

Docker has responded on their blog. https://news.ycombinator.com/item?id=8683276 https://news.ycombinator.com/item?id=8683276

pron 12y ago

Looking at the code[1] this seems to be a simple wrapper around systemd-nspawn[2] [1]: https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be493a05bee915474b75e/stage1/container.go https://github.com/coreos/rocket/blob/9ae5a199cce878f35a3be4... [2]: http://lwn.net/Articles/572957/ http://lwn.net/Articles/572957/

tedchs 12y ago

Has libcontainer[1] been considered as a minimal Docker alternative? [1] https://github.com/docker/libcontainer https://github.com/docker/libcontainer

mrmondo 12y ago

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

bjt 12y ago

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 12y ago
Yes, the app-container spec has the concept of dependent filesets. See: 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 https://github.com/coreos/rocket/blob/master/app-container/S... What do you think of the filesets concept?
- bjt 12y ago
  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 12y ago
    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.

peterwwillis 12y ago

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 12y ago
> 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.

shykes 12y ago

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 12y ago
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.

bkeroack 12y ago

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.

teekert 12y ago

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 12y ago
> 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.

gfunk911 12y ago

Any plans to "support" Dockerfiles in any way?

craneca0 12y ago

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.

ash 12y ago
And if you read "Docker" backwards you'll get "Rocket". Somewhat.
pnathan 12y ago
Rocket and Docker are both 6 letter words. Can't be coincidental.

deleted 12y ago

[deleted]

jtchang 12y ago

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!

smegel 12y ago

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 12y ago
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.

nstott 12y ago

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

make3 12y ago

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

codecraig 12y ago

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/0db56e6c519b19ec16c6fbd12e3cee7dfa6018c5#diff-04c6e90faac2675aa89e2176d2eec7d8R12 https://github.com/docker/docker/commit/0db56e6c519b19ec16c6.... Competition is good but this was a bit weak in its first appearance.

_mikz 12y ago

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 12y ago
> Even stupidest things like allowing to have more dockerfiles in one folder. Wow. That issue has been open for a long time.
- drewcrawford 12y ago
  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.
  - darkarmani 12y ago
    I saw your articulate response in that thread. Thank you for that response. I don't need multiple dockerfiles right now, but if i invest more into docker, I will. I think your responses might have convinced shykes that the need won't be going away. There was a similar disconnect on data volumes a while ago that took some convincing before the discussion moved forward. It has always been trivial in OpenVZ to bind mount into a container (ie: share a very large read-only mount between containers).
  - narrowrail 12y ago
    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-39763037 https://github.com/docker/docker/issues/2112#issuecomment-39... It gets quite interesting, and it's still going 14 months later...

degio 12y ago

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.

gexla 12y ago

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.

nwmcsween 12y ago

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 12y ago

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.

medhacker 12y ago

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?

xjlixd 12y ago

good.

perlpimp 12y ago

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

72deluxe 12y ago

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.

shrikrishna 12y ago

The first thing that popped into my mind when I read this is http://xkcd.com/927/ http://xkcd.com/927/

lgs 12y ago

I'd like to highlight the following analysis: "Why Docker and CoreOS’ split was predictable" http://bit.ly/1zMLYSt http://bit.ly/1zMLYSt

shawn-butler 12y ago

>>> 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 12y ago
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.

Wlinuxhv 12y ago

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!

Wlinuxhv 12y ago

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!