BR-ANAC-DOV-MOD-1 key terms

The client-server runtime that builds and runs containers. A command-line client talks over a local socket or network to a long-running daemon that manages images, containers, networks, and volumes.

The background daemon process that does the real work: pulling images, creating containers, wiring networks, and mounting volumes. It listens on a Unix socket by default and exposes a REST API.

The user-facing command-line program that translates typed commands into REST calls to the daemon. It can target a remote daemon through environment variables or context settings rather than the local socket.

The Unix domain socket, usually /var/run/docker.sock, through which clients reach the daemon. Anyone who can read and write it effectively has root-equivalent control of the host.

A named bundle of connection settings (endpoint, TLS certificates, orchestrator choice) that tells the CLI which daemon to talk to. Switching contexts avoids retyping host flags for every command.

A plain-text recipe of instructions that the builder executes in order to produce an image. Each instruction adds a layer, so ordering instructions well improves caching and final image size.

The set of files sent to the builder when an image is built, usually the directory named on the command line. Large contexts slow builds, so ignore files exclude unneeded content.

A file listing paths that must be excluded from the build context. Excluding junk speeds transfers, keeps secrets out of the build, and prevents needless cache invalidation when unrelated files change.

An immutable filesystem diff produced by a build instruction or image pull. Layers are shared between images and cached, so identical lower layers are stored and transferred only once.

A Dockerfile technique using several FROM statements where earlier stages compile or prepare artifacts and a later stage copies only the results. This yields small final images without build tooling.

A read-only, layered template containing a filesystem plus metadata such as default command, ports, and environment. Containers are created from images and add a writable layer on top.

A running or stopped instance of an image, isolated by kernel namespaces and limited by cgroups. It has its own writable layer, process tree, network identity, and lifecycle.

A human-readable label such as 1.21 or latest attached to an image reference to distinguish versions. Tags are mutable pointers, so identical tags can refer to different content over time.

A content-addressed identifier, typically a SHA-256 hash, that uniquely and immutably names an image manifest. Pulling by digest guarantees exactly the same bytes regardless of tag movement.

A networked service that stores and distributes image repositories, supporting push and pull over HTTP APIs. Public and private registries differ mainly in authentication and access control.

A named collection of related images inside a registry, identified by a path like team/app. Each repository holds multiple tags and their underlying manifests.

A JSON document describing an image: its configuration and the list of layer digests that compose it. Multi-platform manifests point to per-architecture manifests so the right one is selected.

A Linux kernel feature that gives a process its own isolated view of a resource such as processes, mounts, network interfaces, hostnames, or user IDs. Containers are built from several namespaces.

A Linux kernel mechanism that groups processes and enforces limits on CPU, memory, block I/O, and process counts. It provides the resource constraints that keep one container from starving others.

A fine-grained Linux privilege unit, such as binding low ports or changing file ownership, that can be granted or dropped independently of full root. Dropping unneeded capabilities hardens containers.

Running the daemon and containers entirely as an unprivileged user, using user namespaces for isolation. It reduces the impact of a container escape but limits some networking and storage features.

Persistent storage managed by the container engine and stored outside the container filesystem, typically under a host directory. Volumes survive container removal and are the preferred way to keep data.

A mapping that exposes an existing host file or directory directly inside a container. It is simple and fast but ties the container to host paths and host permissions.

An in-memory filesystem mounted into a container that disappears when the container stops. It suits scratch data and secrets that should never be written to persistent disk.

The pluggable component that implements the layered, copy-on-write filesystem for images and container layers, for example overlay2. Choice affects performance, disk usage, and available features.

A strategy where containers share read-only image layers and copy a file into their writable layer only when it is modified. This makes container startup fast and saves disk space.

The default software network on a single host that connects containers through a virtual switch and provides outbound NAT. User-defined bridges also supply automatic DNS resolution between containers.

A network mode that removes network isolation so the container shares the host's interfaces and ports directly. It avoids NAT overhead but causes port conflicts and reduces isolation.

A multi-host virtual network that spans several engines or cluster nodes, encapsulating traffic so containers communicate as if on one subnet. It underpins swarm services and cross-node container links.

Mapping a host port to a container port so external clients can reach a service, written as host:container. It is required in bridge mode but unnecessary with host networking.

A resolver built into user-defined networks that maps container names and network aliases to current IP addresses. It lets containers find each other by name instead of hard-coded addresses.

The mechanism by which components locate each other's addresses at runtime rather than through static configuration. Container engines and orchestrators supply it via DNS, aliases, or service VIPs.

A declarative YAML document defining services, images, networks, and volumes for a multi-container application. One command then creates and starts the whole set with consistent configuration.

A definition of how to run one or more identical containers, including image, replicas, ports, and networks. In swarm mode the orchestrator schedules and reconciles the desired number of tasks.

The smallest scheduling unit in swarm mode: a single container plus the slot it fills in a service. If a task fails, the orchestrator creates a replacement to restore the desired state.

The engine's built-in clustering capability, where manager nodes accept service definitions and worker nodes run tasks. Managers use Raft consensus to keep cluster state consistent.

A swarm node that participates in the Raft consensus group, stores cluster state, and schedules services. Losing a majority of managers makes the cluster unable to accept changes.

A swarm node that only runs tasks assigned by managers and never takes part in consensus. Adding workers increases capacity without affecting the cluster's fault tolerance.

The majority of manager nodes that must agree for the cluster to make decisions. A cluster of three managers tolerates one failure; an even number adds no benefit and risks split votes.