Docker Pipeline, Containerized Build Steps, Docker Agents, Sidecars, Registries, and Image Workflows: Configuration, Design Choices, and Tradeoffs

1. Docker Pipeline plugin versus Docker CLI

The Docker Pipeline plugin offers Jenkins-native abstractions for common execution patterns. Raw CLI is more explicit and often exposes newer Docker features directly. Neither is inherently “more secure”; both ultimately operate against a Docker daemon/builder and therefore inherit its trust boundary.

2. Local rootful daemon, rootless daemon, remote daemon, isolated builder

Dedicated local rootful Docker is simple and fast but high impact: daemon control can imply host-level power. Keep it on a trusted disposable/dedicated worker.

Rootless Docker moves daemon/container execution into a non-root user namespace. This reduces privilege but does not make arbitrary CI code harmless; the job still controls that user’s container engine, files, network, and resources.

Remote Docker via SSH/TLS relocates daemon authority to another host. Docker documents secure SSH/TLS access; the connecting credential is sensitive. Jenkins Docker Pipeline inside also expects compatible filesystem visibility for workspace mounts, so API reachability alone does not guarantee that inside works with a remote daemon.

Ephemeral or isolated builders can reduce long-lived host state and improve separation, at the cost of provisioning, caching, and additional control-plane complexity.

3. Top-level versus stage-level container execution

Current Jenkins docs note that Declarative reuseNode true keeps the current node/workspace for a Dockerized stage; the same option is not available in Scripted form. Choose based on dataflow and isolation, not syntax preference.

4. Workspace and cache design

A reused workspace improves feedback time but can preserve stale files. Fresh workspaces improve isolation but require checkout/stash/artifact transfer. Docker layer and package caches reduce network/build time but are shared mutable state. Scope them by trust/tool/version and measure hit rate versus disk pressure.

Never store registry secrets, signing keys, or untrusted artifacts in broadly shared caches.

5. Mutable tag versus digest promotion

A tag such as :candidate is a channel name. A digest such as sha256:… is content identity. A promotion record should bind source/build/repository/digest/target:

producer_job=jenkins/ch19-image
producer_build=184
source_sha=abc123...
repository=registry.example.invalid/team/app
digest=sha256:0123...
promotion_target=staging

Promotion may add/move a target tag, but it must refer to the already verified digest. Re-running docker build from the same Git SHA is a new build, not promotion.

6. Registry credentials and auth context

Credentials Binding with docker login --password-stdin is explicit and portable. Docker Pipeline’s withRegistry can scope registry authentication through a Jenkins credential ID. In both cases, the credential should be repository-scoped where possible and live only for the shortest needed stage.

Authentication success and repository authorization are different states. Record credential ID/reference and push result without logging the secret or archiving Docker auth files.

7. Plugin, engine, and image governance

Docker Pipeline 653.v2f2c08eff0ec is executable controller dependency state. The Docker Engine/CLI version is worker state. Base/test images are external dependencies identified by upstream tags plus resolved digests. Track all three independently. A plugin upgrade should be tested with representative container, sidecar, registry, and workspace flows.

8. Worked scenario: trusted main branch and untrusted fork PRs

The trust decision occurs before the Pipeline receives daemon/credential authority. That is more reliable than trying to sanitize arbitrary PR commands afterward.

9. Resource and feedback tradeoffs

• Cold pulls increase registry bandwidth and stage startup time.
• Layer caches reduce time but consume disk and preserve state.
• Parallel image builds can saturate CPU/disk/registry bandwidth before Jenkins executors are the bottleneck.
• Remote builders improve isolation but add network latency and another credential boundary.
• Per-stage containers improve tool isolation but increase lifecycle overhead.

Measure pull/build/push time, daemon disk use, CPU/I/O, queue wait, and registry latency before increasing executors or retries.

10. Rollback reuses known content

If digest B is bad and digest A was previously verified, rollback should redeploy/repoint to A according to target-platform controls. Do not rebuild “the old commit” and call the result A; the rebuilt digest can differ.

Knowledge check

Answer before revealing the explanation.

Official references and version notes

• Jenkins LTS changelog — baseline Jenkins 2.568.3 LTS, tested with Java 21 and 25; labs use Java 21 for Jenkins components.
• Using Docker with Pipeline — Docker agents, workspace synchronization, multiple containers, sidecars, builds, remote servers, and custom registries.
• Docker Pipeline plugin — reviewed version 653.v2f2c08eff0ec, requires Jenkins 2.541.3, and is currently marked “up for adoption”.
• Docker Pipeline steps — current step reference; deprecated Docker fingerprint steps are not used as authenticity/provenance evidence.
• Docker Engine security, protect daemon access, and rootless mode.
• Docker Engine 29 release notes — current release family at the chapter timestamp; 29.8.1 was released 2026-09-15.
• Distribution Registry official image — local lab baseline registry:3.1.1.
• Python, Alpine, and httpd official images — reviewed lab tags python:3.13-alpine3.24, alpine:3.24.1, and httpd:2.4.68-alpine3.24; resolve actual architecture-specific digests before execution.