Docker & Containers for Beginners

Key terms in plain words

• Kernel: the core part of an operating system. It controls the CPU, memory, disk and network for all programs.
• Virtual machine (VM): a pretend computer, run by software, that has its own full operating system. A hypervisor is the software that creates and runs VMs.
• Container: a normal process on a machine that is isolated (kept apart) from other processes. It looks like a small computer to the app inside, but it uses the host's kernel.
• Image: a read-only package that contains your app and everything it needs. A Dockerfile is a text file with the steps to build an image.
• Registry: a server that stores images so that other machines can download (pull) them.
• Volume: a folder that lives outside the container, so its data stays after the container is deleted.
• stdout and stderr: the two normal output streams of a program. Normal messages go to stdout. Error messages go to stderr.
• Root: the all-powerful user account on Linux. It can change anything on the machine.
• Environment variable: a named setting (like DATABASE_URL) that you give to a program from outside, when it starts. The program reads it while it runs.
• Lockfile: a file (like package-lock.json) that records the exact version of every library your project uses, so every install gets the same versions.
• YAML: a plain-text format for settings, written as indented key: value lines. Docker Compose files use it.
• Port: a number that picks one network door on a machine. 8080:3000 means "machine port 8080 leads to container port 3000".

Containers vs virtual machines

How containers work on Linux:

• Namespaces are a Linux feature that gives each container its own view of the system: its own process list, network interfaces, file system, hostname and users. The container "thinks" it is alone on the machine.
• cgroups (control groups) are a Linux feature that limits resources. For example: "this container can use at most 1 CPU and 512 MB of memory".
• A layered file system (like OverlayFS) stacks the read-only image layers on top of each other. A thin writable layer goes on the very top. A "layer" is one set of file changes made by one Dockerfile step.

Containers are isolated processes, not tiny virtual machines. That is why they are fast and light. (If you need stronger isolation, you can use gVisor, which adds an extra layer between the container and the kernel, or Firecracker, which starts very small and fast VMs.)

Images, containers and registries

• Image: a read-only template. It holds your app plus everything it needs, and you build it from a Dockerfile. Think of it as a recipe with all the ingredients, packed in a box.
• Container: a running copy of an image. It is the dish that was cooked from the recipe. You can run many containers from one image.
• Registry: a place to store and share images. Examples are Docker Hub, GitHub Container Registry (GHCR), Amazon ECR and Google Artifact Registry.

A Dockerfile, step by step

Here is a simple Dockerfile for a Node.js API. It is not optimised yet. Each line is an instruction: FROM picks the base image, WORKDIR sets the folder, COPY copies files in, RUN runs a command while building, EXPOSE documents the port, and CMD is the command that starts the app.

FROM node:24WORKDIR /appCOPY . .RUN npm installEXPOSE 3000CMD ["node", "server.js"]

It works, but the image is large (the full Node image plus dev tools). Also, every code change reinstalls all dependencies.

A better Dockerfile is a multi-stage one. It uses more than one FROM. The first stage builds the app. The second stage is the small image that you ship. (npm ci installs the exact versions from the lockfile, and it fails if the lockfile does not match package.json.)

# ---- Stage 1: build ----FROM node:24-slim AS buildWORKDIR /app# Copy the dependency files FIRST (so Docker can cache this step)COPY package*.json ./# Install the exact versions listed in the lockfileRUN npm ciCOPY . .# For example, compile TypeScriptRUN npm run build# Remove the dev dependencies (tools only needed to build)RUN npm prune --omit=dev# ---- Stage 2: run ----FROM node:24-slimWORKDIR /appENV NODE_ENV=productionCOPY --from=build /app/node_modules ./node_modulesCOPY --from=build /app/dist ./dist# Do not run as root (the all-powerful user)USER nodeEXPOSE 3000CMD ["node", "dist/server.js"]

Why this is better:

• Layer caching. Docker saves (caches) the result of each step and reuses it if nothing changed. Here package.json is copied before the source code. So dependencies are only reinstalled when they change, not on every code edit. Builds can go from minutes to seconds.
• Multi-stage builds. Compilers, dev dependencies and build tools stay in the first stage. The final image contains only what is needed to run. So it is smaller, faster to download and has less for an attacker to target.
• Slim base images. A base image is the image you start from (the FROM line). Small ones, such as -slim, alpine or distroless (almost nothing except your app and its runtime), reduce size and the number of known security holes.
• A non-root user. If an attacker breaks into the app, they do not get root power inside the container.

