Sharing the Docker socket on a node with Jenkins in a container of that node.

[jpcyrenne]

Good day Brent,

I followed your Udemy class a few months back : Docker Mastery: The complete toolset form a docker Captain - great stuff!

I’m wondering if you could guide me with the best practice for a popular subject that also seems to have many different and controversial solutions.

In a nutshell, in a CI/CD world, we want Jenkins (in a container) to spin other containers, test what it has to test and shut them down.

Object : I run Jenkins in Docker (v1.12.6 on a single node) and Jenkins needs to access the docker.sock on the node.

1. I see a solution where people share —volume= /run/docker.sock:/run/docker/sock (seems the bad way to do it).

https://docs.docker.com/engine/security/https/
I also see a solution by sharing the socket with TLS (SSL). Seems to be the right way.

Although it is not recommended, could I share the socket without SSL ? Making sure the firewall doesn’t allow any connection from other nodes on 2375 (-H=0.0.0.0:2375 ) instead of 2376 ? To simplify things in the Jenkins container.

2. There seems to be a misconception, with a co-worker, that I should launch with the —host:tcp://10.30.0.1/16:2375 (in /etc/sysconfig/docker) and we can access the socket because it’s on the same bridge0 (had to change the default IP because was in conflict with our VPN). This is wrong, right? The same network brodge0 is not the IP of the node's docker.sock

I also read about a version with a plug-in for Jenkins… Guess it's the plug-in that Jenkins uses to access the docker socket. (really not a Jenkins expert - for now!)

So, I’m wondering if you could please guide me towards the best/simple solution for this challenge of mine. You might know of a good link for this? Someone who explains the solution well...

Thank you in advance and have a good DockerCon!

JP Cyrenne

[BretFisher]

@vfarcic any thoughts?

[vfarcic]

I think that all those solutions are more or less the same. They all rely on Docker running inside your cluster. I'd go with mounting a socket for the commands that would propagate information to Swarm (e.g., docker service... or docker stack...). That's the simplest one and it is as insecure as any other you mentioned. Any job will be able to control the cluster.

If you need it more secure, you'd need some form of RBAC and, as far as I know, DockerEE is the only one offering that in Swarm.

Bear in mind that you should NOT build images inside your Swarm cluster nor run any other non-Swarm commands. Doing that would interfere with scheduling. I prefer to spin up and ec2 instance for building images (and shut it down if it's inactive for more than X minutes).

Building should change once kaniko becomes stable. We'll be able to build images inside containers.