Cli: Implement import & export functionality for volumes

Created on 11 Oct 2018  路  3Comments  路  Source: docker/cli

I would like the ability to import and export volumes in Docker. I will explain each of these scenarios below. The motivation for this is that sometimes I like to be able to easily transition between bind mounts on the host and volumes managed by docker. If I previously started a container with a bind mount (which requires a directory on the host), I want to easily create a new volume with the contents of that directory, and run the container next time using a volume instead of a bind mount. The vice-versa of this scenario should also be supported. At the end of the day, the container doesn't know the difference and still sees the same data, this is just a management task for the host machine.

I also feel docker doing this is safer since it already has root privileges, and sudo won't be needed to copy in/out of /var/lib/docker which at the moment is locked down for even viewing.

Import Volumes

Use case: I have a directory that I want to recursively box into a docker volume. The end result of this operation should be:

docker volume create newvolume
cp -r /some/directory /var/lib/docker/volumes/newvolume/_data

Proposed docker command line usage for such a feature:

docker volume import /some/directory newvolume

This recursively copies the contents of /some/directory into a new volume named newvolume. Permissions should be retained during the copy (owners & permission bits). This is really just sugar coating over mkdir and cp, as shown in my earlier example.

Export Volumes

Use case: I have a volume that I want to convert to a directory, where that directory contains an exact recursive replica of the data in the volume. The end result of this operation should effectively be:

cp -r /var/lib/docker/volumes/existingvolume/_data/* /some/export/path

Example docker command line for such feature:

docker volume export existingvolume /some/export/path

pre & post conditions:

  • Destination directory must exist
  • The destination directory must be empty
  • The destination directory will receive the contents of the volume (recursively)
  • The destination directory contents will retain the permission bits & owner/group that was there in the volume itself
kinfeature

Most helpful comment

Granted I don't know the ins and outs of docker, or its cli design principles, but really using run for this just feels hacky. It's more of a workaround. I prefer a polished and simple solution like with import and export. Opinions on naming ambiguity aside, I think it's much simpler and more trivial than what you've suggested. I don't like using run for this at all.

I think we could have a very broad debate on what "import" and "export" mean in various contexts, but I think part of this feature is about picking one and defining it clearly: Later you could expand these to import/export volumes to tarballs or something, to make it a little closer to what you're probably thinking (maybe some backup mechanism?). But I think at the end of the day, since volumes really do deal in data, the terms aren't that ambiguous.

Don't forget that part of this is about keeping things simple.

All 3 comments

import and export are pretty ambiguously used here.
I would expect import and export to deal with actual volumes instead of just the data of a volume.

Just copying data from some directory to another is also something that is easily performed with a docker run, e.g. docker run -v /some/directory:/tmp/src -v someVolume:/tmp/dst busybox cp -r /tmp/src/* /tmp/dst/

And this could be optimized with other tools like rsync, or some storage specific optimization, which is something that a command like export and import could possibly optimize for.

Granted I don't know the ins and outs of docker, or its cli design principles, but really using run for this just feels hacky. It's more of a workaround. I prefer a polished and simple solution like with import and export. Opinions on naming ambiguity aside, I think it's much simpler and more trivial than what you've suggested. I don't like using run for this at all.

I think we could have a very broad debate on what "import" and "export" mean in various contexts, but I think part of this feature is about picking one and defining it clearly: Later you could expand these to import/export volumes to tarballs or something, to make it a little closer to what you're probably thinking (maybe some backup mechanism?). But I think at the end of the day, since volumes really do deal in data, the terms aren't that ambiguous.

Don't forget that part of this is about keeping things simple.

For reference; earlier discussions around this feature (or similar);

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nanomosfet picture nanomosfet  路  4Comments

Ingosmar89219 picture Ingosmar89219  路  3Comments

kinghuang picture kinghuang  路  4Comments

devmishrs picture devmishrs  路  3Comments

thaJeztah picture thaJeztah  路  5Comments