Docker agents for isolation in Jenkins - Mini Project: Build & Apply

Docker Agents for Isolation in Jenkins

📖 Scenario: You are setting up a Jenkins pipeline to run build steps inside isolated Docker containers. This helps keep your builds clean and consistent, like having a fresh workspace every time.

🎯 Goal: Create a Jenkins pipeline script that uses a Docker agent to run a simple shell command inside a container. This will show how Docker agents isolate the build environment.

📋 What You'll Learn

Create a Jenkins pipeline with a pipeline block

Use a agent directive with docker to specify the container image

Add a stage named Run inside Docker

Inside the stage, run a shell command echo "Hello from Docker"

Print the output of the command

💡 Why This Matters

🌍 Real World

Many teams use Jenkins with Docker agents to ensure builds run in clean, repeatable environments without leftover files or dependencies.

💼 Career

Understanding Docker agents in Jenkins is essential for DevOps roles to create reliable CI/CD pipelines that work the same everywhere.

1

Create the basic Jenkins pipeline structure

Write a Jenkins pipeline script starting with pipeline {} and inside it add an empty agent directive and a stages block.

Jenkins

pipeline {
    agent any
    stages {
        // Your code here
    }
}

Hint

Start with pipeline {}, add agent any to run on any available node, and add stages {} for build steps.

2

Configure the Docker agent

Change the agent directive to use a Docker container with image alpine:latest. Use agent { docker { image 'alpine:latest' } }.

Jenkins

pipeline {
    agent {
        docker {
            image 'alpine:latest'
        }
    }
    stages {
        // Your code here
    }
}

Hint

Use the agent block with docker and specify the image as 'alpine:latest'.

3

Add a stage to run a shell command inside the Docker container

Inside stages, add a stage named Run inside Docker. Inside it, add a steps block with a shell command echo "Hello from Docker" using sh.

Jenkins

pipeline {
    agent {
        docker {
            image 'alpine:latest'
        }
    }
    stages {
        stage('Run inside Docker') {
            steps {
                // Your code here
            }
        }
    }
}

Hint

Use stage('Run inside Docker') with steps { sh 'echo "Hello from Docker"' } to run the command inside the container.

4

Print the output of the Docker container command

Add a script block inside steps to capture the output of echo "Hello from Docker" using sh(script: ..., returnStdout: true). Then print the output with echo.

Jenkins

pipeline {
    agent {
        docker {
            image 'alpine:latest'
        }
    }
    stages {
        stage('Run inside Docker') {
            steps {
                script {
                    // Your code here
                }
            }
        }
    }
}

Hint

Use def output = sh(script: ..., returnStdout: true).trim() to get the command output, then print it with echo output.

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