Containers and images
Containers and images
Container vs virtual machine
graph TB
subgraph VMs
H1[Hardware] --> HV[Hypervisor]
HV --> G1[Guest OS + App]
HV --> G2[Guest OS + App]
end
subgraph Containers
H2[Hardware] --> OS[Host OS kernel]
OS --> CR[Container runtime]
CR --> C1[App]
CR --> C2[App]
end
A container is a process on the host kernel, isolated by namespaces and limited by cgroups. No guest OS, so start-up is milliseconds.
Image
Read-only template built from layers; each Dockerfile instruction adds one. Layers are shared and cached. The running container adds one thin writable layer that disappears when the container is removed - which is why data belongs in a volume.
graph BT
L1[nginx:1.27 base layers] --> L3[COPY site content]
L3 --> RW[container writable layer]
Networking - four modes
| Mode | Use |
|---|---|
bridge | default; private network per host, published ports via NAT |
host | container shares the host network stack |
none | no network |
container | reuse another container’s network namespace - this is what a Pod does |
Containers on a user-defined network resolve each other by name. Kubernetes does the same thing, except the name keeps working when the container is replaced. That is a Service.
Data persistence
- Volume - managed by the engine. Preferred.
- Bind mount - a host path mounted in. Handy for development.
- tmpfs - memory only.
Dockerfile
FROM nginx:1.27-alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80
Put the instructions that change least at the top: everything below a changed layer is rebuilt.