Containers — everything your app needs in one package

Before you touch container networking, spend a minute on what a container actually is. The idea's smaller and simpler than the internet makes it sound.

The one-sentence definition

A container is one package that wraps up your application together with the exact libraries, files, and settings it needs to run — so it behaves the same on any machine that can run containers.

A shipping container

Before shipping containers, cargo was a mess — barrels, crates, sacks. Every port needed its own way of handling things. Then a standard steel box made loading, moving, and unloading the same everywhere. Software containers did that same trick for your apps.

What's inside a container

Your app code

The binary, script, or bundle you built.

Its runtime

Node.js, Python, JVM, .NET — whatever your code needs to execute.

System libraries

OpenSSL, glibc, image libraries — anything your app depends on that isn't part of the runtime.

Config and env

Default env vars, exposed ports, entrypoint command.

Notice what isn't in there: the operating system kernel. Containers borrow the host's kernel instead of carrying their own — and that's exactly why they're so much lighter than VMs.

Container vs virtual machine

VMs vs containers — the layer that gets shared

VMs virtualise hardware. Containers share the kernel and virtualise the process namespace.

The workflow you'll actually use

Write a Dockerfile — a plain text file that spells out how to build the image.
Build the image — docker build -t my-app .
Push it to a registry — Docker Hub, ECR, GHCR, wherever your team keeps images.
Run a container from that image on any host that has a container runtime.

A tiny Dockerfile:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Why the network chapter changes now

Once your apps are packaged as containers, three networking questions suddenly get a lot more interesting:

How do containers on the same host reach each other? → Bridge networks
How does the outside world reach a container? → Port mapping
How do containers on different hosts reach each other? → Overlay networks

"Works on my laptop"

That old excuse dies the moment the environment is the container image. If it runs on your laptop, the exact same image — byte for byte — runs in staging and in production too.

Key takeaways

A container = your app + its dependencies + config, bundled into one image.
Containers share the host kernel — much lighter than VMs.
You build once, ship the image everywhere.
The next three topics focus on how containers reach each other and the outside world.