Last Updated on February 17, 2024 by KnownSense
Docker is a platform designed to help developers build, share, and run container applications. But now we need to understand a bit of the Docker history because, it really helps us understand why things are the way they are now. This page explores how Docker was created and changed over time in detail.
The Early Days: Birth from dotCloud
Back in the early days, like when TVs were black and white, Docker came out of a company called dotCloud. Back then it was just a Python tool called dc, d for dot and c for cloud. DotCloud were pioneering the use of Linux containers as a safe and efficient way of delivering PaaS services to their customers. Dc was a Python wrapper around LXC and AUFS. AUFS is a union file system, and LXC is a bunch of tools for working with container primitives in the kernel. This was all Linux back then.
Evolution and Challenges
The relationship with LXC was a bit of a problem for Docker.One of the issues was just the sheer pace that things were developing at. Docker was evolving both as a technology and as an ecosystem. At the same time and not by coincidence, LXC started cranking up its own development. Changes within LXC often caused disruptions for Docker’s functionality, highlighting the need for a more controllable alternative, leading to the birth of libcontainer.
Libcontainers: Docker’s Turning Point
Libcontainers pretty much like replacement for LXC, something to interface with the kernel and build containers out of namespaces and C groups. Importantly, it’s under Docker’s control. So Docker swapped out LXC for libcontainer, and it was a key move. By this time, the dc tool had become Docker, and things were developing like crazy. But, Docker itself became a monolith.
Docker’s Monolithic Phase
As Docker continued to evolve, it gradually transformed into a monolithic structure, contrary to its original lightweight design. So, rather than being lightweight and fast, like it was supposed to be, it got bloated and slower. It was doing everything. It was implementing the HTTP server and the REST API, which is fair enough. But it was also doing images, it was doing builds, registry stuff, networking, storage, authentication. It was bloated, and it had lost its mojo.
It’s ironic because on the one hand, Docker is leading the microservices revolution. But on the other hand, Docker itself is a monolith. Like what? Well, look, nobody was happy. For the folks at Docker building and iterating on a monolith, that’s no fun. For the ecosystem though, well, they all wanted to work with Docker. Only really, they just wanted to work with the runtime bit. They didn’t want all of the other stuff. In fact, as a quick example. Kubernetes was out there at the time, positioning itself as a container orchestrator, and it was using Docker as its run time. But by pulling in Docker, it meant it was also getting all of this, including Docker own built‑in orchestrator. So, Kubernetes, as an orchestrator, was shipping with Docker, which had a competing orchestrator already built in. The ecosystem was not liking the bloat. It was killing usability and composability and simplicity and security.
But it’s all good, right? Everything’s fixable. So two things happen. Docker starts unpicking itself and refactoring stuff into separate independent tools.
Refactoring and Standards Development
To address above discussed issues, Docker initiated a process of breaking down its monolithic structure into smaller, specialized components.
Networking stuffs get ripped out and refactored into its own component called a lib network. Build stuff comes out and goes into build kit. The container runtime stuff, that gets ripped out and goes into two components actually, containerd and runc. Containerd is responsible for the more high‑level container lifecycle management; whereas runc does all of the work with the kernel bits. The monolith gets unpicked and refactored into small specialized components around the same time, the OCI, or the Open Container Initiative was entering the scene and creating standards. Specifically, it created an image spec and a container runtime spec.
Current State and Ongoing Developments
As a result of these transformations and the establishment of standards, Docker’s landscape has significantly changed, emphasizing modularity, compatibility, and adherence to industry specifications. For the latest insights into Docker’s current status and working, you can explore Internal Working Of Docker.
Conclusion
The Docker history showcases a journey from its dotCloud origins as “dc,” a Python tool, through challenges with LXC, leading to the pivotal development of libcontainer. Despite evolving into a monolith, Docker underwent a crucial refactoring phase, dividing into specialized components and aligning with industry standards. This transformation highlights Docker’s current emphasis on modularity and compatibility.