Docker-in-Docker considerations in Jenkins - Time & Space Complexity

Time Complexity: Docker-in-Docker considerations

O(n)

Understanding Time Complexity

When using Docker inside Jenkins pipelines, it is important to understand how the execution time grows as you run more Docker commands inside Docker containers.

We want to know how the number of Docker operations affects the total build time.

Scenario Under Consideration

Analyze the time complexity of the following Jenkins pipeline snippet using Docker-in-Docker.

pipeline {
  agent {
    docker {
      image 'docker:latest'
      args '--privileged'
    }
  }
  stages {
    stage('Build Images') {
      steps {
        script {
          def images = ['app1', 'app2', 'app3']
          images.each { image ->
            sh "docker build -t ${image} ."
          }
        }
      }
    }
  }
}

This pipeline runs a loop to build multiple Docker images inside a Docker container using Docker-in-Docker.

Identify Repeating Operations

Look for repeated commands or loops that affect execution time.

• Primary operation: The docker build command inside the loop.
• How many times: Once for each image in the list (3 times here, but can be more).

How Execution Grows With Input

As the number of images to build increases, the total build time grows roughly in direct proportion.

Input Size (n)	Approx. Operations
3	3 docker build commands
10	10 docker build commands
100	100 docker build commands

Pattern observation: Doubling the number of images roughly doubles the total build time.

Final Time Complexity

Time Complexity: O(n)

This means the total time grows linearly with the number of Docker images you build inside the pipeline.

Common Mistake

[X] Wrong: "Running Docker commands inside Docker containers is instant and does not add extra time."

[OK] Correct: Each Docker build runs fully inside the container and takes time proportional to the image size and build steps, so more builds mean more time.

Interview Connect

Understanding how nested Docker commands affect build time helps you design efficient pipelines and explain your choices clearly in real projects.

Self-Check

What if we parallelize the Docker builds instead of running them one after another? How would the time complexity change?