Containers & Docker Explained

What Is a Container?

A container is a lightweight, isolated environment that packages an application together with everything it needs to run: libraries, configuration files, and the runtime environment. The key insight is that a container shares the host operating system's kernel rather than running a full OS of its own. This makes containers dramatically smaller and faster than virtual machines.

The core problem containers solve is the classic "it works on my machine" problem. Before containers, an application that worked perfectly in a developer's local environment might fail in production because of subtle differences in library versions, OS configuration, or installed software. A container bundles the application and its exact dependencies together, so it runs identically regardless of where it's deployed — a developer's laptop, a test server, or a production cloud environment.

Containers are ephemeral by design. When a container stops, any data written inside it is lost unless explicitly saved to external storage. This makes containers ideal for stateless services — web servers, APIs, microservices — where each instance is identical and disposable. For stateful applications like databases, you mount external persistent storage volumes.

Containers vs Virtual Machines

Docker: Images, Containers, and the Dockerfile

Docker is the platform that standardised containers and made them accessible to developers. The Docker ecosystem has four key components you need to understand:

The typical Docker workflow is: write a Dockerfile → run docker build to create an image → push the image to a registry → on any server, pull the image and run docker run to start a container.

Container Registries

A container registry is a repository for storing and distributing Docker images. Understanding the major registries is important for cloud certification exams:

In a secure enterprise environment, image scanning is performed at the registry level — every pushed image is automatically scanned for known vulnerabilities in its layers before it can be deployed. AWS ECR, ACR, and Google Artifact Registry all provide built-in vulnerability scanning.

Container Orchestration and Kubernetes

Running a single container on a single server is straightforward with Docker. But real production applications might require dozens or hundreds of containers spread across multiple servers, with requirements for automatic scaling, load balancing, rolling updates, and self-healing when a container crashes. This is the problem container orchestration solves.

Kubernetes (abbreviated K8s — K, 8 letters, s) is the dominant container orchestration platform. Originally developed at Google and open-sourced in 2014, it is now maintained by the Cloud Native Computing Foundation (CNCF). Every major cloud provider offers a managed Kubernetes service: AWS EKS (Elastic Kubernetes Service), Azure AKS (Azure Kubernetes Service), and Google GKE (Google Kubernetes Engine).

Kubernetes key capabilities include automatic scaling (add more Pods when CPU usage spikes), self-healing (automatically restart failed containers or reschedule Pods from failed nodes), rolling updates (update containers to a new version with zero downtime by gradually replacing old Pods), and rollbacks (revert to the previous version if a deployment fails).

Container Security

Containers introduce specific security considerations that appear on Security+ and cloud security exams:

Image vulnerabilities — container images are built on top of base OS images (e.g. Ubuntu, Alpine Linux) that may contain known CVEs. Regularly scanning images and rebuilding them against updated base images is essential. Use minimal base images (Alpine Linux is ~5MB vs Ubuntu's ~70MB) to reduce the attack surface.

Container escape — a vulnerability that allows a process inside a container to break out of the container's namespace and access the host OS. This is the most serious container security risk. Running containers as non-root users and using read-only filesystems reduces this risk.

Secrets management — application secrets (database passwords, API keys) should never be baked into Docker images. Use environment variables, Kubernetes Secrets, or dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault) to inject secrets at runtime.

Namespace isolation — Linux namespaces are the underlying technology that isolates containers from each other and from the host. Containers share the kernel but have separate process, network, and filesystem namespaces. This isolation is weaker than VM isolation — a kernel vulnerability can potentially affect all containers on a host simultaneously.

Exam Scenarios

Container Volumes and Persistent Storage

Containers are ephemeral by design — when a container is destroyed and recreated from the same image, any data written inside the container is lost. For stateless applications (web servers, API services) this is fine. For stateful applications (databases, file stores) it is not — data must persist across container restarts and deployments.

Docker volumes are the recommended mechanism for persistent data in containers. A volume is a directory managed by Docker that exists outside the container's writable layer, persists when the container is removed, and can be shared between multiple containers. When you run a database container with a volume mounted at its data directory, the database files are stored in the volume — recreating the container leaves the data untouched in the volume.

Bind mounts mount a specific directory from the host machine into the container. Unlike volumes (which Docker manages), bind mounts expose a specific host path — including the risk that the container can modify host files. Bind mounts are commonly used in development environments to mount source code from the developer's machine into a container, enabling code changes to be reflected immediately without rebuilding the image.

