🐳 Containers & Virtualization Language

A virtual machine emulates an entire computer — including a guest operating system kernel — on top of a hypervisor, making each VM a fully isolated environment at the cost of significant memory and startup overhead. A container shares the host OS kernel and uses Linux namespaces and cgroups to isolate processes, making it far lighter — typically starting in milliseconds and consuming megabytes of overhead rather than gigabytes. The vocabulary distinction matters when discussing architectural trade-offs: containers offer density and speed; VMs offer stronger security isolation and full OS control.

A Dockerfile is a text file containing a sequence of instructions that Docker uses to build a container image. Key instruction vocabulary includes: FROM (base image), RUN (execute a command during build), COPY (add files from the build context), ADD (like COPY with additional URL and archive extraction support), CMD (default command at container start), ENTRYPOINT (executable that runs as PID 1), EXPOSE (documents the port the container listens on), and ENV (sets environment variables). Multi-stage builds use multiple FROM instructions to separate build-time and runtime environments, reducing final image size.

Container orchestration is the automated management of containerised workloads across a cluster of machines — handling scheduling, scaling, health checking, networking, and rolling updates. Kubernetes is the dominant orchestration platform and provides resource types including Pods, Deployments, Services, Ingresses, and ConfigMaps to declare the desired state of the system. Teams adopt Kubernetes when they need to manage multiple services at scale, require automated self-healing, or need fine-grained traffic and resource control across environments.

A container registry is a service that stores and distributes container images. Key vocabulary includes: image (an immutable snapshot of a containerised application), tag (a mutable pointer to a specific image version, e.g. latest or v1.2.3), digest (an immutable SHA256 hash identifying a specific image layer set), manifest (the metadata record describing an image's layers and platform), and multi-platform manifest (a single tag that resolves to different architecture-specific images). Public registries include Docker Hub and GitHub Container Registry; private registries include AWS ECR and Google Artifact Registry.

ENTRYPOINT defines the executable that will always run as the container's main process (PID 1) and is not overridden by arguments passed to docker run. CMD provides default arguments to the ENTRYPOINT or, if no ENTRYPOINT is set, the default command to run — and can be overridden at runtime. The common professional pattern is to set ENTRYPOINT to the application binary and CMD to default flags, allowing operators to override arguments without replacing the application itself.

Container networking controls how containers communicate with each other and the outside world. Docker networking vocabulary includes bridge (the default isolated virtual network for containers on a single host), host (the container shares the host network stack with no isolation), overlay (a virtual network spanning multiple hosts, used in Swarm and Kubernetes), and macvlan (assigns a MAC address to the container for direct network access). Port binding maps a host port to a container port using the syntax host_port:container_port, for example -p 8080:80.

Container security vocabulary includes: running as non-root (avoiding UID 0 inside the container to limit blast radius), dropping Linux capabilities (removing permissions like CAP_NET_ADMIN beyond what the process needs), read-only filesystem (mounting the root filesystem as immutable to prevent runtime writes), seccomp profiles (restricting the system calls the container is permitted to make), CVE (Common Vulnerabilities and Exposures — vulnerability identifiers used in image scan reports), and image scanning (static analysis of image layers for known vulnerabilities before deployment).

Docker Compose is a tool for defining and running multi-container applications using a YAML configuration file (compose.yaml or docker-compose.yml). Key vocabulary includes: service (a container definition with its image, ports, environment, and dependencies), depends_on (declares start-up order dependency between services), volumes (persistent or shared storage — named volumes vs. bind mounts), env_file (loading environment variables from a file rather than inline), and override files (docker-compose.override.yml for environment-specific configuration without modifying the base file).

Exit code 137 means the container was killed by signal 9 (SIGKILL), most commonly because it exceeded its memory limit and was terminated by the Linux OOM (Out of Memory) Killer. In Kubernetes, this appears as an OOMKilled status on the Pod. Engineers diagnose this by checking container resource limits and memory usage metrics, then either increasing the memory limit or optimising the application's memory footprint. The vocabulary "the container OOM-killed" or "we have an OOMKilled event" is standard in incident triage language.

CoderLingo's Containers and Virtualization Language section includes seven exercise sets: Dockerfile writing vocabulary, container registry language, VM vs. container comparison language, container networking vocabulary, container lifecycle language (including exit codes and restart policies), container security language, and Docker Compose vocabulary. Sets span Intermediate and Advanced levels, covering vocabulary for developers, DevOps engineers, and platform engineers working with container technology daily.