DevOps Tools Introduction #06: Container Basics

Container virtualization is one of the major technologies behind modern software architectures. While the concept of container virtualization is rather old, new tools extend the pure virtualization components with numerous features that facilitate the deployment of containerized software. Docker is the most prominent project in that field. Objective 702.1 of the DevOps Tools Engineer certification focuses entirely on Docker and Podman containers.

Docker and Podman both implement the Open Container Initiative (OCI) specifications, which define standardized image formats and runtime behavior. This compliance ensures portability: an image built in one compliant environment can run in another without modification. For DevOps professionals, this standardization is foundational because it decouples application packaging from runtime details.

An essential concept is that containers are ephemeral by design. Stateless workloads align naturally with container architecture, whereas stateful workloads that preserve their state across instances require deliberate storage strategies.

Docker follows a client–server model. The Docker CLI communicates with the Docker daemon (dockerd), which manages images, containers, networking, and storage. This centralized daemon simplifies orchestration and API-driven automation, making Docker particularly suited for integrated workflows and CI/CD pipelines.

Podman, in contrast, uses a daemonless architecture. Each container is launched as a direct child process of the invoking user, employing OCI runtimes such as runc or crun. This model reduces background privileged services and aligns closely with traditional Linux process management and systemd integration. The architectural distinction has implications for security, system resource management, and operational design.

Container images are distributed through OCI-compliant registries such as Docker Hub, GitHub Container Registry, and Quay. An image is composed of layered snapshots of a filesystem representing incremental changes. These layers enable efficient distribution, caching, and reuse across systems.

From a conceptual standpoint, image immutability is critical. Tags may change, but digests uniquely identify image content. In professional DevOps environments, referencing images by digest instead of mutable tags enhances reproducibility and supply-chain integrity.

Understanding authentication mechanisms, private registries, and image provenance is equally important. Secure image sourcing is a core component of container security.

A container is a runtime instance of an image. Conceptually, containers are isolated processes that share the host kernel while maintaining separation through Linux namespaces and control groups (cgroups). They are not virtual machines; they rely on the host’s kernel rather than a separate hypervisor to isolate and protect containers from different users.

Operating containers involves managing their lifecycle states (created, running, paused, stopped, removed), inspecting metadata, accessing logs, and interacting with running processes. Observability and proper lifecycle governance are fundamental in production environments.

Container networking abstracts Linux networking primitives into programmable virtual networks. By default, containers can be attached to isolated bridge networks, which provide internal communication and controlled exposure to external systems. Overlay networks extend this abstraction across multiple hosts. They create distributed virtual networks that allow containers running on different machines to communicate securely as if they were on the same logical network. Overlay networks are foundational for clustered environments and distributed application architectures.

Container storage is based on layered filesystems using copy-on-write semantics. Each image layer is read-only, and a thin writable layer is added when a container is created. Changes exist only in that writable layer and disappear when the container is removed.

Volumes provide storage independent of container lifecycle. They are managed by the container engine and decouple application data from ephemeral runtime instances.

A strong conceptual understanding of container architecture—covering runtime design, networking abstractions, DNS-based service discovery, layered storage, persistent volumes, and rootless execution—enables DevOps engineers to design secure, scalable, and production-ready container platforms aligned with modern cloud-native best practices and LPI DevOps Tools Engineer expectations.

To get started playing with Docker, visit the Play with Docker Classroom. Here you’ll find practical exercises that give you access to a remote Docker installation so you can start practicing right away. To access the interactive labs, you’ll need a Docker ID, which you can create for free at Docker Hub.

Once you get your Docker ID, you can choose to follow the operator’s or developer’s walk-through. Both tracks contain a lot of explanations and practical exercises. To ensure you capture all the knowledge in there, I recommend following both tutorial series. Furthermore, I highly recommend joining Jérôme Petazzoni and AJ Bowen in their comprehensive Introduction to Docker and Containers.

The vast majority of Docker commands can be executed in Podman simply by replacing the docker command with podman, as both tools intentionally maintain a high level of CLI compatibility. This design allows professionals to transition between environments with minimal friction while preserving operational workflows. However, there are architectural differences worth noting: Docker relies on a centralized daemon (dockerd), whereas Podman is daemonless; Podman was built with native rootless execution in mind; and Podman integrates more directly with systemd for service management. Additionally, Docker includes built-in support for Swarm orchestration, while Podman emphasizes compatibility with Kubernetes through pod concepts.

After completing the Play with Docker labs and reviewing the workshop materials, move on to the official Docker documentation to deepen your understanding of its architecture, networking model, storage drivers, and security mechanisms. The official documentation provides the authoritative reference needed to connect hands-on practice with internal design concepts.

In parallel, make sure to study the official LPI Learning Materials for DevOps Tools Engineer 2.0. The LPI content is structured specifically around the certification objectives and reinforces both conceptual understanding and operational competence, aligned with the exam expectations.

<< Read the previous part of this series