Docker in CI/CD

Introduction

Modern CI builds, scans, signs and pushes images on every commit. The pipeline becomes the source of truth for what's in production.

Purpose of this lesson

This lesson teaches Docker in CI/CD as an engineering decision: what problem it solves, when to use it, how to implement it safely, and what signals tell you it is failing.

Understanding the topic

Use this in production readiness work. These practices decide whether containers are merely running or are actually secure, observable, recoverable, and safe to promote through a delivery pipeline.

Core concepts to understand:

• Build → test → scan → tag → push → deploy.
• Use BuildKit + registry cache to keep CI fast.
• Tag with git SHA + semantic version; immutable in registry.
• Sign images (cosign) for supply-chain trust.

Visual explanation

Architecture or command flow to keep in mind:

# .github/workflows/docker.yml (excerpt)
- uses: docker/setup-buildx-action@v3
- uses: docker/login-action@v3
  with: { registry: ghcr.io, username: ${{ github.actor }}, password: ${{ secrets.GITHUB_TOKEN }} }
- uses: docker/build-push-action@v6
  with:
    push: true
    tags: ghcr.io/acme/api:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

Step-by-step explanation

1. Define the production risk first: credential leakage, vulnerable base image, runaway resource use, missing logs, or broken delivery flow.
2. Apply the smallest control that reduces the risk: non-root user, read-only filesystem, scan gate, secret mount, limit, or log driver.
3. Prove the control with commands such as docker inspect, docker history, docker stats, and a failing test case.
4. Automate the check in CI or operational runbooks so it does not depend on memory.
5. Review the result after a real incident or release and tighten the policy where evidence shows gaps.

Informative example

Use the example below as a working baseline, then verify the runtime behavior instead of assuming the command or file is correct.

# .github/workflows/docker.yml (excerpt)
- uses: docker/setup-buildx-action@v3
- uses: docker/login-action@v3
  with: { registry: ghcr.io, username: ${{ github.actor }}, password: ${{ secrets.GITHUB_TOKEN }} }
- uses: docker/build-push-action@v6
  with:
    push: true
    tags: ghcr.io/acme/api:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

A production-minded check usually includes docker ps, docker logs, docker inspect, and one validation from outside the container such as curl, a database connection, or a registry pull.

# Verification loop for Docker in CI/CD
docker ps -a
docker logs --tail=100 <container-name>
docker inspect <container-or-image-name>
docker system df

Real-world use

GitHub Actions + GHCR is the modern default for indie/small teams. Larger orgs pair Jenkins/Buildkite with ECR/GAR.

Enterprise use cases

In a mature engineering organization, Docker in CI/CD is documented as a repeatable pattern with approved base images, ownership labels, CI checks, security expectations, rollback notes, and troubleshooting commands. The difference between a tutorial and production practice is that every container decision must be observable, reviewable, and reversible.

Best practices

• Cache aggressively (BuildKit registry/inline cache).
• Tag with both SHA and semver.
• Run scan + sign before push to a 'release' tag.

Debugging tips

• Inspect effective runtime settings with docker inspect; do not assume the Dockerfile or Compose file applied as expected.
• For resource incidents, compare docker stats, exit codes, OOMKilled state, and host memory pressure.
• For supply-chain issues, trace the exact image digest from build logs to registry to deployment.

Optimization strategies

• Treat image size, CVE count, non-root execution, and digest pinning as release quality signals.
• Set log rotation and resource limits before the first production incident, not after disk or memory exhaustion.
• Cache builds by registry or CI cache backend while still scanning the final pushed image.

Advanced interview questions

Hands-on exercise

Create a small lab for Docker in CI/CD: run the example, inspect the created Docker object, intentionally introduce one mistake, and record the command that reveals the failure. The goal is not just to make the happy path work; it is to build operational reflexes.

# Hands-on lab scaffold
mkdir -p docker-docker-in-ci-cd-lab
cd docker-docker-in-ci-cd-lab

# Add the Dockerfile, compose.yml, or command from this lesson.
# Then run one happy-path test and one broken-path test.
docker version
docker info
docker system df

Summary

Docker in CI/CD matters because Docker is not only a packaging tool; it is a runtime, build, networking, storage, and delivery workflow. Treat each lesson as a production habit: make it repeatable, inspectable, secure, and easy to debug.