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

Post by [deleted] » Thu, Feb 06, 2014, 1:35 AM UTC

ashleyw wrote: post #62

shykes wrote: post #3

Just to clarify on the OSX support: obviously we did not magically get Darwin to support linux containers. But we put together the easiest possible way to run Linux containers on a Mac without depending on another machine. We do this by combining (1) docker in "client mode", which connects to (2) a super-lightweight linux VM using boot2docker. The details are on http://docs.docker.io/en/latest/installation/mac/

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 G…

Post by shykes » Thu, Feb 06, 2014, 1:47 AM UTC

FooBarWidget wrote: post #50

derefr wrote: post #27

Earlier quoted context omitted.

Personally, when I read "OSX support", I thought that meant that there would now be containers with Darwin-ABI binaries inside them. So on Linux, you'd use cgroups for Linux-ABI binaries and a VM for Darwin-ABI, just as on OSX you use a VM for Linux-ABI (and presumably would use the OSX sandbox API for Darwin-ABI containers.) This "native sandboxing for own-ABI if available, VM if not, and VM for everything else" app…

Going that way would dilute Docker's value. Docker's promise is that you can build a container and it will always work; it won't mysteriously break in production or giving you installation headaches. To do that, your development environment has to be as close to the production environment as possible. Having a totally different ABI doesn't help with that goal.

Post by tianon » Thu, Feb 06, 2014, 2:10 AM UTC

lengads wrote: post #28

tianon wrote: post #21

Earlier quoted context omitted.

Or even bare metal. Personally, I extract the kernel and initrd and use it directly via PXE.

Is that to say that you.. wait, what are you doing?

  LABEL boot2docker
          MENU LABEL boot2docker v0.5.2
          KERNEL boot2docker/v0.5.2/vmlinuz64
          APPEND initrd=boot2docker/v0.5.2/initrd.img loglevel=3 user=docker

Post by mjn » Thu, Feb 06, 2014, 2:13 AM UTC

_wmd wrote: post #70

stesch wrote: post #33

Is Docker a good way to bring more security on a server with a few different websites? Separating the sites from each other and run nginx as a proxy in front of them? What's the overhead?

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 mac…

Post by _wmd » Thu, Feb 06, 2014, 2:23 AM UTC

shykes wrote: post #80

_wmd wrote: post #70

Earlier quoted context omitted.

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 mac…

> Unfortunately Docker prevents hosting environments from employing some of the most potent security mitigations added to Linux recently. You list various facts that are mostly correct, but your conclusion is wrong. Docker absolutely does not reduce the range of security mitigations available to you. Your mistake is to present docker as an alternative to those security mitigations. It's not an alternative - it presen…