Container Strategy

Status: Stub Category: Infrastructure Default enforcement: Advisory Author: PushBackLog team

Tags

• Topic: infrastructure, containers, devops
• Skillset: devops, backend
• Technology: docker, kubernetes
• Stage: deployment, architecture

Summary

Containerisation packages an application and its dependencies into a portable, isolated unit that runs consistently across environments. A container strategy covers how images are built, versioned, stored, and run — from local development through to production — along with the security and operational hygiene that determines whether containers deliver their promise of consistency and isolation in practice.

Rationale

Containers eliminate the classic “it works on my machine” problem by encoding the full runtime environment — OS libraries, language runtimes, configuration — into a reproducible image. They enable consistent environments across development laptops, CI pipelines, staging, and production, and they are the foundational unit of most modern cloud deployment platforms.

Without a deliberate container strategy, teams build images ad-hoc, accumulate security vulnerabilities in unscanned base images, embed secrets in layers, and operate containers with excessive permissions. A strategy codifies sensible defaults before ad-hoc decisions compound into technical debt.

Guidance

Image hygiene

A good container image is:

• Small — use minimal base images (alpine, distroless, slim variants) to reduce attack surface and pull time
• Layered deliberately — order Dockerfile instructions from least-frequently to most-frequently changed; stable layers are cached and not rebuilt unnecessarily
• Multi-stage — separate build-time dependencies from the final runtime image; do not ship compilers, test frameworks, or build tools to production
• Non-root — applications should not run as root inside the container; create a dedicated application user

Image versioning and tagging

Never deploy latest to production. Always deploy a specific digest or tag that can be traced back to a repository commit.

Registry management

• Use a private registry for application images (AWS ECR, Google Artifact Registry, GitHub Container Registry)
• Enable image scanning in the registry; block deployment of images with critical CVEs
• Implement lifecycle policies to clean up old images and prevent unbounded registry growth
• Restrict push permissions to CI/CD pipelines; developers should not push to production-serving registries directly

Runtime security

Orchestration considerations

For multi-container deployments, an orchestration layer (Kubernetes, ECS, Nomad) handles scheduling, health checks, scaling, and service discovery. The container strategy must align with the orchestration platform’s:

• Health probe requirements — containers must expose liveness and readiness probes
• Graceful shutdown — containers must handle SIGTERM and complete in-flight requests before exiting
• Configuration injection — environment variables and secrets are injected by the orchestrator, not baked into images
• Log routing — containers write to stdout/stderr; the orchestrator routes logs to the observability stack

Common failure modes

Part of the PushBackLog Best Practices Library