Docker agents for isolation in Jenkins - Step-by-Step Execution

Process Flow - Docker agents for isolation

Jenkins Master

↓

Request Build

↓

Allocate Docker Agent

↓

Start Docker Container

↓

Run Build Inside Container

↓

Build Complete

↓

Stop and Remove Container

↓

Return Results to Master

Jenkins master requests a build, allocates a Docker container as an isolated agent, runs the build inside it, then cleans up the container after completion.

Execution Sample

Jenkins

pipeline {
  agent {
    docker {
      image 'python:3.12'
    }
  }
  stages {
    stage('Build') { steps { sh 'python --version' } }
  }
}

This Jenkins pipeline runs the build inside a Docker container using the python:3.12 image for isolation.

Process Table

Step	Action	Docker Container State	Build Command	Output
1	Jenkins master starts pipeline	No container	N/A	N/A
2	Allocate Docker agent	Container created (python:3.12)	N/A	Container starting
3	Run build command inside container	Container running	python --version	Python 3.12.x
4	Build completes	Container running	N/A	Build success
5	Stop and remove container	Container stopped and removed	N/A	Cleanup done

💡 Build finished and container cleaned up to keep environment isolated

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 5
Docker Container	None	Created (python:3.12)	Running	Removed
Build Output	None	None	Python 3.12.x	Finalized

Key Moments - 2 Insights

Why does Jenkins create a new Docker container for each build?

Each build runs in a fresh container to keep environments clean and isolated, as shown in execution_table steps 2 and 5 where container is created and then removed.

What happens if the build command fails inside the Docker container?

The container still stops and is removed after the build attempt, ensuring no leftover state, similar to step 5 in the execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what is the Docker container state at step 3?

A Container running

B No container

C Container stopped

D Container removed

💡 Hint

Refer to the 'Docker Container State' column at step 3 in the execution_table

At which step does Jenkins remove the Docker container?

A Step 2

B Step 5

C Step 3

D Step 4

💡 Hint

Check the 'Docker Container State' column for when the container is stopped and removed

If the build command was changed to 'python --help', how would the output in step 3 change?

A Output would show Python version

B Output would be empty

C Output would show Python help text

D Build would fail immediately

💡 Hint

Look at the 'Build Command' and 'Output' columns in step 3 to understand command-output relation

Concept Snapshot

Jenkins Docker agents run builds inside isolated containers.
Syntax: agent { docker { image 'image_name' } }
Each build gets a fresh container.
Build runs inside container, then container is removed.
Keeps builds clean and reproducible.

Full Transcript

This visual execution shows how Jenkins uses Docker agents for isolation. The Jenkins master starts a pipeline and requests a Docker agent. A new container is created from the specified image (python:3.12). The build command runs inside this container, producing output like the Python version. After the build finishes, Jenkins stops and removes the container to keep the environment clean. Variables like the Docker container state and build output change step-by-step. Key points include why containers are created fresh for each build and that containers are always cleaned up even if builds fail. The quiz tests understanding of container states and command outputs during the process.

Practice

1. What is the main benefit of using Docker agents in Jenkins for running jobs?

easy

A. They provide isolated environments to avoid conflicts between builds.

B. They speed up the Jenkins UI loading time.

C. They allow Jenkins to run without any plugins installed.

D. They automatically backup Jenkins configuration files.

Solution

1. Step 1: Understand Docker agent purpose

   Docker agents run Jenkins jobs inside containers, isolating each build environment.

2. Step 2: Identify the benefit of isolation

   This isolation prevents conflicts and keeps builds clean and reproducible.

3. Final Answer:

   They provide isolated environments to avoid conflicts between builds. -> Option A

4. Quick Check:

   Docker agents = isolated environments [OK]

Hint: Docker agents isolate builds to avoid conflicts [OK]

Common Mistakes:

• Thinking Docker agents speed up Jenkins UI
• Believing Docker agents remove need for plugins
• Assuming Docker agents backup Jenkins configs

2. Which of the following is the correct syntax to specify a Docker agent with image python:3.12 in a Jenkins pipeline?

easy

A. agent { docker { image 'python:3.12' } }

B. agent { docker.image('python:3.12') }

C. agent { docker('python:3.12') }

D. agent { docker { image: 'python:3.12' } }

Solution

1. Step 1: Recall Jenkins pipeline Docker agent syntax

   The correct syntax uses agent { docker { image 'image_name' } } format.

2. Step 2: Match the syntax with options

   agent { docker { image 'python:3.12' } } matches the correct syntax exactly with single quotes and no colon.

3. Final Answer:

   agent { docker { image 'python:3.12' } } -> Option A

4. Quick Check:

   Correct Docker agent syntax = agent { docker { image 'python:3.12' } } [OK]

Hint: Use agent { docker { image 'name' } } syntax [OK]

Common Mistakes:

• Using dot notation instead of block syntax
• Adding colon inside image declaration
• Using parentheses incorrectly

3. Given this Jenkins pipeline snippet:

pipeline {
  agent {
    docker {
      image 'node:18'
      args '-p 3000:3000'
    }
  }
  stages {
    stage('Run') {
      steps {
        sh 'node -v'
      }
    }
  }
}

What will be the output of the sh 'node -v' command?

medium

A. No output, command skipped

B. Error: node command not found

C. v12.x.x (Node.js version 12 output)

D. v18.x.x (Node.js version 18 output)

Solution

1. Step 1: Identify Docker image used

   The pipeline uses the Docker image node:18, which includes Node.js version 18.

2. Step 2: Understand command execution inside container

   The sh 'node -v' runs inside the container, so it will output Node.js version 18.

3. Final Answer:

   v18.x.x (Node.js version 18 output) -> Option D

4. Quick Check:

   Docker image node:18 runs Node.js v18 [OK]

Hint: Command runs inside specified Docker image environment [OK]

Common Mistakes:

• Assuming host Node.js version runs instead
• Expecting error due to missing node
• Confusing image tag with different Node version

4. You wrote this Jenkins pipeline snippet to use a Docker agent:

pipeline {
  agent {
    docker {
      image 'ubuntu:latest'
      args '-v /var/run/docker.sock:/var/run/docker.sock'
    }
  }
  stages {
    stage('Test') {
      steps {
        sh 'docker ps'
      }
    }
  }
}

But the build fails with docker: command not found. What is the likely cause?

medium

A. The Jenkins agent cannot mount volumes.

B. The ubuntu:latest image does not have Docker installed.

C. The args option is incorrect syntax.

D. The docker ps command is invalid inside containers.

Solution

1. Step 1: Check the Docker image capabilities

   The ubuntu:latest image is a minimal OS image and does not include Docker by default.

2. Step 2: Understand why command fails

   Since Docker is not installed inside the container, docker ps command is not found, causing the error.

3. Final Answer:

   The ubuntu:latest image does not have Docker installed. -> Option B

4. Quick Check:

   Missing Docker in image = command not found error [OK]

Hint: Check if Docker is installed inside the container image [OK]

Common Mistakes:

• Blaming volume mount syntax
• Assuming docker commands always work in containers
• Thinking docker ps is invalid inside containers

5. You want to run a Jenkins job inside a Docker container with a custom environment variable MY_VAR=hello and mount the workspace directory to /app inside the container. Which Jenkins pipeline snippet correctly sets this up?

hard

A. agent { docker { image 'python:3.12' args '-e MY_VAR=hello -v /app:$WORKSPACE' } }

B. agent { docker { image 'python:3.12' args '-v $WORKSPACE:/app -e MY_VAR=hello' } }

C. agent { docker { image 'python:3.12' args '-e MY_VAR=hello -v $WORKSPACE:/app' } }

D. agent { docker { image 'python:3.12' args '-v /app -e MY_VAR=hello' } }

Solution

1. Step 1: Understand Docker args for environment and volume

   To set environment variables, use -e VAR=value. To mount volumes, use -v host_path:container_path.

2. Step 2: Match correct volume and env var syntax

   agent { docker { image 'python:3.12' args '-e MY_VAR=hello -v $WORKSPACE:/app' } } correctly uses -e MY_VAR=hello and mounts $WORKSPACE to /app inside container.

3. Final Answer:

   agent { docker { image 'python:3.12' args '-e MY_VAR=hello -v $WORKSPACE:/app' } } -> Option C

4. Quick Check:

   Env var and volume mount syntax = agent { docker { image 'python:3.12' args '-e MY_VAR=hello -v $WORKSPACE:/app' } } [OK]

Hint: Use '-e VAR=value' and '-v host:container' in args [OK]

Common Mistakes:

• Reversing volume mount paths
• Omitting environment variable flag
• Incorrect order or missing colon in volume