Official-images: docker 1.12 image doesn't work without some "doing"

[stevvooe]

The daemon has several errors when starting up (on ubuntu 16.04 on top of docker 1.13.0):

1. It was attempting to load several kernel modules and failing.
2. dbus integration was failing.
3. Iptables was missing.

Eventually, I got to the following working command:

$ docker run --net host --privileged -it -v /lib/modules:/lib/modules -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket docker:1.12

Then, inside the container, you need to run the following:

apk update
apk add iptables

Then, it can run with the small incantation:

docker -D

There are a few things we may want to do:

1. Include the bind mounts from above (modules and dbus) in the instructions.
2. Re-roll the image with iptables installed.

I am not sure if these are broadly encountered problems or specific to my system, but I thought I would document the problem.

[tianon]

The issues with dbus and kernel modules are somewhat odd for sure -- I've seen warnings about those, but I usually already have the necessary kernel modules loaded on the host, so ignoring the warnings should be reasonably harmless in most cases. Regarding dbus integration, I think that has something to do with Docker's systemd integration, right? (so should be safe to ignore inside a container too)

Bind-mounting /lib/modules read-only is something I'd definitely be +1 to adding in the documentation -- that should be reasonably safe and fix some of the modprobe warnings/issues, but I'm still on the fence with the DBus bind and would be curious to find out what Docker is using DBus for to determine how important it is. Could it perhaps be some attempted interaction with firewalld?

With respect to iptables, that's because you're using docker:1.12, which is the "Docker client" variant of the image -- there's a separate dind variant which adds more packages (docker:1.12-dind), and an entrypoint which will pass daemon flags directly through to dockerd:

$ docker run -dit --name docker --privileged docker:1.12-dind --storage-driver overlay2

In the future, issues like this should probably be filed against either https://github.com/docker-library/docker (for issues with the image) or https://github.com/docker-library/docs for issues with the image description/docs. :+1: :heart:

[tianon]

For reference, here's the full dind variant Dockerfile: https://github.com/docker-library/docker/blob/50ec917e1b7601d655daee8893567e8cfd213248/1.12/dind/Dockerfile

[stevvooe]

@tianon Agreed, I am not sure if those dbus and module loads are really a problem. The /lib/modules bind mount may prevent some problems.

All in all, I thought it would be cool just to run docker run docker. The news: this actually worked for the test I was attempting.

Any reason we don't unify dind and the client?

[stevvooe]

@tianon Any reason we can pull https://github.com/docker-library/docker/blob/50ec917e1b7601d655daee8893567e8cfd213248/1.12/dind/Dockerfile#L4 up into the base image? Or am I just doing this wrong?

[tianon]

Mostly just for hyper-slim size -- those deps aren't needed for folks who only need a client (due to having a daemon running in another container, or due to bind-mounting the daemon socket from their host, which are both common uses of this container). They don't account for a lot of size, but once they're added, they can't be removed, so we try to separate the concerns as much as possible.

[stevvooe]

@tianon So, it sounds like this was mostly a pebkac/documentation problem. I can't remember where I landed, so I don't have a good suggestion as to what modifications should be made, other than having an image dockerd in addition to docker.

[tianon]

Maybe we could tweak the documentation to try and make it more obvious that :latest doesn't contain the necessary dependencies for running the daemon properly, and is intended for client-only usage?

[stevvooe]

@tianon How about just having it display on image startup?

"Hey there, you! It looks like you're trying to run a docker deamon! How about you try this instead: <help ensues>"

There can even be a paper clip!

[tianon]

📎 :smile:

That's not a bad idea -- I've filed an issue over there (https://github.com/docker-library/docker/issues/61) so we can track this in the right place. :+1: