Containers solve the "works on my machine" problem: the same image runs the same way on a laptop, a CI runner and a production cluster. Because they share the host kernel instead of booting a full operating system, containers start in seconds or less and many of them fit on one server.
How containers work
- Image. A read-only, layered template, usually built from a Dockerfile, that holds the application and everything it needs. Images are stored in registries such as Docker Hub, Amazon ECR or GitHub Container Registry.
- Container. A running instance of an image, with its own writable layer on top.
- Isolation. On Linux, namespaces give each container its own view of processes, network interfaces, mounts and users, and cgroups cap how much CPU, memory and I/O it can use.
- Runtime. containerd, CRI-O or Docker Engine start and stop containers. The Open Container Initiative (OCI) standardizes the image and runtime formats, so images built with one tool run on another.
Containers vs. virtual machines
| Containers | Virtual machines | |
|---|---|---|
| What is virtualized | The operating system: processes share the host kernel | The hardware: each VM runs a full guest OS on a hypervisor |
| Typical size | Megabytes | Gigabytes |
| Startup | Seconds or less | Usually minutes |
| Density | Many per host | Fewer per host |
| Isolation | Weaker, because the kernel is shared | Stronger, because each VM has its own kernel |
The two are often combined: in the cloud, containers usually run on virtual machines.
Running containers at scale
A handful of containers can be run with Docker or Docker Compose. Once you have many services across many hosts, an orchestrator such as Kubernetes, Docker Swarm or Amazon ECS schedules containers onto machines, restarts the ones that fail and scales them with load. Containers are also the usual way to package microservices.
What to monitor
Containers are short-lived and move between hosts, so monitoring tied to a fixed server doesn't fit. Watch:
- CPU usage and throttling against the container's limit
- Memory usage against its limit, and out-of-memory kills
- Restart counts and exit codes
- Network and disk I/O per container
- Logs written to stdout and stderr, collected before the container disappears
Container monitoring with Atatus
Container monitoring discovers Docker, Docker Compose, Swarm and Amazon ECS containers automatically and collects CPU, memory, network, I/O, state and logs for each, and keeps terminated containers visible so you can still investigate them. Kubernetes workloads are covered by Kubernetes monitoring. For a comparison of tools, see Docker container monitoring tools.