I'm working on a CI Jenkins build with scripted pipeline. From Jenkins on one machine, I'm connecting with already configured Jenkins slave on another machine (M2). I'm able to successfully execute docker commands within the jenkins slave, however it seems that docker is unable to mount the volumes from the slave to the freshly started docker image.

node('testImage') {
   ... //do some job including creation of volumes within the "testImage" container
    stage('Run WildFly instances') {
        //run wildfly relevant
        sh "docker run -d --restart=unless-stopped \
           -v /some/path/to/volume/in/jenkins/slave/container:/some/path/to/volume/within/wildfly14/container \
           -p 8380:8080 \
           -p 9380:9990 \
           -e JAVA_OPTS='-Xms256m -Xmx512m -Djava.net.preferIPv4Stack=true' \
           --name wildfly14 \

/some/path/to/volume exists within the jenkins slave docker image, because it's created within the lifecycle of the pipeline, but the wildfly14 container that I'm trying to run is unable to access /some/path/to/volume, because when I run

docker exec -it wildfly14 ls -lR /some/path/to/volume/within/wildfly14/container

it's simply empty. Any suggestions on why is it even happening? I've noticed that the docker containers are set up outside of the jenkins slave container, on the actual machine (M2). Could it be the reason that docker tries to map a volume from outside of the container (/some/path/to/volume) on M2 instead of the location within the jenkins slave?

  • are there any docker related errors? What are the permissions of the volume path? – man0v Jun 12 '19 at 9:23
  • 1
    I've made a mistake of not configuring the proper volume mountins inside docker plugin, now it's fixed – Patryk Jun 14 '19 at 7:37
  • Could you please answer your own question so that this question will be marked as answered? – Bruce Becker Aug 3 '19 at 5:48

In configuration settings of Docker plugin for Jenkins, there were missing mountings for the volumes, because I was deploying docker images within docker slave container, so that the "master" docker container (with Jenkins slave agent) couldn't access the real files from the host machine.

Your Answer

