Docker

Docker is a platform for building, distributing and running applications as containers. A container is an isolated process that carries the application and its dependencies, so it does not rely on software installed on the host.

How it works

The docker client sends commands to the Docker daemon, dockerd, which manages images, containers, networks and volumes. An image is a read-only template built from a Dockerfile, where each instruction produces a layer. Rebuilding regenerates only the layers that changed, which is why instruction order matters for speed.

Images are stored in registries such as Docker Hub, Amazon ECR or Google Artifact Registry. Running an image creates a container with a writable layer on top. Linux namespaces isolate each container, and unsaved state is lost when the container is removed.

Containers differ from virtual machines in that all containers on a host share the same kernel, so they are lighter and start faster. VMs bundle a full operating system with its own kernel.

A practical example

A multi-stage build compiles in one stage and ships only the result:

FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=build /app /app
USER 65532:65532
ENTRYPOINT ["/app"]

Copying the dependency files before the source keeps the download step cached when only code changes.

Common mistakes

• Running as root when the service does not need it. Docker’s guidance is to create a user and switch with USER.
• Shipping build tools in the final image instead of using multi-stage builds.
• Skipping a .dockerignore, which sends unneeded files into the build.
• Relying on a moving tag. A digest pins the exact image, though you then need a process to pick up security updates.
• Storing data in the container filesystem and expecting it to persist.

When to use it and when not to

Docker suits services that need a consistent runtime across development, CI and production, and it is the usual entry point to Kubernetes. It is less suitable where strong isolation between tenants is required, because containers share a kernel, or for workloads that need direct hardware or special kernel features. Keep each container focused on one concern. For help with image standards and pipelines, see Docker containerisation.

See also

• Kubernetes
• Infrastructure as Code
• CI/CD
• Multi-stage Dockerfile builds