Docker Glossary

A comprehensive list of terms used in the Docker course.

A

Alpine Linux
A security-oriented, lightweight Linux distribution based on musl libc and busybox. Often used as a base image for containers due to its small size (5MB).

B

Base Image
An image that has no parent image. Usually an OS image like ubuntu, alpine, or debian. Defined by FROM scratch in a Dockerfile.
Build Context
The set of files located in the specified PATH or URL. The docker build process can access any file in this context.

C

Cgroup (Control Group)
A Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network) of a collection of processes.
Container
A runnable instance of an image. It is an isolated process that shares the host’s kernel but has its own namespace (PID, NET, MNT).
Containerd
An industry-standard container runtime with an emphasis on simplicity, robustness, and portability. It manages the complete container lifecycle of its host system.
Copy-on-Write (CoW)
A resource management technique used by Docker storage drivers. If a container needs to modify a file that exists in a lower read-only layer, Docker first copies the file up to the container’s read-write layer. The modification is then made to this copy, leaving the original file in the lower layer unchanged.

D

Daemon
A background process that manages Docker objects such as images, containers, networks, and volumes. The Docker daemon (dockerd) listens for Docker API requests.
Digest
An immutable identifier for a Docker image, generated using a SHA256 hash of the image’s content. Unlike tags, digests guarantee that the image content has not changed.
Distroless
A type of Docker base image that contains only the application and its runtime dependencies. They do not contain package managers, shells, or any other programs you would expect to find in a standard Linux distribution.
Docker Hub
A cloud-based registry service for building and shipping application or service containers. It provides a centralized resource for container image discovery, distribution, change management, user and team collaboration, and workflow automation.
Dockerfile
A text document that contains all the commands a user could call on the command line to assemble an image.

E

Entrypoint
An instruction in a Dockerfile that sets the command and parameters that will be executed first when a container is run.
Exit Code
A numeric value returned by a process to its parent when it terminates. Code 0 typically indicates success, while non-zero values (e.g., 1, 137) indicate errors.

G

Graceful Shutdown
The process of allowing a container application to clean up resources (close DB connections, save state) before terminating. Triggered by SIGTERM.

H

Hypervisor
Software that creates and runs virtual machines (VMs). It sits between the hardware and the virtual machine and manages the execution of the guest operating systems.

I

Image
A read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization.

L

Layer
An image consists of multiple layers. Each instruction in a Dockerfile creates a new layer. Layers are stacked on top of each other.

M

Manifest
A JSON file that describes the layers of an image and the architecture it supports.
Multi-stage Build
A method of organizing a Dockerfile into multiple stages, where each stage begins with a FROM instruction. This allows you to copy artifacts from one stage to another, enabling you to use a heavy image for building (e.g., with compilers) and a lightweight image for running the application.

N

Namespace
A Linux kernel feature that wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Examples: PID, NET, MNT, UTS, IPC, USER.

O

OCI (Open Container Initiative)
An open governance structure for the express purpose of creating open industry standards around container formats and runtimes.
OOM Killed
“Out Of Memory Killed”. Occurs when a container exceeds its memory limit (or host memory), causing the kernel to kill the process (Exit Code 137).
OverlayFS
A union mount filesystem implementation for Linux. It combines multiple different underlying mount points into one, resulting in a single directory structure that contains underlying files and sub-directories from all sources.

R

Registry
A stateless, highly scalable server side application that stores and lets you distribute Docker images.
Repository
A collection of images with the same name but different tags (e.g., ubuntu:18.04, ubuntu:20.04).
Restart Policy
A rule that tells Docker how to handle a container when it exits. Options include no, on-failure, always, and unless-stopped.
Runc
A CLI tool for spawning and running containers according to the OCI specification.

S

Scratch
An explicitly empty Docker image, used for building super-minimal images (often for static binaries like Go or Rust applications).
Shim
A process that sits between containerd and the container process (runc). It allows the daemon to restart without killing running containers.
SIGKILL
Signal 9. A termination signal that cannot be caught or ignored. It abruptly kills the process. Docker sends this if a container doesn’t stop within the timeout after SIGTERM.
SIGTERM
Signal 15. The default signal sent by docker stop. It requests the process to terminate gracefully.

T

Tag
A label applied to a Docker image in a repository. Tags are mutually exclusive per image. latest is the default tag.

U

Union File System
A file system service for Linux that allows files and directories of separate file systems, known as branches, to be transparently overlaid, forming a single coherent file system.

V

Volume
A persistent data storage mechanism for Docker containers. Volumes are stored in a part of the host filesystem which is managed by Docker (/var/lib/docker/volumes/).

Z

Zombie Process
A process that has completed execution (via exit) but still has an entry in the process table. This occurs if the parent process (PID 1) fails to read the child’s exit status.