-1

With the below command:

docker container run -dit --name testcontainer –mount source= ubervol, target=/vol alpine:latest

source mount point name is ubervol pointing to target /vol that resides within container as shown below:

user@machine:~$ docker container exec -it b4fd sh
/ # pwd
/ 
/ # ls vol
vol

enter image description here

ubervol sits outside the container in /var/lib/docker/volumes/ubervol path of host machine(hosting docker daemon)

With the below Dockerfile:

# Create the folders and volume mount points
RUN mkdir -p /var/log/jenkins
RUN chown -R jenkins:jenkins /var/log/jenkins

RUN mkdir -p /var/jenkins_home
RUN chown -R jenkins:jenkins /var/jenkins_home

VOLUME ["/var/log/jenkins", "/var/jenkins_home"]

my understanding is, target is sitting within container with path /var/log/jenkins && /var/jenkins_home

What is the source mount point name? for each target(/var/log/jenkins && /var/jenkins_home)

What is the path of this mount point name in host machine?

overexchange
  • 15,768
  • 30
  • 152
  • 347

1 Answers1

2

The location of the volume data on the host is an implementation detail that you shouldn't try to take advantage of. On some environments, like the Docker Desktop for Mac application, the data will be hidden away inside a virtual machine you can't directly access. While I've rarely encountered one there are also alternate volume drivers that would let you store the content somewhere else.

Every time you docker run a container based on an image that declares a VOLUME, if you don't mount something else with a -v option, Docker will create an anonymous volume and mount it there for you (in the same way as if you didn't specify a --mount source=...). If you start multiple containers from the same image, I believe each gets a new volume (with a different host path, if there is one). The Dockerfile cannot control the location of the volume on the host; the operator could mount a different named volume or a host directory instead.

In practice there's almost no point to using VOLUME in a Dockerfile. You can use docker run -v whether or not here's a VOLUME for the same directory. Its principal effect is to prevent future RUN commands from modifying that directory.

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • If you don't specify it with `-v` the the path on the host machine will be created by docker. I think you would need to search `/var/lib/docker/overlay2`. – Perplexabot Jun 21 '19 at 21:14
  • There's some discussion of [backing up volumes](https://docs.docker.com/storage/volumes/#backup-a-container) in the Docker documentation. You might find it easier to use host paths, as much as the documentation encourages named volumes. Either way, avoid anonymous volumes: be explicit with `-v` or `--mount` options so you're clear what data is being managed. – David Maze Jun 21 '19 at 21:15
  • Are you suggesting to use volume options while running `docker container run ` command? but not in Dockerfile – overexchange Jun 21 '19 at 21:16
  • Yes, that's correct. Don't put `VOLUME` in your Dockerfile at all. – David Maze Jun 21 '19 at 21:18
  • What about `volumes` & `volumes_from` in docker-compose.yaml? – overexchange Jun 21 '19 at 21:27
  • Docker Compose `volumes:` is the same as `docker run -v`. `volumes_from:` has always struck me as a little vague and I tend to avoid it. – David Maze Jun 21 '19 at 22:51