Questions:
- Why does a relative host volume path (i.e.,
./jenkins_home:...
) prevent jenkins from serving it's GUI yet an empty volume path allows jenkins to serve it's GUI? - Where is the aliased host volume (i.e.,
volumes: jenkins_home: <no value>
) stored on the host?
Context:
This situation is similar to https://stackoverflow.com/a/57040274/7490713 but I'm unsure why the solution works.
Using Docker Desktop docker-compose
on Windows 10, with a relative path (i.e., ./jenkins_home:...
) for the host volume location correctly persists data to the current directory, & port 50000 is accessible, however, port 8080 (i.e., Jenkins GUI) is unavailable:
version: '3.9'
services:
jenkins:
image: 'jenkins/jenkins:lts'
restart: 'unless-stopped'
ports:
- '8080:8080'
- '50000:50000'
volumes:
- './jenkins_home:/var/jenkins_home' # Relative path (jenkins GUI doesn't work).
volumes:
jenkins_home:
ping http://localhost:50000 # Success.
ping http://localhost:8080 # Not found.
Whereas using an empty host volume path works:
# ...
services:
jenkins:
# ...
volumes:
- 'jenkins_home:/var/jenkins_home' # Aliased empty path (jenkins GUI works).
volumes:
# NOTE: Empty path value used below.
jenkins_home:
ping http://localhost:8080 # Success.
For comparison, the jenkins GUI is accessible when using docker run
with a host volume path alias as below (although I'm unsure where this is located on the host machine):
Running jenkins via docker run
successfully makes the jenkins GUI available:
docker run -p 8080:8080 -p 50000:50000 -d -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts
The relative volume path makes the jenkins GUI inaccessible, it seems this is because persistence doesn't work in this situation, which prevents jenkins from serving it's GUI on http://localhost:8080
, & somehow using an empty volume path via volume alias allows persistence & the GUI to be served - the question is why does the relative path cause the GUI to not serve yet the empty path causes the GUI to serve?
CodePudding user response:
Since the GUI not being available is an application-specific issue this can not be answered solely from a docker
perspective. But most probably the cause here is the difference between volumes
and bind-mounts
in docker
, namely in the way these are initialized on creation:
While for bind-mounts
simply the specified directory on the host will be mounted into the container as-is, new volumes
are created by docker
if they don't exist yet and populated with the contents of the target directory from the image. This includes also setting the same permissions for the volume
.
So for your question 1.: look for error messages in the container's log regarding permission denied
/ access denied
or missing files/directories in /var/jenkins_home
. If so you just need to set the correct permissions for ./jenkins_home
or initialize the expected contents manually (how exactly is an application-specific issue).
Regarding question 2.: where the contents of the volumes are stored on disk is managed by docker
and dependent on the configuration of the docker
daemon and host. Normally you should not need to care about this and only manage them via the docker volume
command.
See the docker
documentation for more on this.