Docker 0.8: Quality, new builder features, btrfs, OSX support

I've followed and refollowed those steps on OS X 10.9.1, but this is what happens:

  » docker version
  Client version: 0.8.0
  Go version (client): go1.2
  Git commit (client): cc3a8c8
  2014/02/05 23:10:55 unexpected EOF

Yet the docker server is definitely up:

  docker@boot2docker:~$ docker version
  Client version: 0.8.0
  Go version (client): go1.2
  Git commit (client): cc3a8c8
  Server version: 0.8.0
  Git commit (server): cc3a8c8
  Go version (server): go1.2
  Last stable version: 0.8.0

Tried both `export DOCKER_HOST=tcp://` and `export DOCKER_HOST=localhost` (as per boot2docker README), before re-init.

the first parts are right (though i don't know how accurate) and could certainly be improved with tooling.

testing will come with time.

with raidz sure it's great but the vdevs being immutable is really rather annoying. the way btrfs handles multi device stuff is significantly better (replication is not between 2 devices but closer to the file (it allocates a chunk of space and decides where to put the other replica in the pool).

though i wish the erasure coding stuff would land faster.

btrfs has had send\receive for a while.

I haven't needed to dig into the btrfs man pages yet so can't common on how accurate this is.

btrfs also uses barriers log devices and cache devices are awesome. i hope btrfs adds them.

the block device thing is a limitation of btrfs and annoys me though i've slowly moved to just having files. (though in anything largish i would probably be moving to a distributed fs anyway)

the sharing stuff is good but i think that's a tooling issue not an fs issue.

btrfs has an out of band dedup allowing you to run periodic dedup without having the memory penalty of live dedup (though costing disk)

Oracle acquired Sun, so they could have solved it by just choose another license moving forward. One gotcha is the ZFS (Solaris core) team vehemently resisted anything GPL-compatible. Something like a BSD license would make the most commercial sense. Instead, Oracle has a consistent pattern of losing community goodwill that loses customer interest and pushes developers to fork.

does btrfs have anything comparable to raidz3?

Unfortunately Docker prevents hosting environments from employing some of the most potent security mitigations added to Linux recently.

You cannot treat a docker container like a virtual machine – code running in the container has almost unfettered access to the parent kernel, and the millions of lines of often-buggy C that involves. For example with the right kernel configuration, this approach leaves the parent machine vulnerable to the recent x86_32 vulnerability (http://seclists.org/oss-sec/2014/q1/187) and many similar bugs in its class.

The algorithms in the running kernel are far more exposed too - instead of managing a single process+virtual network+memory area, all the child's resources are represented concretely in the host kernel, including its filesystem. For example, this vastly increases the likelihood that a child could trigger an unpatched DoS in the host, e.g. the directory hashing attacks that have effected nearly every filesystem implementation at some point (including btrfs as recently as 2012).

The containers code in Linux is also so new that trivial security bugs are being found in it all the time – particularly in sysfs and procfs. I don't have a link right now, though LWN wrote about one a few weeks back.

While virtual machines are no security panacea, they diverge in what classes of bugs they can be affected by. Recent Qemu/libvirt supports running under seccomp.. ensuring even if the VM emulator is compromised, the host kernel's exposure remains drastically limited. Unlike qemu, you simply can't apply seccomp to a container without massively reducing its usefulness, or using a seccomp policy so liberal that it becomes impotent.

You could use seccomp with Docker by nesting it within a VM, but at that point Docker loses most of its value (and could be trivially replaced by a shell script with a cute UI).

Finally when a bug is discovered and needs to be patched, or a machine needs to be taken out of service, there is presently no easy way to live-migrate a container to another machine. The most recent attempt (out of I think 3 or 4 now) to add this ability to Linux appears to have stalled completely.

As a neat system for managing dev environments locally, it sounds great. As a boundary between mutually untrusted pieces of code, there are far better solutions, especially when the material difference in approaches amounts to a few seconds of your life at best, and somewhere south of 100mb in RAM.