jpetazzo

This combines the advantages of Device Mapper (granularity) and AUFS/overlay (page cache re-use), and doesn't require new kernel code. Promising!

The comparison with systemd is unfair. Docker wants to be "batteries included, but swappable/removable". If you don't like host management, orchestration, build, etc., you can disable that specific component and put another one; and none of those components are strictly necessary.

Contrast with systemd, where it's impossible to use anything else, and the attitude of the maintainers is "our way or the highway" when people beg them to continue to support alternatives.

Compare Docker to frameworks like Django or Rails, which come with everything you need (templating, ORM, url mapping, etc.) but where each thing is replaceable if you don't like it; versus Rocket which would be like Flask or Sinatra, which are smaller and require to be combined with other things to be useful. Nothing wrong with either approach; but if the comparison is right, we can expect Docker to provide "reasonable defaults", and some people building some specific apps to use Rocket because they just want to run things and they don't need build/orchestration/API/etc (or they need special versions of those components).

Docker can play with or without Chef/Puppet/Salt/Ansible/etc.:

- you can use configuration management tools to author Docker images; - you can use configuration management tools to deploy Docker (and start Docker containers).

The following presentation has some Puppet-specific information (but the concepts map neatly to other CM tools):

http://www.slideshare.net/jpetazzo/docker-and-puppet-puppet-...

Actually, Docker doesn't always have docker0; you can configure it to use a different bridge.

On my setup, for instance, I use br0 and share the same bridge for containers and VMs.

FWIW, boot2docker became my favorite all-purpose, ready-to-run, ridiculously-small-and-therefore-insanely-fast-to-download VM image.

It's faster to download it (it's 25 MB) and start it with qemu, than to go through the clicky-pointy interfaces of VirtualBox etc., or go through the download of a full Vagrant box. This is game changing.

I don't know yet what will happen for Windows, but an upcoming version of Docker will run on OS X. (I say "upcoming" because I know some core maintainers have OS X support in their local branches, so it's just a matter of time before it hits master.)

It doesn't has the same isolation guarantees (yet) but it lets you use the same workflow.

Windows is different, but I can't imagine a scenario where you have to run your app on Windows. I.e. if it's your local machine, you can spin up a VM; if it's in your datacenter, you can use Linux. If your local policies are "we only run Windows on our servers, screw Linux!" chances are that you wouldn't run Docker anyway, even if it ran natively on Windows :-)

"A few systems that support LXC", that's actually most modern Linux systems now. Anything with a 3.8 kernel is game.

Indeed; for the lucky ones around here with a bare metal Linux box, just substitute kvm instead and ROCK ON!

Just do:

    wget https://github.com/steeve/boot2docker/releases/download/v0.1/boot2docker.iso
    qemu-system-x86_64 -cdrom boot2docker.iso -m 1024

Mind. Blown.

I assume entire responsibility for this; and the associated confusion which ensues when doing e.g. "curl get.docker.io/blah | sh" :)

This is an update to the "classical" Docker presentation.

It includes some details about integration with configuration management systems, and the new "-name" and "-link" features.

In the Docker issues, also look for the "easyfix" tag.

We try to set it for issues that are hopefully actionable for people with a moderate knowledge of Docker and/or Go.

There is a trade-off between "running anywhere" and "running mostly anywhere". I.e. going from 99% to 99.99% :-)

The server-side component only runs on Linux for now, and while it's supported only on x86_64, people have confirmed that it could run on i386, and arm v6/v7/v8.

Later releases will also target FreeBSD, Solaris, and possibly OS X.

The client-side component already runs on OS X, and could possibly run on Windows as well.

However, there is currently no interest at all in running Docker on AIX, HP/UX, Plan9; or on Sparc, Power, s390, or Mips platforms.

Thanks!

godep is definitely cool. But it's a bit sad that it has to be an add-on. Don't get me wrong -- it's a great thing that go gives us a good build system, a good test system, a good dependency system, etc. But if we end up using another build system, another test system, another dependency system, because the stock ones aren't powerful enough, it kind of ruins it :-)

Regarding private repos: IMHO it's much simpler to go to your $GOPATH/src/github.com/blahblah and `git clone [email protected]:blahblah/repo`. But if you know a difference between both approaches I would be happy to hear it!

> [is there] _any_ hack that allows us to limit the size of the filesystem?

Docker 0.7 will let you do that, since each container will have its own (thin) block device, and therefore have a default size limit (which can be trivially bumped up if needed, of course).

Now to anticipate your next question (assuming it is "when will Docker 0.7 be available?"), the answer would be "pretty soon", since the core team is ironing out the last issues before merging to master and releasing :-)

I don't understand what this means; can you elaborate?

Since the attachment for an AOE drive is Ethernet, the drive controller is just an Ethernet NIC...

Yup; there are lots of Docker images available at http://index.docker.io/; and more interesting features are on the way (trusted images, automated builds...)

Also, the Docker workflow is appealing to (at least) some people; this helps them to integrate Docker and OpenStack together.

Among the tons of new features, Havana has native support for Docker containers (as a Nova driver). This means at least three big things:

- when testing OpenStack workloads, you can spin up containers instead of VMs, and boot environments in seconds (much faster than with VMs, especially if you don't have a badass machine and must spin up tiny VMs); - if you're doing HPC, you can run on OpenStack without being afraid of losing any performance, since containers have much lower overhead than VMs (the overhead can be reduced to exactly zero with proper configuration).

Now I can't wait to see Docker containers as a resource in Heat :-)

I work for dotCloud (the company which started Docker), and I was at YaC (Yandex tech conference; the equivalent of Google I/O in Eastern Europe, if you will), and had the opportunity to discuss this with the Yandex team. Here are some extra info (that can easily be found on the web, so nothing sensitive here)

- They released the Docker plugin shortly before the conference [1] - Yandex uses a distributed storage system called Elliptics [2] in many places, and they implemented an Elliptics backend for the Docker registry (the code is out there somewhere. They contributed the Elliptics backend to the Docker registry repo a couple of days ago [3]. - Cocaine is used to power various things inside Yandex, like the Yandex.Browser backend. This backend can sustain very high loads (10-100k req/s). I discussed with their Ops team, since they had specific questions about how to identify (and remove) potential performance bottlenecks in Docker networking stack. (Good news: you can achieve native network performance within containers with zero overhead!)

I'm considering writing Dockerfiles for Elliptics and Cocaine (as soon as I can find some spare time to do so...) but I would also be happy to help if other people want to do that (I'm actively monitoring the docker-user mailing list [4] so don't hesitate to get in touch through here).

[1] https://github.com/cocaine/cocaine-plugins/tree/master/docke... [2] https://github.com/reverbrain/elliptics [3] https://github.com/dotcloud/docker-registry/pull/101 [4] https://groups.google.com/forum/#!forum/docker-user

All this stuff also applies if you don't want to use LXC, Docker, or any kind of container. You can put processes in control groups, and get all those metrics as well.

This is one of the reasons why OpenVZ was initially rejected from being included into the kernel: all the features (isolations and accounting) were mixed together, and the kernel maintainers wanted something that could be re-used in different scopes. It eventually drove the development of LXC, which is really two completely orthogonal feature sets: namespaces (to perform strict isolation) and control groups (to account and isolate resources).