Cannot connect to the Docker daemon

[pierrediancourt]

Hi,

I ran your docker container this way

docker run --net=isolated_nw \ -e DOCKER_API_VERSION='1.23' \ -p 88:8080 -p 50000:50000 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /volumes/jenkins/jenkins_home:/var/jenkins_home \ -v /volumes/jenkins/ansible_inventory:/etc/ansible \ --hostname=jenkins --name jenkins \ -d stefanprodan/jenkins

As my docker version is Docker version 1.11.2, build bac3bae and running on CoreOS stable, i checked there https://docs.docker.com/engine/reference/api/docker_remote_api/ and have guessed i should specify '1.23' for the environment variable DOCKER_API_VERSION.

When running the build job from the Pipeline sample you provide by your groovy script, i can see this in the Console Output

Started by user admin [Pipeline] node Running on master in /var/jenkins_home/workspace/Test pipeline [Pipeline] { [Pipeline] stage [Pipeline] { (aspnetcore) [Pipeline] sh [Test pipeline] Running shell script

• docker inspect -f . microsoft/aspnetcore-build

Cannot connect to the Docker daemon. Is the docker daemon running on this host? [Pipeline] sh [Test pipeline] Running shell script

• docker pull microsoft/aspnetcore-build Using default tag: latest Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon. Is the docker daemon running on this host?). Using system default: https://index.docker.io/v1/ Cannot connect to the Docker daemon. Is the docker daemon running on this host? [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline ERROR: script returned exit code 1 Finished: FAILURE

I'm getting nothing relevant using docker logs jenkins.

I can assure you that/var/run/docker.sock is a valid path as the ls -lah /var/run/d* command returns me this

-rw-r--r--. 1 root root 4 Nov 4 20:05 /var/run/docker.pid srw-rw----. 1 docker docker 0 Nov 4 20:05 /var/run/docker.sock

So i guess CoreOS is not different enough from other systems to cause the issue, don't you think ? Moreover there's this ls -lah /var/run/d* command result executed in the precedently ran container ( passed thanks to this command docker exec -it jenkins /bin/bash)

srw-rw----. 1 233 233 0 Nov 4 20:05 /var/run/docker.sock The user or group "233" are unknown (can't see anything like that when i cat /etc/passwd or cat /etc/group, no need to copy their content here i think).

docker -v displays Docker version 1.12.3, build 6b644ec from within the container

[stefanprodan]

I don't think it's CoreOS, but the Docker version. As far as I know Docker API changed a lot from 1.11 to 1.12. You can can fork the repo and install Docker 1.11.2 on the Jenkins image here https://github.com/stefanprodan/jenkins/blob/master/Dockerfile#L29

[pierrediancourt]

Thanks a lot i'll explore that path and keep you informed here

[pierrediancourt]

Running docker -v on my freshly built image returns this

Docker version 1.11.2, build b9f10c9

To build the image i cloned the url you linked me, and edited the docker-engine package apt-get is installing (docker-engine=1.11.2-0~jessie which is the only 1.11.2 version i could download, see https://apt.dockerproject.org/repo/dists/debian-jessie/main/filelist)

As a reminder, my host (CoreOS) docker version is : Docker version 1.12.3, build 6b644e which is the same but not exactly, refering to the build number... Sadly i can't get closer but i think it's close enough to guess that the problem is somewhere else.

What about the docker.sock permissions ? Might be a good lead no ?

[markdavidburke]

I had to chmod 777 /run/docker.sock in Fedora 23 then it worked. I found this out by logging into the container docker exec -it jenkins-ci /bin/bash and running docker info which couldn't connect to the docker daemon

in the down.sh why would you run rm -rf /home/$(whoami)/jenkins_home ?

[pierrediancourt]

Thanks for your contribution sofuca. So you executed something like docker exec -u root ${NAME} /bin/chmod -v a+s $(which docker) (untested) after running the jenkins container ? Because there's no sudo in the container and running as jenkins user you can't use chmod on the .sock file, no rights for that.

I really advice you both to read the following post and moreover, to watch the video in it to fully understand the risks of the container we're discussing about. I'm currently wondering if i shouldn't look for another way to fulfill my CI objectives (not using a docker.sock passed to a docker container). https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html

In my opinion, the part of the down.sh script you're talking about is just here to let stefanprodan easily reset his environment for testing his work on the container.

[markdavidburke]

Hey, sorry for the confusion, you need to change the permissions on the docker.sock on the host, not inside the Jenkins container.

[pierrediancourt]

Yeah i had and hesitation about it. I'm not sure i'll do that but thanks for your explanation.

[stefanprodan]

Yes the down.sh resets everything on host, don't use that if you want to keep your data. Regarding the permissions on the docker sock, it shouldn't be a security issue if your CI server is behind a firewall. If your Jenkins server has a public IP then the docker socket is the least of your problems.