Moby will convert Docker from a monolithic engine into a toolkit of reusable components Credit: Docker Being an Austinite, I enjoyed having DockerCon local, and I co-authored a guide to visiting Austin in the hopes that attendees would enjoy having DockerCon in Austin as well. During DockerCon 2017, a few major announcements were made, including the Moby Project. What is the Moby Project? It’s a framework to assemble specialized container systems without reinventing the wheel. The Moby Project is to Docker what Fedora is to Red Hat Enterprise Linux. – Solomon Hykes, Docker CTO/Founder In becoming the container project equivalent to the Fedora project, how Docker is built is changing. Red Hat did a good job in the early days of the RHEL confusion in that they delineated the project from product; they split Fedora from RHEL. Docker sees this approach as a way to better engage community. The boundaries between community and products were fuzzy before. People couldn’t necessarily tell when they are contributing to the project vs the product. This separation of code between the moby/moby repository and the docker/docker repository clarifies this distinction. Moby will convert Docker from a monolithic engine into a toolkit to assemble its components into different configurations. The Moby Project should encourage reuse of each of the components. Docker has a history of success in this regard and can be measured in their reuse beyond their creator: They spun out OCI/runc, and it is now the established standard for container runtime and image formats. They spun out containerd, and it is now the de facto industry standard for container runtimes with contributions from all major cloud vendors and 99 percent of the install base (millions of nodes worldwide). Notary has become the industry’s most mature implementation of TUF and a hub of collaboration for the security community. Docker distribution is the open-source foundation for a dozen commercial products. The Docker team is hopeful that as the Docker monolith is broken into smaller pieces, that these individual components may become building blocks for custom solutions. Previously residing in docker/docker, the monolithic project has been relocated to moby/moby. Some confusion arose about the project. The Docker team communicated the project well to contributors at the conference and to most of the maintainers. However, people more casually interfacing in the community were surprised and unclear about its purpose and impact, expressing frustration in not understanding how the various pieces fit together or what the new features (e.g., LinuxKit) do. The @moby Project in a nutshell: inside and outside. pic.twitter.com/K8Rn9YYtVs — Solomon Hykes (@solomonstre) April 22, 2017 The Moby Project enables system builders to create other projects on top of the same tooling. A system builder may want to run these assemblies differently, depending on whether they run on a small IoT device or if they run on a large system with GPUs. There’s still much work to break out components; however, the goal is to create one large upstream for Docker—that being Moby. Docker Inc. wants the tooling to be more open than Docker. Product design decisions are sometimes at odds with a consensus-driven open-source project. Having separation of concerns allows Docker Inc. to compile opinions on user experience into their community and enterprise Docker offerings. Moby is the project. Docker is the product. The Moby Project can be described in four layers: All the way upstream components Moby Docker CE Docker EE The organization of the project into layers should assuage natural content that arises when decisions need to be made between what works for the project vs. product. Docker as a product will add opinions informed by their users (to be easier for their users). For example, containerd doesn’t have a default registry, while Docker will have Docker hub as the default or the Docker CLI, providing a easy lookup for open issues you have for your project in the Docker support forum/system. Users unaffected. Users will still interact with Docker in the same way. Application developers looking for an easy way to run their applications in containers may look to Docker CE. Enterprise IT looking for a ready-to-use, commercially supported container platform may look to Docker EE. Nothing changes for these users. The command line remains the same. Docker can now leverage the ecosystem to innovate faster for them. System builders looking to leverage components of the Moby Project may innovate without being tied to Docker. Project Governance The Moby Project is open and will be a community-run project. Docker Inc. has a general inclination to donate individual components in this project to other governing bodies where appropriate. Containerd has to stand alone from the Moby org because it was donated to CNCF. Long-term individual projects should eventually move out and go into other repositories. Moby Project FAQ Now that Moby is breaking up the monotlith, will languages other than Go be incorporated? For LinuxKit—There’s a commitment to Ocaml and Rust. There’s no master plan to change languages. Will REST be replaced with gRPC? Docker Inc generally desires to leave REST API as constant façade, while moving internal communications between Moby projects to gRPC. A component can change languages and not have it affect other components (just like microservices provide choice). Engine has an HTTP REST API, and all of the lower-level components have adopted gRPC. Solomon proposes adopting gRPC as the standard interface. Benefits include more automated tooling. Where will you find Docker CE (the open source project)? TBD—Docker/CLI will have the client libraries and SDKs for now. Packaging and building is edition-specific, given that there are many Docker for XXX. Software DevelopmentOpen Source