CI/CD with Containers

Containers are the packaging format that changed both how software runs and how CI/CD pipelines are structured. A container bundles an application with everything it needs to run — runtime, dependencies, configuration — into a portable, isolated unit that behaves identically on a developer's laptop, a CI runner, and a production server. For CI/CD, containers are simultaneously the most common artifact format, a tool for running isolated pipeline steps, a mechanism for spinning up test dependencies, and the unit of deployment in modern infrastructure. Understanding how containers fit into every layer of the pipeline is essential for working in any contemporary engineering organisation.

Containers in Three Pipeline Roles

Containers appear in CI/CD pipelines in three distinct roles, each serving a different purpose. Conflating these roles produces confusion about what a container is doing at any given point in the pipeline.

Multi-Stage Builds — Lean Production Images

A naive Docker build includes everything needed to compile the application in the final image — build tools, compilers, test frameworks, development dependencies. This produces images that are large, slow to pull, and carry a much larger attack surface than necessary. Multi-stage builds solve this by separating the build environment from the runtime environment within a single Dockerfile.

The first stage installs all build dependencies and compiles the application. The second stage starts from a minimal base image and copies only the compiled output from the first stage — no build tools, no source code, no development dependencies. A Node.js application that requires 800MB of node_modules to build might produce a runtime image under 100MB. A Go binary requires nothing beyond the compiled executable and a minimal OS layer. Smaller images mean faster pulls, faster deployment, and a smaller CVE surface area.

# Stage 1 — builder: full Node.js environment with all dev dependencies
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci                              # Install all dependencies including devDependencies
COPY src/ ./src/
RUN npm run build                       # Compile TypeScript, bundle, optimise

# Stage 2 — runtime: minimal image with only what production needs
FROM node:20-alpine AS runtime
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev                   # Production dependencies only — no build tools
COPY --from=builder /app/dist ./dist    # Copy compiled output from builder stage only
# Source code and devDependencies never reach this image
USER node                               # Run as non-root for security
EXPOSE 3000
CMD ["node", "dist/server.js"]

# GitHub Actions — build, scan, and push the multi-stage image
jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Build image (multi-stage)
        run: |
          docker build \
            --target runtime \                          # Build only the runtime stage
            -t ghcr.io/myorg/app:${{ github.sha }} .

      - name: Scan image for vulnerabilities
        uses: aquasecurity/trivy-action@v0.16.0         # Scan before pushing
        with:
          image-ref: ghcr.io/myorg/app:${{ github.sha }}
          exit-code: '1'                                # Fail pipeline on critical CVEs
          severity: 'CRITICAL,HIGH'

      - name: Push to registry
        run: docker push ghcr.io/myorg/app:${{ github.sha }}

Service Containers — Real Dependencies for Integration Tests

Integration tests that run against mocked databases or in-memory substitutes test the application code in isolation from the dependencies it actually uses in production. Service containers in GitHub Actions spin up real dependency instances — PostgreSQL, Redis, RabbitMQ — as Docker containers that run alongside the job and are destroyed when it completes. The application connects to them exactly as it would in production, using a real TCP connection to a real database engine.

jobs:
  integration-tests:
    runs-on: ubuntu-latest

    services:
      postgres:                                         # Real PostgreSQL instance
        image: postgres:16
        env:
          POSTGRES_USER: testuser
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5                            # Wait until PostgreSQL is ready

      redis:                                            # Real Redis instance
        image: redis:7-alpine
        options: >-
          --health-cmd "redis-cli ping"
          --health-interval 10s

    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - name: Run integration tests
        env:
          DATABASE_URL: postgresql://testuser:testpass@localhost:5432/testdb
          REDIS_URL: redis://localhost:6379
        run: npm run test:integration

Container Security in the CI Pipeline

Every Docker image pushed to a registry is a potential production artifact — it deserves security scrutiny before it leaves the pipeline. Container image scanning analyses the layers of an image for known CVEs in installed packages, deprecated base images, and misconfigurations before the image reaches any deployment environment. Tools like Trivy, Grype, and Snyk Container integrate directly into GitHub Actions as pipeline steps.

Beyond vulnerability scanning, container security in the pipeline includes several other practices: always run containers as a non-root user (the USER directive in the Dockerfile), use minimal base images like alpine or distroless to reduce the installed package surface, never embed secrets in image layers (they persist in the layer history even if deleted in a later layer), and pin base image versions to a digest rather than a mutable tag to prevent silent base image changes between builds.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz