Docker / Images and container fundamentals / Lesson 1
Processes, isolation, and the Docker model
Build a precise mental model before interpreting commands or trusting isolation boundaries.
On this page
Lesson goals
- Separate image, container, engine, client, and registry responsibilities.
- Compare Linux containers with virtual machines and inspect identity safely.
A container is an isolated process environment
A Linux container runs processes with selected namespaces, filesystem views, resource controls, and security restrictions. It shares the host kernel; it does not boot an independent guest kernel like a traditional virtual machine. This makes startup and distribution convenient, but a kernel vulnerability or excessive privileges can cross assumptions about isolation. Docker Desktop normally places Linux containers inside a managed virtual machine on other operating systems, adding a separate boundary.
Know who receives a command
The docker client sends API requests to an engine selected through configuration and context. The engine creates and supervises containers and stores local image content. A registry distributes image manifests and blobs. A terminal that looks local can address a remote engine, so checking command syntax alone does not establish the affected machine. This course never accesses any daemon; commands are review-only illustrations for a separately authorized disposable laboratory.
docker context show
docker context inspectThese commands describe the selected context and its endpoint configuration. Names and paths depend on the installation, so no fabricated output is supplied. A context describes where a command would go; it does not prove that the endpoint is reachable, isolated, or approved for experimentation.
An image is not a running container
An image packages immutable filesystem layers and configuration such as the default command. Creating a container adds runtime configuration and a writable layer; starting it launches the configured process. Several containers can share image content while having independent runtime state. A stopped container still exists, whereas an image remains a template. Neither a recognizable name nor an image tag proves that an application is currently running or healthy.
docker container inspect parcel-api
docker image inspect parcel-api:labThe first query addresses an existing container named parcel-api; the second addresses an image reference. Their ids, state, mounts, and configuration answer different questions. Both require an authorized engine and existing objects; absence is a legitimate diagnostic result, not a reason to create resources blindly.
Use a small explicit teaching application
Later lessons describe parcel-api, a synthetic HTTP service with app.py, a Dockerfile, and optional compose.yaml in one lab directory. It listens on container port 8080 and has no real customer data or credentials. Python is only the fixture language; the learning goal is container behavior. Image tags used for readability are mutable examples, and advanced lessons explain how reviewed digests and dependency inputs improve release reproducibility.
Isolation needs an explicit threat model
Running as container root is not equivalent to unrestricted host root in every configuration, yet default rootful engines and dangerous mounts can grant substantial host influence. A mounted Docker socket effectively exposes powerful daemon operations. Namespaces do not replace patching, least privilege, resource limits, or secret handling. Decide which processes and users may access the engine before treating containers as a security boundary between untrusted tenants.
Common errors and fixes
Cannot connect to the Docker daemon.
- Why it happens
- The selected endpoint may be unavailable or unintended; this does not prove a Dockerfile error.
- How to fix it
- Inspect client context and contact the authorized environment owner before changing services.
- Prevent it next time
- Document endpoint ownership and separate disposable lab access from operational credentials.
No such container: parcel-api.
- Why it happens
- An image reference was confused with a container name, or the object exists in another context.
- How to fix it
- Confirm object kind and approved context, then inspect the intended existing object.
- Prevent it next time
- Record container and image identifiers separately in diagnostic notes.
A container is assumed to provide VM-grade kernel separation.
- Why it happens
- Shared-kernel isolation was mistaken for a separate guest operating system.
- How to fix it
- Choose an appropriate isolation architecture for the actual trust boundary.
- Prevent it next time
- Review kernel sharing, daemon privileges, mounts, and tenant trust together.
Check your understanding
1. Two containers use the same image. Must their writable files remain identical?
Show worked solution
No. They share immutable image content but have separate writable layers and runtime configuration. A write in one container does not modify the image or the other container's layer. Shared mounts can deliberately connect their data, which must be reviewed independently of image sharing.
2. Why inspect the active context before interpreting a surprising container list?
Show worked solution
The client may address another local socket, a rootless engine, or a remote endpoint. Listing objects from the wrong engine can look like data loss while the intended objects remain elsewhere. Establish endpoint identity first, then compare object ids through an authorized read-only inspection.
Key takeaways
- Distinguish process isolation, image identity, and runtime state.
- A context identifies an endpoint; it never authorizes experiments.