Container CI CD Pipelines Cheat Sheet

Updated 2026-05-25

Next Topic: Container Debugging & Troubleshooting Cheat Sheet

🧠Study flashcards on this topic120 cards · spaced repetition→

Container CI/CD pipelines automate the entire lifecycle of containerized applications—from building images to deploying them across environments—while embedding security, testing, and quality gates at every step. These pipelines are the backbone of modern cloud-native development, enabling teams to ship updates rapidly without sacrificing reliability or security. A well-designed pipeline integrates build optimization, vulnerability scanning, image promotion, and GitOps workflows to create a seamless path from source code to production. The key distinction from traditional CI/CD lies in the immutable, portable nature of containers: you build once, test thoroughly, and deploy the same artifact everywhere, ensuring consistency across environments while minimizing configuration drift. In 2026, supply chain security—SBOM attestations, provenance verification, and pipeline hardening—has become as central to pipeline design as build speed and deployment frequency.

What This Cheat Sheet Covers

This topic spans 16 focused tables and 178 indexed concepts, 120 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Container Build StrategiesTable 2: Container Security ScanningTable 3: Image Versioning and TaggingTable 4: Container Registry WorkflowsTable 5: Build Tools and PlatformsTable 6: GitOps and Continuous DeploymentTable 7: Container Deployment StrategiesTable 8: Container Testing StrategiesTable 9: Image Signing and ProvenanceTable 10: Secrets Management in PipelinesTable 11: Build Optimization TechniquesTable 12: CI/CD Pipeline ObservabilityTable 13: Advanced Pipeline PatternsTable 14: Kubernetes Deployment AutomationTable 15: Policy and Compliance EnforcementTable 16: CI/CD Pipeline Security Hardening

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Container Build Strategies

Multi-stage builds and intelligent layer ordering are the foundation of fast, small container images. Choosing the right build strategy up front determines both your image size and how quickly CI rebuilds run on incremental code changes.

Strategy	Example	Description
Multi-stage builds	`FROM golang:1.21 AS builder` `WORKDIR /app` `COPY . .` `RUN go build -o app` `FROM alpine:3.19` `COPY --from=builder /app/app .`	• Separates build environment from runtime • drastically reduces final image size by copying only compiled artifacts into a minimal base.
Layer caching	`COPY package*.json ./` `RUN npm install` `COPY . .`	• Orders Dockerfile instructions from least to most frequently changing • placing dependency installation before source code maximizes cache reuse across rebuilds.
BuildKit cache mounts	`RUN --mount=type=cache,target=/root/.cache/pip` `pip install -r requirements.txt`	• Persists package-manager caches across builds without baking them into layers • 10x faster dependency installs on warm CI runners.
Build context optimization	`.dockerignore:` `node_modules` `*.log` `.git`	• Excludes unnecessary files from build context with `.dockerignore` • reduces context upload size and daemon transfer time.
Cross-platform builds	`docker buildx build --platform linux/amd64,linux/arm64 -t myapp:latest .`	• Creates multi-architecture images via QEMU emulation or native builders • supports both x86_64 and ARM64 from a single pipeline run.
BuildKit registry cache	`docker buildx build --cache-from=type=registry,ref=myrepo/cache` `--cache-to=type=registry,ref=myrepo/cache .`	• Shares layer cache between CI runners via registry backend • enables persistent caching across ephemeral CI workers.
Docker Buildx Bake	`docker buildx bake` using `docker-bake.hcl`	• Declarative HCL/JSON file defining multiple build targets, groups, and matrices • replaces long `docker build` command strings with version-controlled config.
SSH mount in BuildKit	`RUN --mount=type=ssh git clone` `[email protected]:org/private-repo.git`	• Forwards SSH agent socket into build without copying keys into image layers • secure way to clone private repositories during CI builds.
Parallel stage execution	`FROM base AS deps` `FROM base AS test` `FROM deps AS prod`	• BuildKit automatically runs independent stages concurrently • reduces total build time proportionally to stage parallelism.
Dependency pre-fetching	`COPY go.mod go.sum ./` `RUN go mod download` `COPY . .` `RUN go build`	• Copies dependency manifests first to cache the download step separately • avoids re-downloading dependencies when only application code changes.
Rootless builds	Buildah, Kaniko, or BuildKit rootless mode	• Builds images without privileged daemon access or Docker socket • essential security control in shared CI environments.
Inline cache	`docker build --build-arg BUILDKIT_INLINE_CACHE=1 .`	• Embeds cache metadata directly into image layers for `--cache-from` reuse • simpler than separate cache manifests but increases image size slightly.

Table 2: Container Security Scanning

Security scanning gates are the primary defense against deploying vulnerable images. Embedding scans early in the pipeline — at build time rather than at deployment time — makes blocking on findings practical and keeps CVE noise actionable.

Tool	Example	Description
Trivy	`trivy image myapp:latest` `--severity HIGH,CRITICAL` `--exit-code 1`	• Open-source scanner covering OS packages, language dependencies, IaC configs, and secrets in a single binary • default choice for CI integrations; supports offline scanning and SBOM output.

