Proposal: Add support to mount an image or a container

[zhuguihua]

Background

Currently, image handling is based on

• Works inside a container with a shell or other tools
• Copy file from host

Problems

• Application container maybe not contains a shell or other tools
• Copy file from host implies dependencies from container to host

Design

We will realize a feature similar to libguestfs.

• Create a new sub command "mount" in docker.
  • Usage: docker mount IMAGE|CONTAINER mountPath
  • If container is not in stop state, or image is in use, mount operation will fail.
  • If container or image is in mounted state, some operations like start, push, commit will fail, and docker daemon will output the error message.
  • Files in image or container will be mounted to the given mount path. The default mount path is /var/lib/docker/file/
  • The image or container will be mounted read-only, and we will add a new rw layer based on it.
  • User can add, delete, modify files at the mount point.
• Create a new sub command "unmount" in docker.
  • Usage: docker unmount IMAGE|CONTAINER
  • For image, we will untag the original image, then commit a new image which contains the added rw layer with the original image's tag.
  • For container, we will combine the original rw layer of container with the added new one.

[thaJeztah]

If I understand correctly, you want to access the (new) rw-layer from the host, not inside the container, then manipulate files in the rw-layer, and commit the results to a new image?

[zhuguihua]

@thaJeztah Yes, your understanding for image mount is correct. But for container mount, we will not commit a new image, it is also a container.

[hkamezawa]

I think we can use host's gdb to debug a coredump inside container image, host's tool to investigate logs or report in containers without exporting the container image to tar ball. And we can modify container even if the app container doesn't contain an editor or shell.

[thaJeztah]

Won't docker cp allow you to do this? I don't really see how this would make the container/image less dependent on the host (per "Copy file from host implies dependencies from container to host")

i.e.,

docker cp mycontainer:/some/file .
vim file
...
docker cp file mycontainer:/some/file

[yangdongsheng]

Hi @thaJeztah , TBH, the docker cp way looks not convenient to me. What's more, the idea of docker mount would work on image not only container from the description from @zhuguihua . That means, mount is providing a feature similar with libguestfs . I think that's helpful 😄

[zhuguihua]

@thaJeztah docker cp cannot edit image directly. If you want to update it, you must start a container with the image firstly. It is not convenient for users.

[hkamezawa]

For my case, at debugging, a user need to extract a runtime and all required library from a container which is scattered over a file tree in the container, installed automatically by docker build. That's a pain. He'll not want to install gdb and debuginfo into the container at docker build. It's good to have some way to examine container's contents with tools in a host without copying.

[dmcgowan]

I agree with @thaJeztah, the proper way to copy files from a docker daemon host to the a docker cli host is through docker cp. This command has no value as a cli command since the mounted directory may not even be reachable from the cli issuing the command. If docker cp does not match your use case, docker inspect does provide low level mount information, i.e. docker inspect -f '{{.GraphDriver}}' $(docker create ubuntu).

[zhuguihua]

@dmcgowan For image, this command could have a function similar to libguestfs, it could edit config file in image before starting a container. For container, this command is helpful for debugging like @hkamezawa saying.

[runcom]

can't this be thought an external tool for just doing this and handle the logic of mounting/not mounting based on container's state? not a user, can't libguestfs be extended to mount/inspect docker containers/images? :) btw, this seems really something for an external tool to me

[zhuguihua]

We have already discussed with libguestfs's guys, it is not so good for implementing this feature to mount docker images. Do you have some advice about other external tools to achieve this? @runcom
We need this feature indeed, is there a better way to do this? Welcome new ideas. @thaJeztah @dmcgowan
Thanks.

[unclejack]

Images aren't supposed to be modified. Images are meant to be immutable and containers are supposed to be mutable.

The right way to modify an image is to create a container using that image, make any desired changes to the container and commit that container as a new image.

Additionally, images can also be edited using export and import.

Adding new top level commands such as mount and unmount won't happen as that's not needed. Having more than one way to do the exact same thing which has been there for a long time is overkill.