Last Updated on March 3, 2024 by KnownSense
In the ever-evolving landscape of software development, Docker has emerged as a game-changer, revolutionizing the way applications are built, shipped, and deployed. Offering a lightweight and portable solution, Docker containers encapsulate an application and its dependencies, ensuring consistency across various environments. This article delves into the Internal working of Docker, exploring its core concepts, functionalities, and the unparalleled efficiency it brings to modern development practices. Join us on a journey through the intricacies of Docker and unlock the power to streamline your development workflow.
Docker hides all the hard kernel stuff, and gives us a powerful CLI and API that make containers easy. For Docker, I think it’s good to think of it as two pieces for now, the client and the engine. Sometimes we call the engine the daemon or just Docker.
Understanding the Docker Engine Components
Docker CLI and Its Commands
The core of Docker’s functionality resides in the Docker client, where commands like docker run and docker pull initiate container operations. However, the real magic happens within a sophisticated system comprising multiple components.
Daemon: The REST API Implementation
At the heart of Docker lies the daemon, which implements the REST API. Contrary to popular belief, the daemon doesn’t directly handle container creation but orchestrates the process through other specialized components.
ContainerD: Managing Container Lifecycle
Responsible for managing container lifecycle tasks such as starting, stopping, pausing, and unpausing, ContainerD acts as a crucial intermediary between the daemon and the OCI layer.
RunC: OCI Runtime Spec Implementation
At the lowest level, RunC operates within the OCI layer, executing the essential tasks with the kernel. As the reference implementation of the OCI runtime spec, Runc essentially builds and manages containers.
Workflow Insights: Creating a Container
The process of creating a container begins with the Docker CLI, leveraging commands like docker run with various parameters. However, the daemon, despite its name, doesn’t create containers; instead, it delegates this task to ContainerD. Surprisingly, even ContainerD doesn’t directly build containers; the actual creation happens within RunC at the OCI layer.
ContainerD serves as a bridge between the daemon and Runc, orchestrating the creation process by initiating a shim process for each container and calling upon Runc for execution. Once created, Runc exits, leaving behind the long-running shim process.
Modularity and Reusability
Architecturally, Docker’s components – Containerd and Runc – exemplify modularity and reusability. Containerd, a CNCF project, and Runc, an OCI project, are not exclusively owned by Docker. This modularity allows for interchangeability, common in Kubernetes setups, where alternatives can replace these components.
Benefits of Decoupling
The separation of containers from the daemon and even Containerd allows for independent updates without affecting running containers. This decoupling enhances flexibility and minimizes disruptions during updates or restarts.
Docker’s Component Evolution
Previously, Docker relied on external tools like LXC and later developed libcontainer. However, the shift to smaller, independent components owned by external projects like CNCF and OCI reflects a more stable and collaborative approach.
Conclusion
In this article we read in detail about the Internal working of Docker. The intricate orchestration of Docker’s components, from the daemon to Containerd and Runc, showcases a modular, stable, and interconnected system, enabling efficient container management. This structure, though complex, emphasizes the evolution and collaborative nature of modern container technologies.