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 git@github.com: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).

Each container will have a "fixed-size filesystem", but:

- it will be thinly provisioned (i.e. it can be 10G or 100G but still use only a few MB on disk if it's essentially empty, like a sparse file), - it can be grown easily.

On the one hand, it's a bit less convenient because you have to care about the disk usage.

On the other hand, it's great because a single container can't eat up all your precious disk space (and if you want to run some public/semi-public stuff that's quasi mandatory).

If you want to check the current code, you can look here: https://github.com/alexlarsson/docker/tree/device-mapper3

The Dockerfile provides caching. When you tweak a few things, you don't have to re-run the whole script, which is great if there are some expansive steps (e.g. downloading and installing Java, compiling a big library, etc.)

Of course, you can achieve something similar with shell scripts, e.g. "if Java is not installed, install it, otherwise go to the next step". But if you get it wrong, or if there is some side-effect, the end result (after running the script multiple times) won't be exactly the same. The Dockerfile (with snapshots at each step) ensures consistency.

It's not a big deal if you are a shell expert and write that kind of script for breakfast, but it's not the case for everyone :)

Allow me to apologize if I sound blunt, but I think you missed the point of Dokku. It is a, what, 100 lines shell script? It supports a single app, but you can run it multiple times. The same way that Heroku supports a single app per git repository. It's a kind of design decision, and not a limitation per se.

Dokku is a demonstration of what you can achieve with Docker + a very little shell script. In my humble opinion, it's very promising that you can achieve so much (something that lets you deploy applications in a Heroku-compatible way) with so little.

Also, 12-factor is totally orthogonal: you (not you specifically, but the general developer) should use 12-factor as much as possible (because most of it can be considered as "best practice", I think), then you can deploy on IAAS, PAAS, your own machines, etc.; and using 12-factor just makes the whole process easier.

Others will correct me if I'm wrong, but Deis particularly makes sense, since Dokku has a more restricted scope, and Flynn isn't out yet.

Also, the required glue is a bit more complicated than you think, especially when you want to be able to scale and/or deploy on multiple servers. You need to store some extra info somewhere (at least in a database, at best in a distributed one like zookeeper, doozer, or etcd). Then things get exciting :-)

... That's something that I would love to do once Docker has pluggable backends.

However (please don't throw stones at me if I'm wrong) I thought it wasn't possible to do "zones within zones"; did that change?

Fair point; but this is not using IPSec. It's using OpenVPN, which relies on TUN/TAP.

That's not the only thing I'm doing on this VM; as I pointed out, I'm consolidating lots of little hacks and projects that are running all over the place in different environments. I put each thing in its own container. Benefits:

- I can shutdown one of those "experiments" without affecting others. - If I want to migrate one of those things elsewhere (because it turns out to need more resources), it's already "Dockerized" (i.e. trivial to redeploy elsewhere). - When I remove one of those things, I don't have to worry about leftover packages, dependencies, files, etc. lying around.

Otherwise it would indeed be a poor use of my time :-)

Thanks for your feedback!

Agreed, the approach is far from perfect.

1. Process supervision is kept very simple, because there are many other tutorials and demos out there using Supervisor and other systems. I'd love to know what is inherently wrong with using `while true` and hanging on logs. Personally, replacing Supervisor (or monit, or god, or $yourfavoriteprocessmonitor) with 3 lines of shell script is fine with me, especially as the focus is to show that Docker can now run OpenVPN.

2. Handle multiple log streams: indeed! I considered running two separate containers, and the only reason why I didn't do it is to simplify the setup process. I also explored the other option (using two separate containers for TCP and UDP connections), and it works almost the same; it looks like:

docker run openvpn genkeys docker run -volumes-from $CID openvpn tcp docker run -volumes-from $CID openvpn udp docker run -volumes-from $CID openvpn serveconfig

Hopefully, the way the project is laid out makes it fairly trivial for someone to change it to run each openvpn process in its own container.

3. Here again, it's a (not-so-good) trade-off. In many cases, you need something simple and straightforward to move the configuration file to the device, e.g. when the device is a phone or tablet. Downloading a combined file over HTTPS is the simplest solution I found (even if in the Android case, it is slightly crippled by the Download Manager bug). It uses SSL to prevent eavesdropping. It protects against a system which would passively record e.g. WiFi traffic. It doesn't protect against a system which would actively detect such a transfer, and immediately initiate the same transfer, before you have the opportunity to stop the `serveconfig` container. I considered adding some HTTP basic auth, but that would have required a "real" HTTP server in `serveconfig` (or to hack further with socat, but I'm already quite ashamed of the current hack, TBH).

I agree that the setup can be greatly improved (what can't?), but I disagree with "there must be better way in every step". This is certainly not the setup that you want if you have a large number of clients, or if you are in an extremely compromised network (then again, it's only a concern during key exchange), but I don't see why it can't be acceptable for 99% of the personal users out there.

Yeah, still true, but we are actively working on an alternate implementation to be compatible with anything post 3.2 and RHEL 6.4 as well.

There is already some support for Gentoo and Archlinux, and if you are willing to use a "foreign" kernel, Red Hat / Fedora / CentOS work as well.

There is some significant work in progress to add compatibility for non-AUFS systems. I don't have an accurate timeline at this point, but expect something (or at least an announcement) at the end of the month!