In Kubernetes, PersistentVolumes (PV) and PersistentVolumeClaims (PVC) provide the abstraction layer between pods and storage. A PV represents actual storage (an AWS EBS volume, an NFS share, a GCP Persistent Disk). A PVC is a request by a pod for storage with specific size and access mode requirements. The Kubernetes scheduler matches PVCs to available PVs, abstracting storage provisioning from application deployment. This abstraction is important for portability — the same application manifest (YAML) works across cloud providers and on-premises environments without modification.

Container Networking

Container networking is how containers communicate with each other and with the outside world. Understanding the basic networking models is useful for both exam questions and real-world troubleshooting.

By default, Docker creates a bridge network — a private internal network on the host where containers can communicate with each other using their container names as hostnames. The Docker host's network is separate; containers reach the outside via NAT through the host's IP address. This is the default for most single-host deployments.

The host network mode removes network isolation between the container and the Docker host — the container shares the host's network namespace directly, using the host's IP address. This provides the best network performance but eliminates container network isolation. Use this only when performance is critical and the security implications are understood.

For multi-host container deployments (Kubernetes clusters), an overlay network is used. Overlay networks create a virtual network that spans multiple physical hosts, allowing containers on different physical machines to communicate as if they were on the same network. Kubernetes uses Container Network Interface (CNI) plugins (Flannel, Calico, Cilium) to implement overlay networking. Calico, for example, adds network policy capabilities — allowing administrators to define firewall rules that restrict which pods can communicate with each other, implementing microsegmentation within the cluster.

Microservices and Container Architecture

Understanding why containers matter requires understanding the architectural shift they enable. Traditional monolithic applications bundle all functionality into a single deployable unit — the entire application is deployed together and scaled as one piece. Microservices architecture decomposes an application into small, independently deployable services, each responsible for a specific function. An e-commerce platform might have separate microservices for the user authentication service, product catalog, shopping cart, payment processing, and notification service.

Containers are the natural fit for microservices because each service can be packaged in its own container image with exactly the dependencies it needs, deployed independently, and scaled based on its own demand — if payment processing is overwhelmed but the product catalog is fine, only the payment service containers need to be scaled up. This contrasts with monolithic deployment where scaling requires running the entire application stack.

For the exam, the key connection is that containers enable microservices, microservices are deployed on container orchestration platforms like Kubernetes, and this architecture creates specific security challenges — a larger attack surface (many services to secure), east-west traffic between services that must be controlled, and supply chain risk from third-party base images and dependencies.

Container Image Scanning and Supply Chain Security

Container images are built from base images pulled from registries, and those base images contain operating system packages, libraries, and runtimes that may have known vulnerabilities. Container image scanning is the practice of analyzing images for known CVEs (Common Vulnerabilities and Exposures) in the packages they contain — similar to vulnerability scanning for traditional systems, but applied at the image layer before containers are ever deployed.

Tools like Trivy, Anchore, Snyk, and cloud-native scanner integrations (AWS ECR scanning, Azure Defender for Container Registries) can scan images in CI/CD pipelines, blocking deployment if critical or high-severity vulnerabilities are found. This is the container equivalent of "shift left" security — catching vulnerabilities before they reach production.

Supply chain risk in containers is a significant concern. When you run FROM ubuntu:22.04 in a Dockerfile, you're trusting that the ubuntu image on Docker Hub hasn't been tampered with. Image signing (using Docker Content Trust or Sigstore/cosign) allows image publishers to cryptographically sign images, and container runtimes can be configured to only run signed images from trusted publishers. This prevents "typosquatting" attacks where malicious images are published under names similar to popular images (e.g., nginix instead of nginx).

Best practices for container image security include using minimal base images (Alpine Linux or distroless images reduce the attack surface dramatically), never running containers as root, pinning base image versions rather than using mutable tags like latest, and regularly rebuilding images to incorporate security patches from updated base images.

Docker Compose

Docker Compose is a tool for defining and running multi-container applications using a YAML configuration file (docker-compose.yml). Instead of starting individual containers with lengthy docker run commands and manually linking them, Compose lets you define the entire application stack — services, networks, volumes, environment variables, port mappings — in a single declarative file. A single docker-compose up command starts the entire stack.

For exam purposes, the distinction between Docker Compose and Kubernetes is important. Docker Compose is designed for single-host development environments — it manages containers on one machine and is great for local development and testing. Kubernetes is designed for multi-host production deployments — it manages containers across clusters of servers with health checking, auto-scaling, rolling updates, and self-healing. When exam scenarios mention production deployment at scale, the answer is Kubernetes (or a managed equivalent). When scenarios mention local development or simple multi-container applications, Docker Compose is appropriate.

Related Articles