What is the essence of the Moby project and why did moby / moby suddenly become the main Docker repository?
A month ago, Docker at the DockerCon 2017 conference officially introduced its new Open Source project - Moby . If this is just another additional project needed by someone who works with Docker ... then why, as attentive users have noticed, the main repository of the company in GitHub - docker / docker - began to forward to moby / moby ?
Looking ahead and answering questions from developers using Docker as an easy way to launch applications in containers: Moby - the project is notfor you. Despite its appearance and the changes taking place inside, nothing will change “outwardly” (for users of Docker as a finished product). And for those who are more inclined to understand these permutations (very significant!) And, perhaps, even use them to solve their problems ... I will start with a brief digression into the latest history of Docker development.
Docker as a platform for launching containers uses many auxiliary components, which the development company calls “ connecting ” ( plumbing , which literally translates from English as “plumbing, plumbing”) . For several years now, Docker engineers have been trying to make their platform more modular by separating its individual parts into independent Open Source projects.
When in 2015 it was announced the first such large-scale "separation" - the utility to run runC containers - the company published its " Manifesto infrastructure connections » (Infrastructure Plumbing Manifesto), which documented the main principles:
The runC utility, then separate, performed one function of the Docker platform - launching containers. She required a root file system and configuration for this, providing a solution to all related tasks (obtaining an image, unpacking it ...) to other tools.
In the spring of this year, containerd , a component isolated from Docker and implementing the container runtime, suffered a similar fate . We talked about it in detail in this article . Both of these projects (runC and containerd) not only received their separate Git repositories, but also an independent “home” in the form of CNCF (Cloud Native Computing Foundation).
And with the recent announcement of Moby, the company went even further by generalizing and systematizing its approach to the modular architecture of Docker.
Moby ’s initial announcement compared it to a set of lego designers from dozens of components and a framework for assembling them into assemblies . Explaining their intentions, the authors talked about the desire to "develop the software containerization movement and encourage the ecosystem to accept containers as mainstream."
In a more pragmatic sense, Moby turned out to be a framework that provides:
As with Docker itself, the Moby project aims to provide a flexible solution that follows strict guidelines when developing. They are as follows:
With the advent of Moby, the Docker platform finally ceases to be a “monolith”, turning into a component assembly product from Moby :
This also explains the reason for the disappearance of the docker / docker Git repository as such (and its transfer to moby / moby ): developers are now offered not a single product (an already built system), but a framework for assembling such a product in accordance with their needs (i.e. that same constructor). One of these products will be Docker CE (and Docker EE), and the other may be your development.
Moby is building the Docker platform ... and your container system
Since Moby (and moving the main repository) provoked clear questions from a large number of Docker end users, Solomon Hykes, the company's founder, was forced to publicly explain that “users [Moby appearance] will not affect; binary files will remain the same. "
The Moby website offers the following list of potential users of the project:
A separate list contains a list that Moby does not need : application developers (individuals and companies) who are looking for an easy way to launch applications in containers (they are advised by Docker CE and Docker EE, respectively), as well as those curious to learn about containers and find an easy way to master them (for this, according to the authors, docker.com is enough , which is hard to argue with).
At Docker itself, they use Moby “as a research laboratory for experimenting, developing new components and working together on an ecosystem for the future of container technology.”
In the near future thanks to Moby, we can expect the appearance of additional components separated from Docker, as happened with runC and containerd, as well as auxiliary tools, alternative implementations of certain functions from enthusiasts and companies, new Docker-like platforms oriented to special cases of containers .
The first project, conditionally associated with Moby, was LinuxKit , which was simultaneously announced as a set of utilities for building its compact, secure, portable Linux distributions for containers. It uses Moby to build distribution images. A simple practical demonstration of how Moby and LinuxKit work in conjunction can be found in this article .
Only a month has passed since the announcement of Moby, and a month later (June 19, 2017), the first event dedicated to it and focused on “advanced container users” - Moby Summit - will be held annually.
PS See also “ Why do we need containerd and why was it separated from Docker? »And subscribe to our hub for updates!
Looking ahead and answering questions from developers using Docker as an easy way to launch applications in containers: Moby - the project is notfor you. Despite its appearance and the changes taking place inside, nothing will change “outwardly” (for users of Docker as a finished product). And for those who are more inclined to understand these permutations (very significant!) And, perhaps, even use them to solve their problems ... I will start with a brief digression into the latest history of Docker development.
Docker and “connecting” software: runC, containerd
Docker as a platform for launching containers uses many auxiliary components, which the development company calls “ connecting ” ( plumbing , which literally translates from English as “plumbing, plumbing”) . For several years now, Docker engineers have been trying to make their platform more modular by separating its individual parts into independent Open Source projects.
When in 2015 it was announced the first such large-scale "separation" - the utility to run runC containers - the company published its " Manifesto infrastructure connections » (Infrastructure Plumbing Manifesto), which documented the main principles:
- Whenever possible, reuse existing connectivity solutions and return your improvements to their codebase.
- When you need to create a new connecting tool, make it easy to reuse and make improvements. This will increase the number of publicly available components that everyone benefits from.
- Follow the UNIX principle: several separate components are better than one, but complex.
- Define standard interfaces that can be used to assemble many simple components into a more complex system. (An analogy to building multiple console utilities through pipelines in Bash in a single command chain.)
The runC utility, then separate, performed one function of the Docker platform - launching containers. She required a root file system and configuration for this, providing a solution to all related tasks (obtaining an image, unpacking it ...) to other tools.
In the spring of this year, containerd , a component isolated from Docker and implementing the container runtime, suffered a similar fate . We talked about it in detail in this article . Both of these projects (runC and containerd) not only received their separate Git repositories, but also an independent “home” in the form of CNCF (Cloud Native Computing Foundation).
And with the recent announcement of Moby, the company went even further by generalizing and systematizing its approach to the modular architecture of Docker.
What is Moby?
Moby ’s initial announcement compared it to a set of lego designers from dozens of components and a framework for assembling them into assemblies . Explaining their intentions, the authors talked about the desire to "develop the software containerization movement and encourage the ecosystem to accept containers as mainstream."
In a more pragmatic sense, Moby turned out to be a framework that provides:
- a library of containerized components for all vital aspects of the container system: the operating system, the container runtime (the containerd is already mentioned by default), orchestration, infrastructure management, network support, data storage, security, assembly, distribution of images, etc .;
- tools for assembling components into triggered artifacts for the entire supported set of platforms and architectures, i.e. bare metal for x86 and ARM, executable files for Linux, Mac OS and Windows, virtual machine images for popular cloud services and virtualization tools;
- a set of reference kits (assemblies) called Moby Origin, which can be used either as is, or modifying, or as an example to create your own versions.
As with Docker itself, the Moby project aims to provide a flexible solution that follows strict guidelines when developing. They are as follows:
- All components necessary to create a complete container system are available, but are interchangeable (by other implementations) due to the modular architecture. By the way, here is an example replacement for the mentioned containerd can be the rkt project from the authors of CoreOS.
- Security is provided by default without compromising usability.
- Orientation to containers: "Moby is created with containers and for launching containers."
How Moby relates to Docker
With the advent of Moby, the Docker platform finally ceases to be a “monolith”, turning into a component assembly product from Moby :
The Moby project provides a console utility mobythat builds components. At the moment, it collects downloadable images of the operating system, but will soon be used in Docker to build it from components, many of which will become independent projects.This also explains the reason for the disappearance of the docker / docker Git repository as such (and its transfer to moby / moby ): developers are now offered not a single product (an already built system), but a framework for assembling such a product in accordance with their needs (i.e. that same constructor). One of these products will be Docker CE (and Docker EE), and the other may be your development.
Moby is building the Docker platform ... and your container system
Since Moby (and moving the main repository) provoked clear questions from a large number of Docker end users, Solomon Hykes, the company's founder, was forced to publicly explain that “users [Moby appearance] will not affect; binary files will remain the same. "
For whom then is it?
The Moby website offers the following list of potential users of the project:
- hackers who want to prepare or patch their Docker build;
- system engineers or integrators creating a container system;
- infrastructure solution providers intending to adapt existing container systems to their environment;
- enthusiasts from the world of containers who want to experiment with the latest technologies;
- Open source developers about to test their projects on multiple systems;
- all curious about how Docker is built inside and going.
A separate list contains a list that Moby does not need : application developers (individuals and companies) who are looking for an easy way to launch applications in containers (they are advised by Docker CE and Docker EE, respectively), as well as those curious to learn about containers and find an easy way to master them (for this, according to the authors, docker.com is enough , which is hard to argue with).
At Docker itself, they use Moby “as a research laboratory for experimenting, developing new components and working together on an ecosystem for the future of container technology.”
Prospects
In the near future thanks to Moby, we can expect the appearance of additional components separated from Docker, as happened with runC and containerd, as well as auxiliary tools, alternative implementations of certain functions from enthusiasts and companies, new Docker-like platforms oriented to special cases of containers .
The first project, conditionally associated with Moby, was LinuxKit , which was simultaneously announced as a set of utilities for building its compact, secure, portable Linux distributions for containers. It uses Moby to build distribution images. A simple practical demonstration of how Moby and LinuxKit work in conjunction can be found in this article .
Only a month has passed since the announcement of Moby, and a month later (June 19, 2017), the first event dedicated to it and focused on “advanced container users” - Moby Summit - will be held annually.
PS See also “ Why do we need containerd and why was it separated from Docker? »And subscribe to our hub for updates!