[andrewguenther]

Documentation is not the primary problem with Docker that Rocket is trying to solve. The issue is Docker's process model, which is fundamental to the way it is built. Docker seems to have taken the opinion that the best way to solve the problems with their process model is not to fix it, but add more features to the kernel to force it to work. Rocket went with the fix it approach and simply started over.

Also, would you mind clarifying what you mean by "daemonless mode"?

[wmf]

By daemonless I mean making "docker run" be able to directly fork a container without needing dockerd. Like how "rkt run" works.

[mpasternacki]

What's interesing is that Docker used to run (almost) this way some time ago. I guess the daemonless mode won't fly with managing communication (iptables NAT, IP assignment, linked containers, etc).

[shykes]

Yeah we used to call it "standalone mode", it was pretty neat but really confused users (it would auto-detect whether to go daemon mode or not, so behavior became contextual and hard to troubleshoot).

Yes, managing communication or other centralized resources is harder that way which is a challenge for "embedded Docker". Rocket does not have this problem because it relies on systemd to manage all this centrally under the hood. So you get "daemonless" as long as you sweep everything under the giant systemd rug :)

[mpasternacki]

It doesn't need to be systemd, and that's the beauty of Rocket's design: it is composed of individual, well defined pieces with precise boundaries and areas of responsibility. As I wrote, my main practical concern now is to get something container-like working on FreeBSD. Docker is useless here unless it's wholly ported; Rocket is useful even if I don't use its code and go with (even partial) implementation of the spec.

From my practical POV, my options now are: port Docker (NOPE), reimplement Docker (NOPE GOD WHY), port Rocket (Maybe?), reuse spec and pieces of Rocket's code in my own opinionated NIH plumbing (Hell yeah, somebody did the thinking part for me! The spec is usable!), or write own opinionated NIH plumbing from scratch (why would I if there's a decent spec to lean on?).

[Alupis]

This is truly why Rocket is so interesting. The App Container Spec is what is missing from Docker. They had their chance to implement a common universal spec which others could implement independently, but didn't do so. Now CoreOS is picking up the ball and running. I don't see any option for Docker other than to work with CoreOS to form this universal specification, or to adhere to the specification after it's been finalized.

[wmf]

Often people want to run without dockerd because they want to use a different orchestration system (systemd, OpenStack, etc.) and usually that system sets up the networking and such.