Docker Community Forums

Share and learn in the Docker community.

Starting container from within container (have mounted docker.sock), -v path parameter fails


(Peterntatts) #1

Hi!

I’ve been puzzled by this but then realised it’s an architectural issue - don’t know if it’s solvable, please read on…

I’m within a team city container and have docker.sock from the host machine mounted. I was expecting to be able to start a container within the container by doing:

docker run --rm -v /container/path:/path/within/new/container ziptools zip -r /path/within/new/container/file.zip /path/within/new/container

So in other words, mount a directory that sits within the team city container, for the new container to see/write to.

The path appears on the new container but is empty. At first this was puzzling but then I realised if you specify -v /invalid/path:/path/within/new/container in a non-container-within-container situation you get the same behaviour. Nothing seems to validate the “host” path you’re passing to -v.

So the question is, if I’m within a container and using the hosts docker.sock, how can I specify a path within my container, which the hosts docker.sock can see and mount correctly in the newly created container? Or should I not bother because I’m way over-reaching what I should be trying with docker? :slight_smile:

Thanks!


(David Maze) #2

The left-hand side of docker run -v is always the host path on the host that’s running the Docker daemon. (If you’re running docker from within a container, it’s the host path, not the container path; if you’re dangerously running docker remotely, it’s a path on the system running the daemon and not from the client side.)

I have a complicated environment-variable setup that essentially exposes the docker run -v paths that I used to launch my CI system’s build container so that it can remap its container paths to host paths. But it’s probably better to redesign things to just not need these paths at all. (For my specific case, using a named volume for a build cache and docker cp to copy source files in and build artifacts out is probably the right approach but I haven’t spent time coding that yet.)