

Docker 0.11 Released - uniphil
https://github.com/dotcloud/docker/blob/master/CHANGELOG.md#0110-2014-05-07

======
j_s
The first thing I wanted to do with docker was cleanup the mess I made walking
through the examples. Turns out there is no built-in command to do that, and
it looks like it is going to stay that way.

[https://github.com/dotcloud/docker/issues/928](https://github.com/dotcloud/docker/issues/928)

I was surprised to see that nothing had been done about this; a comment there
mentioned that someone was able to clean up 19GB of space once he figured out
what was going on. The solution is easily google-able since so many have run
into it, but cleanup of unused resources should be a first-class operation in
every virtualization solution.

[http://stackoverflow.com/questions/17236796/how-to-remove-
ol...](http://stackoverflow.com/questions/17236796/how-to-remove-old-docker-
io-containers)

~~~
shykes
Hey, I'm a Docker maintainer.

We don't plan on "keeping it that way". Disk clutter after lots of builds is a
problem which we're very much addressing. It's specifically a top-level
_docker clean_ command that I'm not a fan of, because it doesn't capture a
clear intent - what are you cleaning, and who determines what should be kept
and what shouldn't? In general I like to avoid Docker having to guess what you
want - the proverbial "magic".

A few notes:

* The reason Docker can clutter your disk is because we made an explicit tradeoff: it's better to keep too much data than to remove too much. That is why we're able to say "yes, you can run a database on Docker. Neither the container nor its data will be removed, at any point, unless you explicitly request it". Everytime I hear someone complain "there's too much stuff on my disk", I rejoice that I am not instead hearing "Docker ate my data".

* We have already introduced a few improvements. For example Docker used to keep the intermediary container for each build step (for later inspection of the build output, transient state etc). Now, by default, we don't.

* The most elegant fix, I believe, is to use naming and tagging as an indication of interest. If you are interested in keeping an image, give it a name (for example with 'docker build -t'). When an image no longer has a name referencing it, instead of keeping it around as an anonymous image like it does today, Docker can remove garbage collect it. That should take care of the problem elegantly and without requiring a new, clunky top-level command.

TLDR: the "disk clutter" problem is the result of a conscious tradeoff which
we are glad we made. We have started fixing it, and there are more fixes to
come.

~~~
olouv
It's a real PITA that the first thing you do when you start experimenting with
docker is to have to find out about this missing clean command and to design a
custom alias to fit your needs. In my case, I was expecting it (eg. `bower
cache clean`, `npm cache clean`). Regarding the unclear intent, that's what
cli help is for! `docker clean` could output it by default.

~~~
shykes
What would you expect it to do exactly? Remove all untagged images?

~~~
blueyed
That's a good starting point.

I have a docker-cleanup script, which removes untagged images and containers:
[https://github.com/blueyed/dotfiles/blob/master/usr/bin/dock...](https://github.com/blueyed/dotfiles/blob/master/usr/bin/docker-
cleanup)

------
mmerickel
If this is an RC, will docker have a way in 1.0 to properly handle
stdout/stderr logs captured on the host without just allowing a giant json
file to fill up? I'm not aware of a way to do it right now without handling
logs in the container and avoiding the container's stdout/stderr.

~~~
jschneiderhan
There was quite a bit of discussion on this topic in the Docker-dev group. The
comment I found the most informative was by the creator of Docker ->
[https://groups.google.com/d/msg/docker-
dev/3paGTWD6xyw/xj2Xa...](https://groups.google.com/d/msg/docker-
dev/3paGTWD6xyw/xj2XakbfdnoJ)

~~~
mmerickel
Yes, I've read all of that. I consider this a blocker for production use of
docker and releasing a 1.0 RC without solving this is disconcerting (at least
as a process wrapper, it still works fine for wrapping an init system that
handles everything itself). Especially since, in that thread, shykes said it
will be solved prior to 1.0.

~~~
shykes
You're right, the logging subsystem still needs work before 1.0. We're using
the RC label to indicate that we don't plan on breaking APIs and file formats
in any major way between now and 1.0, so toolmakers and integrators can start
locking down their schedule, and trust that their tools won't be deprecated in
a couple months.

If it were entirely up to me I would never call it 1.0, because part of me
wants it to be flawless before anybody uses it in production. But it's not up
to me - a lot of people are already using Docker in production, and there are
many organizations already in process of offering commercial support and
services for it. Clearly they consider Docker acceptable for their needs at
some level - and at some point we'll need to acknowledge that by releasing
1.0, no matter how flawed I find it to be. The improvements won't stop at 1.0
:)

~~~
mmerickel
That's great to hear - I've dove pretty hard into docker and love it but the
logging story has been a dealbreaker for production. Decoupling "create" and
"start" has been great when using the Remote API because I can create a
container, attach my IO handlers, and then start, removing the need for docker
to handle the logs at all (if it supported that). Possibly something like this
can be done via the CLI such that docker can just forward the streams into a
custom script.

------
staunch
Thanks to everyone who contributes to Docker for all your hard work that we
benefit from. You guys really are pushing Linux forward more than almost any
project.

My biggest outstanding issue with Docker (Linux really) is the storage system.
None of the three options make me feel like I'll be able to sleep at night.
Aufs seems broken[1] and will never make it into the kernel. DeviceMapper
seems okay, but I'm not sure how well tested the Docker usage is or how it
performs. Btrfs seems ideal, but again, that's still an "experimental" file
system.

I was even toying with the idea of implementing a Docker storage driver using
rsync (rsnapshot?), for simplicity/stability, but not sure if that would even
be possible.

Obviously something that will inevitably get resolved, but my biggest
stumbling block so far.

1\.
[https://github.com/dotcloud/docker/issues/783](https://github.com/dotcloud/docker/issues/783)

~~~
wmf
What about the VFS driver?

~~~
staunch
Might end up being my best option.

~~~
staunch
BTW, I checked it out again, definitely not a real option.

------
nickstinemates
Blog post coming soon with more information. This is the RC for 1.0. Amazing
work.

~~~
julien421
[http://blog.docker.io/2014/05/docker-0-11-release-
candidate-...](http://blog.docker.io/2014/05/docker-0-11-release-candidate-
for-1-0/)

------
erid
Blog post: [http://blog.docker.io/2014/05/docker-0-11-release-
candidate-...](http://blog.docker.io/2014/05/docker-0-11-release-candidate-
for-1-0/)

------
jimmcslim
Looks good, particularly the support for host networking; this will be a boon
(I think) for those of us using Docker to run lightweight VM style containers
which we wish to have directly accessible on the network by other
machines/devices, and resolved via an existing router's DHCP/DNS. Is there a
way to assign a MAC address to a container under this mechanism so I can setup
the corresponding DNS via my router (or dnsmasq)?

(comment copied from the other item about Docker today)

~~~
craigyk
Agree. Couldn't believe this wasn't in there when I checked it out before.
Isn't using bridged interfaces with VMs/containers a major use case? It's
certainly my primary config, but maybe I'm doing it wrong.

~~~
wmf
I think Docker was originally designed for PaaS "app container" usage where
containers are too cheap to waste an IP address on, hence the NATing and port
forwarding. For VMs or "system containers" it makes sense to give each one its
own MAC and IP address.

~~~
kennu
I'd also consider it very important to be able to run Docker on any host - for
instance a small VPS server that only has its own single IP address.

