1. Keep Container Images Lean

Every binary, library, and daemon you package into a container image is a liability: it increases image size, lengthens pull times, and may consume CPU or memory at runtime. Build images that contain only what your application actually needs at run time.

• Start from a minimal base image. Alpine Linux-based images (e.g., python:3.12-alpine) are often tens of megabytes smaller than their Debian or Ubuntu counterparts.
• Use multi-stage builds. Compile or bundle assets in a build stage, then copy only the final artifacts into a slim runtime image. This keeps compilers, test tools, and build dependencies out of production images.
• Remove unnecessary services. If your application does not need an SSH daemon, cron, or a mail server, do not include them. Unnecessary services waste resources and expand the attack surface.
• Combine RUN instructions. Each RUN layer in a Dockerfile adds metadata and can leave behind cached package lists. Chain related commands (apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*) to keep layers small.

2. Run Docker on Bare-Metal Hosts

Nesting containers inside a full virtual machine (VM) introduces a second layer of abstraction. The hypervisor consumes CPU cycles and memory for emulation, and I/O must traverse both the VM’s virtual device stack and the host’s physical stack. Running Docker directly on a bare-metal server eliminates that overhead.

If workload isolation is still required, consider system container runtimes such as LXD or OpenVZ. These provide a lightweight guest environment with process and namespace isolation while allowing near-native hardware access — a middle ground between full VMs and uncontained processes.

3. Use a Minimalist Host Operating System

The host OS competes with your containers for CPU, memory, and I/O bandwidth. A general-purpose Linux distribution running a full desktop environment, logging agents, and system services you do not need will reduce the resources available to containerized workloads.

Purpose-built container host operating systems are designed to run Docker (or another container runtime) and little else. Examples include:

• Alpine Linux — extremely small footprint, suitable for both container images and host OS use.
• Flatcar Container Linux (the community continuation of CoreOS Container Linux) — immutable, auto-updating, built specifically for running containers at scale.
• Bottlerocket (AWS) — a security-focused, minimal host OS for container workloads.

Whichever host OS you choose, verify that it still meets your security requirements: kernel hardening, SELinux/AppArmor profiles, audit logging, and timely security patch delivery are non-negotiable in production.

4. Adopt a Microservices Architecture

A monolithic application bundled into a single container starts slowly, scales awkwardly, and redeploys entirely even when only one feature changes. Decomposing your application into microservices — small, independently deployable services each running in its own container — offers several performance benefits:

• Faster startup. A container running a single focused service loads less code and initialises fewer dependencies.
• Granular scaling. You can scale only the service under load, rather than duplicating the entire monolith.
• Faster deployments. Updating one microservice redeploys only its small image rather than the entire application.

Microservices introduce their own complexity (network latency between services, distributed tracing, service discovery), so weigh the trade-offs for your specific workload.

5. Leverage Docker’s Build Cache

Docker caches the result of each Dockerfile instruction. If the instruction and its inputs have not changed since the last build, Docker reuses the cached layer instead of re-executing the step. Used correctly, this can dramatically shorten image build times in CI/CD pipelines.

Key guidelines for effective cache use:

• Order instructions from least to most frequently changed. Place COPY instructions for dependency manifests (package.json, requirements.txt) before copying application source code. That way, dependency installation is only re-run when manifests change.
• Understand cache invalidation. Any change to a layer — including a file modification or an updated base image digest — invalidates all subsequent layers. Structure your Dockerfile to minimise the blast radius of common changes.
• Use --cache-from in CI. Pass a previously built image as a cache source in pipeline builds where the local layer cache is not persisted between runs.
• Be cautious with apt-get update. If cached, apt-get update can produce stale package metadata. Always pair it with apt-get install in the same RUN instruction so both are invalidated together.

Summary

Optimising Docker performance is not a single configuration switch — it spans image design, infrastructure choices, application architecture, and build tooling. The five strategies above form a strong baseline:

1. Build lean, minimal container images.
2. Run Docker on bare metal (or lightweight system containers) where possible.
3. Use a purpose-built, minimal host OS.
4. Break monoliths into microservices for faster startup and targeted scaling.
5. Structure Dockerfiles to exploit the build cache effectively.

Apply these techniques incrementally, measure the impact in your specific environment, and prioritise the changes that deliver the greatest gain for your workload profile.

Original source reference: containerjournal.com (2017)