Containers don't just run in production—they power the entire delivery pipeline. From reproducible build environments to daemonless image builds in Kubernetes, containers are the backbone of modern CI/CD.

1. Why Containers in CI/CD?

Before containers, CI environments were fragile snowflakes—shared Jenkins agents with conflicting tool versions, "works on CI but not locally" bugs, and hours spent debugging environment drift. Containers eliminate this entire category of problems:

• Reproducible build environments — Every job runs in a defined image with pinned tool versions
• No "works on CI but not locally" — Same image locally and in CI; identical results
• Fast spin-up — Containers start in seconds vs. minutes for VMs
• Isolation between jobs — Parallel jobs can't pollute each other's filesystem or processes
• Ephemeral and clean-slate — Every run starts fresh; no accumulated state or leftover artifacts

2. Containers AS the CI Environment

Each CI job runs inside a container. The container image defines the complete toolchain available to that job:

GitHub Actions

jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: node:20-alpine
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

The container: image: node:20-alpine line means "run every step of this job inside a node:20-alpine container." The runner pulls the image, starts the container, and executes your steps inside it.

GitLab CI

test:
  image: node:20
  stage: test
  script:
    - npm ci
    - npm test

Jenkins (Declarative Pipeline)

pipeline {
  agent {
    docker { image 'node:20' }
  }
  stages {
    stage('Test') {
      steps {
        sh 'npm ci && npm test'
      }
    }
  }
}

In all three systems, the pattern is the same: declare an image, get a pristine environment with exactly the tools you need.

3. Building Images in CI

Beyond using containers as the CI environment, CI pipelines also build container images as artifacts. The common pattern:

1. Build — docker build creates the image
2. Test — Run the test suite inside the freshly built image
3. Scan — Security vulnerability scan (Trivy, Snyk, Grype)
4. Push — Push to registry on success
5. Deploy — Update the running service with the new image

GitHub Actions Workflow: Build, Test, Push

name: Build and Push

on:
  push:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha
            type=ref,event=branch

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Run tests against built image
        run: |
          docker run --rm ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:sha-${GITHUB_SHA::7} npm test

4. Docker-in-Docker (DinD) vs Socket Mounting

When your CI job itself runs in a container, how do you run docker build inside it? Two approaches:

Docker-in-Docker (DinD)

A privileged container runs its own Docker daemon (dockerd) inside:

# GitLab CI example with DinD
build:
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t myapp .

• ✅ Full isolation — inner Docker has its own storage
• ✅ Clean layer cache per job (or shared via volumes)
• ❌ Requires --privileged mode (security concern)
• ❌ No layer cache sharing between jobs (unless configured)

Socket Mounting

Bind-mount the host's Docker socket into the CI container:

# Mount the host Docker socket
docker run -v /var/run/docker.sock:/var/run/docker.sock \
  docker:24 docker build -t myapp .

• ✅ Shares layer cache with host (fast builds)
• ✅ No privileged mode needed on the inner container
• ❌ Jobs can see/kill each other's containers (no isolation)
• ❌ Container breakout risk — socket access = root on host

5. Kaniko & Daemonless Builds

In Kubernetes-based CI (Tekton, GitHub Actions on ARC, GitLab K8s runners), you often cannot run a Docker daemon. The solution: daemonless image builders.

Kaniko

Kaniko builds container images from a Dockerfile entirely in userspace—no daemon, no root, no privileged mode:

# Kubernetes pod spec for Kaniko
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: kaniko
      image: gcr.io/kaniko-project/executor:latest
      args:
        - "--dockerfile=Dockerfile"
        - "--context=git://github.com/org/repo.git"
        - "--destination=ghcr.io/org/repo:latest"
      volumeMounts:
        - name: docker-config
          mountPath: /kaniko/.docker
  volumes:
    - name: docker-config
      secret:
        secretName: registry-credentials

How it works: Kaniko reads the Dockerfile, executes each instruction in a snapshot filesystem, computes layer diffs, and pushes the resulting image directly to a registry—no dockerd involved.

6. Caching in CI

Without caching, every CI run rebuilds every layer from scratch. With proper caching, only changed layers rebuild—cutting build times from 10+ minutes to under 60 seconds.

Caching Strategies

Example: Registry Cache

# Pull previous image for cache, build with cache-from
docker pull ghcr.io/org/myapp:latest || true
docker build \
  --cache-from ghcr.io/org/myapp:latest \
  --tag ghcr.io/org/myapp:$SHA \
  --tag ghcr.io/org/myapp:latest \
  .
docker push ghcr.io/org/myapp:$SHA
docker push ghcr.io/org/myapp:latest

Example: Dockerfile with Cache Mounts

# syntax=docker/dockerfile:1
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci --prefer-offline
COPY . .
RUN npm run build

7. The Full Pipeline

Here's the complete flow from code push to production deployment:

Industry Callout

Interactive Quizzes

Hands-On Task

# .github/workflows/build.yml
name: Build and Push to GHCR

on:
  push:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      # TODO: Checkout code
      # TODO: Login to GHCR
      # TODO: Build image with SHA tag
      # TODO: Run tests in the built image
      # TODO: Push image (only if tests pass)
      

Key Takeaways

• Containers as CI environments give you reproducible, isolated, ephemeral build agents with zero drift
• The image IS the artifact — build once, test that image, deploy that same image everywhere
• DinD vs socket mounting is a security/isolation trade-off; prefer DinD for multi-tenant, socket mount for single-tenant trusted environments
• Kaniko and Buildah enable image builds without a Docker daemon—essential for Kubernetes-native CI
• Layer caching (registry cache, GHA cache, cache mounts) can reduce build times by 80%+
• Quality gates (test, scan, size check) in the pipeline prevent bad images from reaching production
• The full pipeline: push → build → test → scan → push → deploy staging → promote production