How Does docker.inside Works in Jenkins

How Does docker.inside() Works in Jenkins

In Jenkins you have the chance of running commands inside of seemingly random containers. You are able to execute commands in node, maven, or a bunch of other containers. Somehow the containers keep running even after executing a single shell command. How is this happening?

So when you have a Jenkins script such as:

stage('Run on node') {
    node {
        sh "ls /path/in/node"

        docker.image('node').inside {
            sh "node run ..."
            archiveArtifacts ....
            sh "node run ..."
        }
    }
}

Well if we have a look at the running containers, on a host where Jenkins runs, we notice that there are containers that just have a root container from the image that simply executes cat.

Thus what Jenkins is doing:

docker run -it -v ... node cat

This is to keep up the container with its network interfaces bound, with the volume mounted, to allow any changes that are happening on the container filesystem to be available between different sh calls.

On each sh call, Jenkins is executing the command passed to sh:

docker exec -it sh -c "node run ..."

Two last notes:

1. The inside() is actually passing in an optional container parameter that gives you the id of the container that you’re executing inside.

2. An implicit volume mount is done to the current workspace node. That’s why when you archiveArtifacts, or process junit reports, they must be in the workspace folder.

Article Photo from Pexels: https://www.pexels.com/photo/wooden-robot-6069/