Docker Vocabulary: 30 Essential Terms for Containerisation

Docker changed how we build, ship, and run software. If you work in a modern development team, you will encounter Docker daily — in local development, CI pipelines, and production deployments. This guide covers 30 essential terms with clear definitions and real conversation examples.

---

Images and Containers

Image

A Docker image is a read-only template that contains everything needed to run an application: the OS, runtime, dependencies, and your code. An image is built from a Dockerfile and stored in a registry. It does not run on its own — you create containers from it.

“Pull the latest image before running the tests: docker pull myapp:latest."
"The image is 1.2 GB — let’s optimise it using a multi-stage build.”

Container

A container is a running instance of an image. It is isolated from the host and other containers (separate filesystem, network, and process space), but shares the host OS kernel. Containers are ephemeral by default — when they stop, their data is gone unless you use a volume.

“Start a container in detached mode: docker run -d myapp:latest."
"The container crashed — check the logs with docker logs <container-id>.”

Tag

A tag is a label applied to an image to identify a specific version. The default tag is latest, but you should always tag images with a meaningful version (e.g., a git commit SHA or a release number).

“Tag the image with the commit SHA so we can trace exactly which code is running in production."
"Avoid relying on latest in production — it changes silently when you build a new image.”

Registry

A registry is a storage and distribution system for Docker images. Images are pushed to and pulled from a registry.

“Push the image to the registry after the CI build: docker push myrepo/myapp:v1.2.0.”

Docker Hub

Docker Hub is the default public registry. It hosts millions of official and community images — Node.js, Postgres, Nginx, and many more.

“Use the official Postgres image from Docker Hub as the base for our database service.”

Layer

Docker images are composed of layers. Each instruction in a Dockerfile creates a new layer. Layers are cached — if a layer hasn’t changed, Docker reuses the cached version, making builds faster.

“Put RUN npm install before COPY . . so the dependency layer is cached and doesn’t reinstall on every code change."
"The build is slow because the COPY step invalidates the cache and forces a full npm install.”

---

The Dockerfile

FROM

FROM sets the base image for subsequent instructions. Every Dockerfile starts with a FROM.

“Use FROM node:20-alpine instead of FROM node:20 — the Alpine variant is much smaller.”

RUN

RUN executes a command during the image build. Each RUN instruction creates a new layer.

“Combine multiple RUN commands into one with && to reduce the number of layers.”

COPY

COPY copies files from the build context (your project directory) into the image.

“Use COPY package*.json ./ before copying the rest of the code so the dependency install is cached.”

EXPOSE

EXPOSE documents which port the container listens on. It is informational — you still need to map the port with -p when running the container.

“EXPOSE 3000 tells anyone reading the Dockerfile that the app listens on port 3000.”

CMD

CMD specifies the default command to run when a container starts. It can be overridden at docker run time.

“The CMD is node server.js — you can override it with bash to get a shell inside the container.”

ENTRYPOINT

ENTRYPOINT sets the executable that always runs in the container. Unlike CMD, it is not easily overridden. Use it when the container should always run a specific binary.

“We use ENTRYPOINT so the container always runs our app binary, regardless of any extra arguments passed.”

---

Build Context

Build Context

The build context is the set of files Docker sends to the daemon when you run docker build. By default it is the current directory. Large build contexts (with node_modules, .git, etc.) slow down builds.

“Add node_modules to .dockerignore — there’s no reason to include it in the build context.”

.dockerignore

.dockerignore works like .gitignore — it excludes files and directories from the build context. Always exclude node_modules, .git, and secrets.

Multi-Stage Build

A multi-stage build uses multiple FROM instructions in one Dockerfile. Earlier stages build the application; the final stage copies only the compiled artefacts, resulting in a much smaller production image.

“The final image only contains the compiled binary — everything else was discarded in the multi-stage build."
"We went from a 900 MB image to 60 MB by using a multi-stage build.”

Distroless

Distroless images contain only the application and its runtime dependencies — no shell, no package manager, no OS utilities. They are smaller and have a much smaller attack surface.

“The production image is distroless — you can’t exec into it, so make sure your logging and health checks are in order.”

---

Running and Networking

Volume

A volume is a persistent storage mechanism that lives outside the container’s writable layer. Data in a volume survives container restarts and removals.

“Mount a volume for the database data directory so it persists when the container is recreated."
"Use a named volume for the database — anonymous volumes are hard to manage.”

Network Bridge / Host / Overlay

Docker supports several network drivers:

• Bridge — the default. Containers on the same bridge network can communicate; the network is isolated from the host.
• Host — removes network isolation; the container shares the host’s network stack. Fast, but less secure.
• Overlay — connects containers across multiple hosts. Used in Docker Swarm and Kubernetes.

“Both containers are on the same bridge network, so they can reach each other by container name."
"Use an overlay network to allow containers on different nodes to communicate.”

Docker Compose

Docker Compose defines and runs multi-container applications using a docker-compose.yml file. It is the standard tool for local development environments.

“Start the whole stack with docker compose up -d — it starts the app, database, and Redis together."
"The docker-compose.yml defines the services, volumes, and networks for the local environment.”

Healthcheck

A HEALTHCHECK instruction in a Dockerfile (or Docker Compose) tells Docker how to check whether a container is healthy. Docker periodically runs the check and marks the container healthy or unhealthy.

“Add a HEALTHCHECK to the Dockerfile so Docker knows when the app is ready to receive traffic.”

Push and Pull

Push uploads an image to a registry. Pull downloads an image from a registry.

“The deployment pipeline builds the image, pushes it to the registry, and then the server pulls and runs the new version.”

---

How to Use This in Conversation

In local development:

“Run docker compose up to start the environment. The database and Redis start automatically.”

In CI/CD:

“The pipeline builds the image, runs the tests inside a container, and then pushes the image to ECR if all tests pass.”

In code review:

“The COPY . . instruction is too early — move it after the dependency install so the cache works properly.”

In incident response:

“The container was OOMKilled — it hit its memory limit. Either increase the limit or investigate the memory usage.”

When onboarding someone:

“A container is just an isolated process. The image is the blueprint; the container is the running instance — like a class versus an object.”

Docker vocabulary is one of the most transferable skills in modern development. Once you are comfortable with these terms, you can follow deployment pipelines, contribute to infrastructure discussions, and debug containerised applications with confidence.