Containers and Docker Explained: What They Really Are

The standard explanation is that a container is a lightweight virtual machine. It is a useful first approximation and it is wrong in a way that matters, because it leads directly to two common mistakes: treating containers as secure isolation boundaries, and treating them as long-lived servers.

A container is not a machine at all. It is a normal process running on the host's operating system, with the kernel restricting what it can see. Its own filesystem, its own network interface, its own view of the process table — but the same kernel as everything else on the host.

That single distinction explains why containers start in milliseconds, why they are so small, and why the security story is more nuanced than a virtual machine's.

Why the difference matters

A virtual machine emulates hardware and runs a complete guest operating system with its own kernel. That is why it takes tens of seconds to boot and occupies gigabytes: it genuinely is a computer, simulated.

A container shares the host kernel and isolates a process using kernel features — namespaces to control what it can see, and control groups to limit what it can consume. Starting one is close to starting any other process, because that is essentially what it is.

The practical consequences follow directly. Containers start almost instantly and are cheap enough to run dozens on one machine. They also share a kernel, so a kernel vulnerability is a shared risk in a way it is not between virtual machines — which is why untrusted, multi-tenant workloads are usually given stronger isolation.

Images, layers and why builds are fast

An image is a read-only template; a container is a running instance of one. Images are built in layers, each layer being the filesystem changes made by one build instruction.

Layers are cached and shared. If ten images are built on the same base, that base is stored once. If you rebuild after changing only your application code, every layer before that change is reused from cache and the build takes seconds.

This is why instruction order in a build file matters so much, and why so many builds are needlessly slow.

Containers should be disposable

The mental shift that separates people using containers well from people fighting them is this: a container is not a server you maintain. It is something you throw away and recreate.

Anything written inside a running container disappears when it is replaced, which is a feature rather than a limitation. It means every container starts from a known state and there is no such thing as configuration drift.

It also imposes a rule: persistent state must live outside. Databases use mounted volumes, uploaded files go to object storage, sessions go to a shared cache, and configuration arrives through environment variables. A container that stores something important on its own filesystem will lose it on the next deploy.

Writing images that behave

Multi-stage builds deserve particular attention because the saving is so large. Build your application in one stage that contains compilers, package managers and build tools, then copy only the finished artefact into a clean, minimal final stage. Images routinely drop from over a gigabyte to under a hundred megabytes, and everything you removed was also attack surface.

Security realities

Containers provide meaningful isolation and are not a security boundary equivalent to a virtual machine. Three habits cover most of the practical risk.

• Do not run as root. The default is root, and a compromised process running as root inside a container is a considerably worse day than one running as an unprivileged user.
• Never put secrets in an image. Layers are permanent: a secret added in one instruction and deleted in the next is still present in the layer history and readable by anyone with the image.
• Scan and update base images. A base image pinned two years ago carries every vulnerability disclosed since. Rebuilding regularly is a security control, not housekeeping.

When you need an orchestrator, and when you do not

Kubernetes is frequently introduced far earlier than it is needed. It solves genuine problems — scheduling across many machines, rolling updates, service discovery, self-healing — and it brings substantial operational complexity in exchange.

For a handful of services on one or two machines, a compose file or a managed container service is usually a better fit. The honest question is whether you have the scale that creates the problems Kubernetes solves, or whether you are adopting it because it is what serious companies use.

Containers solve 'it works on my machine' by making the machine part of the artefact. Everything else about them follows from that one idea.

Summary

A container is an isolated process sharing the host kernel, which is why it starts instantly and stays small. Images build in cached layers, so install dependencies before copying source. Keep containers disposable and state external. Use multi-stage builds, minimal bases, non-root users and pinned versions, and keep secrets out of images entirely.

Conclusion

Containers became standard because they solved a real and expensive problem: the gap between the environment where code was written and the one where it runs. Package the environment with the code and that gap closes.

Understand what they actually are and the rest follows naturally — including which of the surrounding tools you genuinely need. Your CI/CD pipeline is where most of these habits either get enforced or quietly skipped.