A .dockerignore file tells Docker which files to leave out of the image (so they are not copied by COPY . .):

node_modules.git.env*.logcoverage

⚠️ Never put secrets in images (like .env files, API keys or COPY credentials.json). Anyone who downloads the image can read them, even from old layers. Pass secrets when the container starts instead (post 51).

Running containers

docker build -t myshop/api:1.4.2 .# -p: connect port 8080 on your machine to port 3000 in the container# -e: pass settings as environment variables# --memory / --cpus: limits on memory and CPU (these use cgroups)docker run -d --name api \  -p 8080:3000 \  -e DATABASE_URL=postgres://... \  --memory 512m --cpus 1 \  myshop/api:1.4.2docker ps                  # list the running containersdocker logs -f api         # follow the logs (your app should write logs to stdout)docker exec -it api sh     # open a shell inside the container (for debugging)docker stop api

Key ideas:

• Containers are disposable. Anything written inside the container disappears when the container is removed. Store data in volumes, databases or object storage (post 17).
• Volumes keep data outside the container, so the data stays after the container is gone: -v pgdata:/var/lib/postgresql/data.
• Configuration comes from the environment, not from inside the image (this is an idea from the Twelve-Factor App, a well-known list of good practices for web apps). One image can move through dev, staging and production with different settings.
• Logs go to stdout and stderr. The platform collects them from there (post 46).

Tags vs digests

• Tags like myshop/api:1.4.2 or :latest are labels that can be moved to point at a different image later.
• Digests like myshop/api@sha256:9f86d0… identify one exact image forever. A digest is a hash (a fingerprint) of the image content.

Avoid :latest in production. You cannot tell which version is running, and the image behind the tag can change without warning. Use version tags (or git commit SHAs). For the most safety, deploy by digest.

Docker Compose for local development

Docker Compose is a tool that runs a whole set of containers from one YAML file, with one command. It solves the "new teammate spends two days installing things" problem:

# docker-compose.ymlservices:  api:    build: .    ports: ["8080:3000"]    environment:      DATABASE_URL: postgres://app:secret@db:5432/shop      REDIS_URL: redis://cache:6379    depends_on: [db, cache]  db:    image: postgres:16    environment:      POSTGRES_USER: app      POSTGRES_PASSWORD: secret      POSTGRES_DB: shop    volumes: ["pgdata:/var/lib/postgresql/data"]  cache:    image: redis:7volumes:  pgdata:

docker compose up     # starts the API, PostgreSQL and Redis, all connected on one network

Services find each other by name (db, cache). This is service discovery in a small form (post 54). Note that depends_on only controls the start order. It does not wait until the database is ready to accept connections. (The passwords above are only for local development. Never use them in real environments.)

The container ecosystem and standards

• The Open Container Initiative (OCI) is a group that defines standard image and runtime formats. Because of this, images built with Docker run on any platform that follows the standard.
• containerd and runc are the low-level programs that actually run containers. Docker uses them inside, and so does Kubernetes.
• Podman is a popular Docker alternative. It can run without a daemon (a program that always runs in the background) and as a non-root user.
• Kubernetes (post 56) is a system that starts, stops and manages containers across many machines. It runs OCI images and does not need Docker itself on the servers.

Container security basics

• ✅ Minimal base images. Rebuild regularly to get security patches.
• ✅ Scan images for known security holes (vulnerabilities) with tools like Trivy or Grype. Do it in CI, the automatic build-and-test step (post 52).
• ✅ Run as non-root. Remove Linux capabilities you do not need (a capability is one small special power of root). Use read-only file systems where you can.
• ✅ No secrets in images. Inject them at runtime.
• ✅ Pin versions of base images (use an exact version, not "latest"). Also sign images, for example with Sigstore/cosign, so you can check who made what you deploy.
• ✅ Set resource limits, so one container cannot take all the CPU or memory from the others (these are the bulkheads from post 42).