Docker

Technical Definition

Docker is a containerisation platform that uses Linux kernel features — namespaces for process, network and filesystem isolation, and control groups (cgroups) for resource limiting — to run isolated user-space instances (containers) that share the host kernel rather than running a separate guest kernel as a virtual machine would. A Docker image is a read-only, layered filesystem snapshot built from a Dockerfile; a container is a running instance of that image with a writable layer on top. The Docker Engine (dockerd) manages images, containers, networks and volumes, and exposes this functionality through a client-server API consumed by the Docker CLI and other tooling.

Operational Relevance

Docker is used to make application deployment reproducible: the same image that passed testing is the image that runs in production, reducing configuration drift between environments. Operationally this matters for build pipelines, local development parity, and horizontal scaling, since multiple containers from one image can be started or stopped quickly without provisioning full virtual machines. It also introduces operational responsibilities that are easy to overlook: image provenance and patching, resource limits per container, log and volume lifecycle management, and network exposure of container ports.

Architecture Relationship

Docker sits between the operating system kernel and the orchestration layer. On a single host, Docker Engine is the runtime that creates and manages containers directly. In larger systems, orchestrators such as Kubernetes typically do not use the full Docker Engine themselves; they use a container runtime conforming to the Container Runtime Interface (CRI), which may or may not be Docker-derived depending on the current cluster configuration. Docker images are commonly stored in a registry (public or private) and pulled by hosts or orchestrators at deployment time. Docker networks and volumes provide the connectivity and persistent storage primitives that containers use when the default ephemeral, isolated container filesystem is insufficient.

Example

A typical bounded workflow is validating a container image locally before it is promoted anywhere else:

1. Build an image from a Dockerfile in an isolated development or CI environment.
2. Run the resulting image as a container with resource limits and a mapped port.
3. Inspect the running container’s logs and status to confirm the application started correctly.
4. Stop and remove the test container once validation is complete, leaving the host state unchanged.

Common Misunderstanding

A frequent misunderstanding is that a Docker container is a lightweight virtual machine. It is not: a container shares the host’s kernel and does not virtualise hardware or run a separate operating system kernel. This is why containers start in a fraction of the time a VM takes, but it is also why kernel-level vulnerabilities or misconfigurations on the host can have a more direct effect on containers than on properly isolated virtual machines. Treating container isolation as equivalent to VM-level isolation can lead to under-provisioned security boundaries.

Related Terms

• Container image: the read-only template a container is instantiated from.
• Dockerfile: the declarative build instructions used to produce an image.
• Container registry: a storage and distribution service for images, such as Docker Hub or a private registry.
• Kubernetes: an orchestration system that schedules and manages containers, often but not exclusively via Docker-derived runtimes, across multiple hosts.
• cgroups and namespaces: the underlying Linux kernel mechanisms Docker relies on for resource limiting and isolation.

Further Reading and Verified Operational Checks

Before relying on Docker in any environment, confirm the installed Docker Engine version and the permissions of the account running Docker commands, since command availability and daemon behaviour can vary by version and by whether the user has been granted access to the Docker daemon socket. Validate any container-based workflow first in an isolated or non-production environment.

• Confirm the Docker daemon is active and responding before treating any container action as reliable evidence of application state.
• Review resource limits (CPU, memory) assigned to containers rather than assuming defaults are adequate for production-equivalent testing.
• Treat image provenance as a security boundary: only run images from sources whose build process and contents have been verified.

When these checks pass, the next safe decision is to promote the validated image reference (not a rebuilt or mutated one) to the next environment stage, keeping the build-once, run-anywhere property intact.