Moby is a software company that creates tools for managing and deploying software. Docker is one of their most popular products. Moby has developed a tool called Moby-Docker that helps you manage and deploy Docker containers.
Docker’s Moby Project disassembles the foundational components of Docker Engine into a modular toolkit that other container-based systems can reuse. Moby was spun out of the then-monolithic Docker codebase in 2017. It’s developed into a comprehensive library of container backend components which can be combined to create full container solutions like Docker itself.
As a Docker end user you don’t directly interact with the Moby project. It’s aimed at people building containerization platforms, not developers building and running container images. However you may come across Moby in Docker’s documentation or when filing bug reports and feature requests.
Docker Before Moby
Docker was originally developed in one codebase that held everything the project needed. This ranged from the container runtime and image builders right through to storage providers, network management, and the CLI.
As Docker adoption ballooned in the mid part of the last decade, this all-in-one approach was observed to be holding back the broader ecosystem. Complementary tools couldn’t build on specific pieces of Docker as nothing was componentized. External vendors had to bring in Docker’s entire sprawling platform.
Core functional units such as containerd were rapidly split out into standalone modules. The community could now create new container systems without reinventing the runtime that mediates with the kernel to start container instances. Other components like runc and HyperKit followed, being separated from the Docker project then pulled back into Docker Engine releases as modular dependencies.
Moby took this approach to the next level by spinning even more components out of Docker. The former docker/docker GitHub repository became moby/moby; it holds the open-source portions of Docker Engine’s code in a community-accessible location, independently of the closed-source Docker CE and EE product repositories.
The Assembly Pattern
With Moby anyone can mix and match parts of Docker’s technology without being forced to pull in the whole lot. It provides implementations of all the key subsystems which make up a containerization platform. You can put together your own version of Docker, then swap pieces out to use alternative projects in specific functional areas.
Moby’s approach is modeled on the automotive industry’s use of shared platforms. Marques build entire model families from a single chassis and engine range. Adding a new option to the line-up is achieved by taking the shared platform and tweaking it to suit the new vehicle’s design requirements. The platform won’t necessarily be used as-is: a model that will be offered as a performance choice might have engine options and chassis modifications that aren’t available on other models using the platform.
Moby offers something similar to container system developers. You can start with pre-built component assemblies that offer proven cross-compatibility. This is the basic shared automotive platform. As your system evolves, you replace individual modules with new implementations to create a more powerful tool. One example could be substituting the BuildKit image builder with a higher performance alternative. This is akin to the auto maker replacing its platform’s standard small engine with a higher capacity alternative.
The Moby developer experience is therefore one of assembly and extension. Each Moby-based project will consume a different set of parts to achieve a unique objective. Prior to Moby, developers had no accessible starting point when innovating in specific areas of the container ecosystem. Now developments can be more focused as Moby fills in the blanks.
What Does Moby Include?
Moby has three distinct functional offerings:
A library of backend components that implement common container features such as image building, storage management, and log collection. A framework with supporting tooling that helps you combine, build, and test assemblies of components within your own system. The toolchain produces executable artifacts for all modern architectures, operating systems, and cloud environments. Examples of the framework’s uses, including a reference assembly. This reference assembly is the open-source core which the Docker product is built on. You can use it to better understand how Moby components are pulled together into a cohesive system.
These pieces give system builders all the ingredients to create their own containerization platform. They facilitate innovation without coupling projects to Docker and its closed ecosystem. The model is described as “batteries included but swappable.”
Moby is fully open-source and community-led. Docker contributes its open-source components to the project and external parties can add pieces too. Docker’s also committed to continuing to use Moby as its upstream; this means changes made to Moby will show up when you install Docker.
Moby isn’t actually the end of the line in Docker’s dependency tree. Some components such as the Containerd runtime have been donated to the CNCF and are consequently maintained separately from Moby. Moby uses Containerd as its default container runtime but it’s included as an upstream dependency, not a member of the project.
From Moby to Docker
While Moby includes all the fundamentals of a container system, its focus on system developers means installing the reference assembly won’t give you the best experience. This is where downstream projects such as Docker add value. They build upon Moby to create a platform that functions in a way that’s useful to end users working with containers and images.
As an example, installing Docker and running docker pull ubuntu:latest is possible without any manual configuration. This is because Docker’s preconfigured to pull unqualified image references from Docker Hub. This wouldn’t work with the Moby reference assembly; although it’s capable of pulling images, it has no default registry so it wouldn’t be able to resolve the tag.
Downstream platforms add opinions to the objective set of features offered by Moby. While container system developers won’t want a preconfigured registry URL, it’s a useful nice-to-have for image builders. Before Moby’s introduction, platform developers had no way of filtering out Docker’s product-based decisions.
Summary
Moby is a modular toolkit of backend container components. It sits upstream of platforms targeted at end users who build and run container images. Moby is for people who create systems like Docker but don’t want to inherit its defaults, opinions, and ties to Docker Inc.
Moby facilitates a more productive container ecosystem that’s no longer dominated by the Docker monolith. Most Docker users won’t have noticed the change as Moby’s introduction has primarily streamlined the development of tools such as Kubernetes, Podman, and other container environments. Those projects benefit from sharing key components that have been distilled down to their bare functional elements.
