3

Consider a Dockerfile that declares two volumes

FROM someimage # ... VOLUME ["/foo", "/bar"]

and a container started from that image, that does a bind mount for one of those volumes:

docker run --name mycontainer -d -v /some/path:/foo myimage

If I created a new image from that container using 

docker commit mycontainer myexportedimage

both paths, /foo and /bar, will be excluded in the exported image.

How do I create a runnable (i.e. maintaining meta data from Dockerfile) image from mycontainer that includes the data from both paths, /foo (bind mounted) and /bar (volume as declared by Dockerfile), so if I exported the image to another Docker host, all data would be present?

Improve this question
5
  • That's the point of volumes. Don't put that in a volume if you want data to be on the image rather than on the volume. I recommend you to read some docker documentation. Commented Sep 9, 2017 at 11:47
  • 1
    @FlorinAsăvoaie I know, but that's just the situation I have and need to handle Commented Sep 9, 2017 at 12:33
  • No, it is not. It is a situation where you need to understand how containers work and what is the difference between a volume and an image, and what the Linux "mount" command does. Commented Sep 9, 2017 at 13:56
  • @FlorinAsăvoaie I was given the job to "rescue" containers from a server I have neither setup nor maintained until now, and now am looking for a possibility to somehow get along with the situation. I know the differences and what mount does. That's why I'm looking for a way (a script, a tool, ...) to somehow handle those containers and do my job. Commented Sep 9, 2017 at 14:01
  • If you need to move volumes, inspect the container to get the volume target, and move that. Also, don't declare volumes inside of a Dockerfile, that feature exists for historical reasons and only causes issues in current environments. Commented Sep 9, 2017 at 21:33

1 Answer 1

Reset to default
1

Disclaimer : answer is incomplete because you won't be able to manage that from a Dockerfile like asked and the point is taken that "we should not be in this situation and we should not try to solve this problem in that manner".

I know this is an old question but I ran into the same situation and here's what I did.

You can create an image with the content of your volumes using docker cp to import the content of your volume locally into the container (just copy it somewhere else in your running container and be aware that this duplicates data so watch you filesystem usage). Or exec into it and use cp commands to copy the data in your mounted volume somewhere else (ie: in a tmp directory).

Then, you can docker commit that container to turn it into an image. Run a new container from that new image without using docker volumes and move back the files copied where they should be if the volumes where mounted.

Now, use docker commit again to get a reusable image from the container where you copied your volumes contents.

You can now tag and/or push that image to a registry or docker save it into an archive and use it where you need it.

Improve this answer
1
  • Would you give some example commands of how to do the copy and relink parts please? Commented Sep 19, 2023 at 9:54

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.