What Is a Container?
By the end of this lesson
Explain what a container isolates and what it shares.
A container is an ordinary process running on your machine, started with a deliberately restricted view of that machine. Nothing boots. There is no small computer inside it. The operating system runs the process and then limits what it can see and how much it can use.
One term before going further, because everything here depends on it. The kernel is the part of the operating system that manages processes, memory, files and hardware. Every program on a machine asks the kernel to do that work on its behalf. A container asks the same kernel as everything else on the host, which is the difference the next lesson examines against virtual machines.
What a container gets of its own:
- A filesystem
- Its own root directory tree, built from the image. The /app directory inside the container has no relationship to any /app on your machine, and your home directory is not visible at all.
- A network identity
- Its own network interfaces and its own set of port numbers. Port 8080 inside a container is unrelated to port 8080 on the host until you connect the two deliberately.
- A process list
- It sees only the processes it started. The application is usually process 1 inside the container, even though the host sees it as an ordinary process among hundreds.
- A hostname and user accounts
- Its own hostname, which Docker generates unless you set one, and its own list of users from the image rather than the accounts on your machine.
Two mechanisms: what you can see, and what you can use
Linux provides two features that together produce a container, and knowing which does what makes container behaviour predictable rather than magical.
Namespaces control what a process can see. There is one kind of namespace per sort of resource — processes, filesystem mounts, network, hostname, users — and a process placed in a new namespace sees only what that namespace contains. The other processes on the machine still exist. They are simply not in the list.
Control groups, usually shortened to cgroups, control how much a process can use: memory, CPU time, disk and network throughput. A control group does not hide anything. It caps consumption.
Namespaces answer the question "what exists?". Control groups answer "how much may you have?". Docker configures both when it starts a container, which is most of what Docker actually does.
# Start a shell inside a container built from a small Linux image
docker run -it --rm alpine:3.20 sh
# --- everything below runs inside the container ---
# Almost nothing is running, as far as this process can tell
ps -ef
# A hostname you did not choose
hostname
# Its own root filesystem. Your project folder is not here
ls /
# The kernel version, which belongs to the host, not to the container
uname -r
# Leaving the shell ends the container
exit- -it does two things: -i keeps input open so you can type, and -t attaches a terminal so the shell behaves normally. Without them the shell starts and exits immediately.
- --rm removes the container when its process ends. Without it the stopped container stays on your machine, which is how people end up with dozens of them.
- ps -ef lists two processes: the shell and ps itself. That is the process namespace at work. The host is as busy as it ever was.
- uname -r is the interesting one. It reports the host's kernel version, because that is the kernel the container is using. Run the same command outside the container and the answer matches.
Sorting the same container into what is genuinely its own and what it borrows:
| Its own | From the host | |
|---|---|---|
| Process view | A list containing only its own processes | Those processes are ordinary host processes, visible in the host's own process list |
| Filesystem | A root filesystem assembled from the image | The actual disk those files are stored on |
| Network | Its own interfaces, addresses and port numbers | The physical network and the host's routing |
| Kernel | None of its own | The host kernel, shared by every container on the machine |
| Memory and CPU | A limit it has to stay inside, if you set one | The same physical memory and the same cores as everything else |
Summary
- A container is a normal host process given a restricted view of the machine
- Namespaces decide what it can see; control groups decide how much it can use
- It has its own filesystem, network and process list, and no kernel of its own
- Sharing the kernel buys speed and density, and means the isolation boundary is weaker than a separate machine
- Resource limits are something you configure, not a default
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Try it yourself
Compare the inside and the outside
Start a shell in a small Linux container and run uname -r, hostname and ps -ef.
Open a second terminal on your own machine and run the same three commands there. Which outputs differ, and which one matches?
Show solution
The hostname and the process list differ, because both are namespaced. The kernel version matches, because there is only one kernel involved.
That single matching line is the whole concept. The container has its own view of the machine and none of its own operating system core. Everything else about container behaviour — the speed, the size, the fact that a Linux image will not run on a Windows kernel — follows from it.
docker run -it --rm alpine:3.20 sh
# inside: uname -r ; hostname ; ps -ef
# then, in another terminal on your machine:
uname -r
hostnameThink about it
Think about it
Both a Linux laptop and a Windows laptop can run Docker. Why can a container image built for a Windows kernel not run on the Linux laptop, when a virtual machine image could?
Show solution
The container carries no kernel. The program inside it makes requests to whatever kernel is on the host, and a program built for Windows expects Windows kernel interfaces that a Linux kernel does not provide.
A virtual machine brings its own kernel along, so it does not care what the host runs. That is the cost of its extra size and start-up time — the thing you are paying for is exactly this independence.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.