Isn't that like running your tests as root though? I have had too many experiences with people backdoor modifying Jenkins.

"The Docker daemon was explicitly designed to have exclusive access to /var/lib/docker. Nothing else should touch, poke, or tickle any of the Docker files hidden there."

Distributed filesystems constantly comes up as the answer to this across many Docker nodes wanting to find hacks to multiplex images easier across docker nodes.

Does this answer particular to NFS from Jérôme in 07/14 still ring true? Here is a better answer: "Yes, you can put the images and containers on NFS; but if you want to share that NFS storage with other Docker Engines, there are some restrictions."

Here are the caveats: - only one engine may pull images (otherwise, you can have conflicts); - other engines have to be restarted to "see" new images; - when you restart an engine, it will detect the containers executed by others. https://groups.google.com/d/msg/docker-dev/02R6VUX7BXU/JUDfU...

Definitely the preferred approach - it's worth noting, though, that you might provide access to the docker daemon over other transports as well.

Regarding the question of bind-mounting docker, it's worth knowing that there are still static binaries available at https://docs.docker.com/engine/installation/binaries/#get-th....

In the process of building a bamboo-agent container for image CI at the minute, the static binaries have come in very handy.

I wonder if mapping [-v $(which docker):/bin/docker] is working after docker binary became dynamically linked binary

this kind of command doesn't work for me (with docker 1.9 installed through rpm):

docker run -v /var/run/docker.sock:/var/run/docker.sock \ -v $(which docker):/bin/docker \ -ti ubuntu

used libraries are not found when i'm trying to launch the container:

docker: error while loading shared libraries: libdevmapper.so.1.02: cannot open shared object file: No such file or directory

Do i have to create another volumes to add librairies ?