Containers, Virtual Machines, Linux Isolation, OCI Standards, and Docker Architecture: Configuration, Design Choices, and Tradeoffs

1. Architecture choices begin with the boundary you need

“Use containers” is not a complete design decision. You still need to decide where the daemon runs, how much privilege it has, whether workloads are mutually trusted, whether VM separation is required, how portable OCI artifacts must be, and which component owns lifecycle. This lesson compares those choices without pretending one mode is universally superior.

2. Container versus VM: optimize for isolation requirements, not slogans

Containers are excellent for packaging userspace and creating fast, repeatable process environments. VMs are useful when you need a separate guest kernel, stronger kernel fault separation, or a fundamentally different operating-system boundary. Many production platforms use both: containers for application packaging inside VM or bare-metal worker nodes.

The decision is about threat model, kernel requirements, operational cost, startup/density goals, and recovery—not about whether one technology is “modern.”

3. Docker Engine versus lower-level runtime APIs

Docker Engine provides a cohesive API and UX for images, containers, networks, volumes, logs, build integration, and administration. containerd and OCI runtimes expose lower-level boundaries used by platforms and engines. Application teams should not bypass Docker's supported Engine API merely because they discover an internal containerd socket.

Current Docker documentation explicitly warns that its managed/embedded containerd endpoint is daemon-owned state and not a general-purpose integration endpoint. Mutating it with external clients can conflict with Docker's expectations. The design principle is simple: use the highest supported API that owns the lifecycle you intend to manage.

4. Rootful and rootless Docker reduce different operational risks

Traditional Docker Engine runs the daemon with root privileges and exposes its Unix socket to authorized clients. Docker's rootless mode runs both daemon and containers without root privileges inside a user namespace, reducing the impact of daemon/runtime vulnerabilities. This is different from merely putting USER 1000 in an image, and it is different from userns-remap, where the daemon remains rootful while container UIDs/GIDs are remapped.

For this chapter, rootless is a conceptual choice only; do not migrate an existing host as a lab. Chapter 26 gives it a controlled setup and compatibility workflow.

5. Native Linux Engine and Docker Desktop have different host boundaries

On native Linux Engine, the daemon host is the Linux machine you administer. Host PID, namespace, cgroup, storage, firewall, and socket evidence can therefore be inspected directly. Docker Desktop inserts a managed Linux VM boundary. That improves desktop portability but changes path resolution, networking, filesystem sharing, process visibility, and performance interpretation.

6. Convenience versus stronger isolation for untrusted workloads

Giving a workload --privileged, broad devices, host PID/network namespaces, sensitive bind mounts, or the Docker socket collapses parts of the isolation model. Those settings can be legitimate for narrowly reviewed system workloads, but they are not debugging conveniences.

When code is untrusted, increase isolation rather than relaxing it: use separate hosts/VMs or dedicated runner pools, rootless/user-namespace strategies where compatible, minimal capabilities, default seccomp/LSM enforcement, read-only filesystems, bounded mounts, and no daemon socket. The specific control depends on the threat model; the direction should be toward fewer privileges.

7. Worked decision table

8. Evaluate five operational dimensions

For any architecture choice, document at least these dimensions:

1. Trust: who can submit container configuration or code, and what host/registry/secret privileges follow?
2. Reproducibility: can you identify the exact image digest, daemon/runtime baseline, and configuration?
3. Failure isolation: does a kernel/runtime/daemon failure affect one container, one host, one VM, or many tenants?
4. Portability: which assumptions are Linux-host-specific, Desktop-specific, architecture-specific, or runtime-specific?
5. Recovery: which state must be rebuilt from source, restored from backup, or reconciled externally?

This turns a “Docker preference” into an auditable engineering choice.

9. Design lab — classify your current environment without changing it

Run only read-only inspection, then complete the worksheet below.

docker context show
docker version
docker info

docker info --format '{{json .SecurityOptions}}' 2>/dev/null || true
docker info --format 'cgroup-driver={{.CgroupDriver}} cgroup-version={{.CgroupVersion}}' 2>/dev/null || true

10. Common wrong approaches

• “Root inside a container means root on the host.” Not automatically; namespaces/capabilities/user mappings matter. But a rootful daemon or dangerous mounts/capabilities can still create severe host risk.
• “Rootless makes every container safe.” No. It reduces daemon/container privilege but does not remove application vulnerabilities, secret exposure, network risk, or resource abuse.
• “Docker Desktop is just Docker Engine installed directly on my laptop OS.” Not for Linux containers; Desktop uses a managed Linux environment/VM boundary.
• “If OCI defines containers, all engines have identical behavior.” OCI defines key portable contracts, not every networking, storage, build, security, or management behavior.
• “I can manage Docker's internal containerd directly because it has a socket.” Docker documents that daemon-owned endpoint as an implementation/debugging surface, not a general-purpose integration contract.

Knowledge check

Summary

Container architecture is a set of boundary choices. Containers and VMs isolate at different layers; Docker Engine and low-level runtimes own different lifecycle contracts; rootful, userns-remap, rootless, and non-root application users solve different privilege problems; Desktop introduces a VM boundary; and untrusted workloads deserve stronger isolation rather than convenient privilege escalation. A sound design states its trust model, platform assumptions, observable evidence, and recovery boundary.

Official references and version notes

Version-sensitive statements in this chapter were rechecked against primary documentation on 2026-09-20. Docker Engine, Docker Desktop, containerd, runc, OCI specifications, security defaults, and platform integration continue to evolve. Record the versions actually reported by your own environment before treating an example as production policy.

• Docker documentation — product documentation and current operating guidance.
• Docker Engine — Engine architecture, daemon, objects, and administration.
• Docker Engine 29 release notes — current 29.x changes; 29.8.1 was released 2026-09-15.
• Docker Engine API — API negotiation and current client/server compatibility guidance.
• Docker Engine security — namespaces, cgroups, daemon attack surface, and kernel hardening.
• Seccomp security profiles — default syscall filtering and why disabling it is not a routine fix.
• Runtime metrics — current cgroup v2 behavior and container cgroup inspection.
• Rootless mode — daemon/container privilege reduction and user-namespace model.
• Docker Desktop on Linux — the VM-backed Desktop execution boundary and desktop-linux context.
• Open Container Initiative — Image, Runtime, and Distribution specifications.
• OCI Runtime Specification — runtime configuration, execution environment, and lifecycle; OCI Runtime Spec v1.3.0 was released in November 2025.