The rest of this section is part of the full cheat sheet

Table 3: Image Versioning and Tagging

Consistent image tagging ties every running container back to an exact build and commit, making deployments auditable and rollbacks reliable. Mutable tags like latest are the single most common source of "which version is running?" ambiguity in production.

Strategy	Example	Description
Semantic versioning	`myapp:1.2.3` `myapp:1.2` `myapp:1`	• Tags follow major.minor.patch convention • multiple tags reference the same digest for flexibility across specificity levels.

The rest of this section is part of the full cheat sheet

Table 4: Container Registry Workflows

The registry is the distribution hub for all container artifacts. Registry workflows govern how images flow from CI builds through environments to production, and how access, storage costs, and integrity are managed throughout.

Workflow	Example	Description
Registry authentication	`echo $REGISTRY_TOKEN \| docker login ghcr.io -u $USER --password-stdin`	• Logs into private registries using secrets piped via stdin • never passes credentials as CLI arguments to avoid log exposure.

The rest of this section is part of the full cheat sheet

Table 1: Container Build Strategies

Strategy	Example	Description
Multi-stage builds	`FROM golang:1.21 AS builder` `WORKDIR /app` `COPY . .` `RUN go build -o app` `FROM alpine:3.19` `COPY --from=builder /app/app .`	• Separates build environment from runtime • drastically reduces final image size by copying only compiled artifacts into a minimal base.
Layer caching	`COPY package*.json ./` `RUN npm install` `COPY . .`	• Orders Dockerfile instructions from least to most frequently changing • placing dependency installation before source code maximizes cache reuse across rebuilds.
BuildKit cache mounts	`RUN --mount=type=cache,target=/root/.cache/pip` `pip install -r requirements.txt`	• Persists package-manager caches across builds without baking them into layers • 10x faster dependency installs on warm CI runners.
Build context optimization	`.dockerignore:` `node_modules` `*.log` `.git`	• Excludes unnecessary files from build context with `.dockerignore` • reduces context upload size and daemon transfer time.
Cross-platform builds	`docker buildx build --platform linux/amd64,linux/arm64 -t myapp:latest .`	• Creates multi-architecture images via QEMU emulation or native builders • supports both x86_64 and ARM64 from a single pipeline run.
BuildKit registry cache	`docker buildx build --cache-from=type=registry,ref=myrepo/cache` `--cache-to=type=registry,ref=myrepo/cache .`	• Shares layer cache between CI runners via registry backend • enables persistent caching across ephemeral CI workers.
Docker Buildx Bake	`docker buildx bake` using `docker-bake.hcl`	• Declarative HCL/JSON file defining multiple build targets, groups, and matrices • replaces long `docker build` command strings with version-controlled config.
SSH mount in BuildKit	`RUN --mount=type=ssh git clone` `[email protected]:org/private-repo.git`	• Forwards SSH agent socket into build without copying keys into image layers • secure way to clone private repositories during CI builds.
Parallel stage execution	`FROM base AS deps` `FROM base AS test` `FROM deps AS prod`	• BuildKit automatically runs independent stages concurrently • reduces total build time proportionally to stage parallelism.
Dependency pre-fetching	`COPY go.mod go.sum ./` `RUN go mod download` `COPY . .` `RUN go build`	• Copies dependency manifests first to cache the download step separately • avoids re-downloading dependencies when only application code changes.
Rootless builds	Buildah, Kaniko, or BuildKit rootless mode	• Builds images without privileged daemon access or Docker socket • essential security control in shared CI environments.
Inline cache	`docker build --build-arg BUILDKIT_INLINE_CACHE=1 .`	• Embeds cache metadata directly into image layers for `--cache-from` reuse • simpler than separate cache manifests but increases image size slightly.

Table 2: Container Security Scanning

Tool	Example	Description
Trivy	`trivy image myapp:latest` `--severity HIGH,CRITICAL` `--exit-code 1`	• Open-source scanner covering OS packages, language dependencies, IaC configs, and secrets in a single binary • default choice for CI integrations; supports offline scanning and SBOM output.

Table 3: Image Versioning and Tagging

Strategy	Example	Description
Semantic versioning	`myapp:1.2.3` `myapp:1.2` `myapp:1`	• Tags follow major.minor.patch convention • multiple tags reference the same digest for flexibility across specificity levels.

Table 4: Container Registry Workflows

Workflow	Example	Description
Registry authentication	`echo $REGISTRY_TOKEN \| docker login ghcr.io -u $USER --password-stdin`	• Logs into private registries using secrets piped via stdin • never passes credentials as CLI arguments to avoid log exposure.

Container CI/CD Pipelines Cheat Sheet

Table 1: Container Build Strategies

Table 2: Container Security Scanning

Table 3: Image Versioning and Tagging

Table 4: Container Registry Workflows

Container CI/CD Pipelines Cheat Sheet

Table 1: Container Build Strategies

Table 2: Container Security Scanning

Table 3: Image Versioning and Tagging

Table 4: Container Registry Workflows