Production Container Patterns, Immutable Delivery, Configuration, Statelessness, Sidecars, and Operational Contracts: Configuration, Design Choices, and Tradeoffs

1. Design starts with failure and replacement

A production pattern is useful only if it predicts what happens when a process exits, a host reboots, an image is replaced, a volume fills, a credential rotates, or a dependency is unavailable. Design choices should therefore be expressed as state and recovery decisions, not as “best-practice” labels.

2. Stateless app versus stateful service

3. Immutable replacement versus in-place mutation

4. Companion service decision

5. Companion contract checklist

• Exact image digest and runtime user.
• Only required network memberships.
• Only required read-only/read-write mounts.
• Independent health/log/resource limits.
• No Docker socket or host namespace unless the architecture explicitly requires privileged infrastructure authority.
• Defined behavior when the primary app is unavailable.
• Upgrade/rollback compatibility rules between app and companion.

6. Configuration mechanism and rollback

7. Resource strategy: measure, then bound

Start with representative load and observe CPU, memory, PIDs, I/O and latency. Apply limits that protect the host while allowing expected peaks. A hard memory limit can intentionally turn uncontrolled host pressure into a bounded container OOM, but the application still needs recovery and capacity planning. CPU quotas can introduce throttling; a “slow app” may actually be a resource-governance symptom.

8. Health strategy: cheap, local, and meaningful

Use a probe that confirms the application can perform its minimum local service, not a deep dependency transaction that overloads every downstream system. A deep external synthetic check belongs at another observability layer. Avoid probing only “PID exists,” but also avoid making every healthcheck call the entire dependency graph.

9. Compose single-host versus orchestrator boundary

10. Release and rollback contract

A rollback record should name the previous image digest, configuration revision, secret compatibility requirement, and persistent-data/schema compatibility. “Retag latest back” is not enough because it hides which bytes and state transition are being reversed. If an image rollback cannot read the current data schema, the release contract must include a forward-fix or data migration plan.

11. Decision table: worked production scenario

12. Cost and developer-experience tradeoffs

Production hardening can increase local friction if every environment must exactly reproduce production. Keep the contract portable but allow development-specific conveniences in Chapter 37’s dev definition. The important boundary is that release bytes and production runtime controls are explicit, reviewed, and independently verifiable.

13. Platform prerequisites to record

Record before approving the design:
- Engine/CLI/Compose versions and OS/architecture
- image/index digest and platform
- cgroup/resource-control support
- logging driver availability and disk budget
- volume driver and backup semantics
- local secret/config implementation versus external provider
- host exposure/firewall/load-balancer boundary
- whether single-host downtime is acceptable
- recovery objective (RTO/RPO) and state compatibility constraints

Knowledge check

Official references and version notes

Design baseline: 2026-09-22. Compose is treated as a single-host production model. The chapter does not imply that service-level health, restart policy, or companion containers replace multi-host orchestration, load balancing, backup systems, or external secret management.

• Docker Docs — Use Compose in production — single-host production use, production-specific overrides, and service recreation.
• Docker Docs — Why use Compose? — current single-host deployment boundary and application-model use cases.
• Docker Docs — Compose services reference — healthcheck, restart, read-only rootfs, resource limits, logging, configs, secrets, stop signal and grace period.
• Docker Docs — Compose Deploy Specification — resource limits/reservations and deployment-oriented service controls.
• Docker Docs — Start containers automatically — restart-policy semantics and the successful-start threshold.
• Docker Docs — Resource constraints — CPU/memory governance and OOM implications.
• Docker Docs — Volumes — persistent data lifecycle independent of containers.
• Docker Docs — Storage — writable-layer versus volume/tmpfs durability boundaries.
• Docker Docs — Manage secrets securely in Compose — file-mounted secret access and environment-variable risk.
• Docker Docs — Compose secrets reference — top-level secret sources and service grants.
• Docker Docs — Configure logging drivers — default json-file behavior and recommendation for bounded local logging.
• Docker Docs — Local logging driver — automatic rotation, max-size/max-file, and daemon-owned log files.
• Docker Engine 29 release notes — current Engine-era baseline; 29.8.1 released 2026-09-15.
• Docker Compose releases — current Compose 5.5.1 baseline used for version-sensitive examples.
• Docker Buildx releases — current Buildx 0.37.1 baseline.
• BuildKit releases — current BuildKit 0.33.0 baseline.
• Docker Official Image — registry — current Distribution Registry 3.1.1 local-registry image used in the optional digest-pinning lab path.