What is the essence of the Moby project and why the main Docker repository suddenly became moby / moby?
A month ago, at the DockerCon 2017 conference, Docker officially unveiled 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 noticed, the main repository of the company in GitHub - docker / docker - began to be sent to moby / moby ?
Looking ahead and answering in advance the questions of developers using Docker as an easy way to launch applications in containers: Moby is not a project for you. Despite its appearance and rearrangements taking place inside, “externally” (for Docker users as a finished product) nothing will change. And for those who are determined to more deeply understand these permutations (very significant!) And, perhaps, even use them to solve their problems ... I will begin with a brief excursion into the recent history of the development of Docker.
')
Docker as a platform for launching containers uses a variety of auxiliary components, which the development company calls “ connecting ” ( plumbing , which literally translates from English as “plumbing, plumbing”) . Not for the first year, Docker engineers have been trying to make their platform more modular, highlighting its individual parts into independent Open Source projects.
When in 2015 the first such large “branch” was announced - runC utilities for container launching, the company published its Infrastructure Plumbing Manifesto ( Manifesto of Infrastructure Connection ), which fixed the main principles:
The then-separate runC utility performed one function of the Docker platform — launching containers. It required the 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, a similar fate befell containerd , a component isolated from Docker and implementing the executable environment for containers. We talked about it in detail in this article . Both of these projects (runC and containerd) not only got their own separate Git repositories, but also an independent “home” in the form of CNCF (Cloud Native Computing Foundation).
And with the recent Moby announcement, the company went even further, summarizing and systematizing its approach to the Docker modular architecture.
Moby ’s original announcement compared it with a Lego set of dozens of components and a framework for assembling them into sets. Explaining their intentions, the authors spoke about the desire to "develop the movement of containerization of software and encourage the ecosystem to accept containers as mainstream."
In a more pragmatic sense, Moby turned out to be a framework that provides:
As is the case with Docker itself, the Moby project is designed to provide a flexible solution, the design of which follows strict guidelines. They consist in the following:
With the advent of Moby, the Docker platform finally ceases to be a "monolith", becoming a product of assembling components from Moby :
This explains the reason for the disappearance of the docker / docker Git repository itself (and its forwarding to moby / moby ): developers are now offered not a single product (an already assembled system), but a framework for building such a product according to their needs (i.e. . That same constructor). One such product would be Docker CE (and Docker EE), and the other would be your development.
With Moby, the Docker platform is built ... and your container system
Since the advent of Moby (and the transfer of the main repository) provoked clear questions from a large number of Docker end-users, the founder of the company Solomon Hykes was forced to publicly clarify that “users [the appearance of Moby] will not be affected; Binary files will remain the same. "
The Moby website offers the following list of potential users of the project:
A separate list lists who Moby doesn't need : application developers (individual 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 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).
The Docker company itself uses Moby "as a research and development 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 additional components separated from Docker, as it happened with runC and containerd, as well as supporting tools, alternative implementations of various functions from enthusiasts and companies, new Docker-like platforms focused on special cases of container usage. .
The first project, conditionally connected with Moby, was LinuxKit , announced simultaneously with it, a set of utilities for building its compact, secure, portable Linux distributions for containers. He uses Moby to build distribution images. A simple practical demonstration of how Moby and LinuxKit work in tandem can be found in this article .
From the moment of Moby’s announcement, only a month passed, and a month later (June 19, 2017) the first dedicated and “advanced container users” event, the Moby Summit , would be held annually.
PS Read also “ Why is containerd needed and why was it separated from Docker? »And subscribe to our hub for updates!
Looking ahead and answering in advance the questions of developers using Docker as an easy way to launch applications in containers: Moby is not a project for you. Despite its appearance and rearrangements taking place inside, “externally” (for Docker users as a finished product) nothing will change. And for those who are determined to more deeply understand these permutations (very significant!) And, perhaps, even use them to solve their problems ... I will begin with a brief excursion into the recent history of the development of Docker.
')
Docker and "connecting" software: runC, containerd
Docker as a platform for launching containers uses a variety of auxiliary components, which the development company calls “ connecting ” ( plumbing , which literally translates from English as “plumbing, plumbing”) . Not for the first year, Docker engineers have been trying to make their platform more modular, highlighting its individual parts into independent Open Source projects.
When in 2015 the first such large “branch” was announced - runC utilities for container launching, the company published its Infrastructure Plumbing Manifesto ( Manifesto of Infrastructure Connection ), which fixed the main principles:
- Whenever possible, reuse existing interconnect solutions and return your improvements to their code base.
- When you want 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 multiple simple components into a more complex system. (Analogy with building in a single chain-command multiple console utilities through pipelines in Bash.)
The then-separate runC utility performed one function of the Docker platform — launching containers. It required the 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, a similar fate befell containerd , a component isolated from Docker and implementing the executable environment for containers. We talked about it in detail in this article . Both of these projects (runC and containerd) not only got their own separate Git repositories, but also an independent “home” in the form of CNCF (Cloud Native Computing Foundation).
And with the recent Moby announcement, the company went even further, summarizing and systematizing its approach to the Docker modular architecture.
What is Moby?
Moby ’s original announcement compared it with a Lego set of dozens of components and a framework for assembling them into sets. Explaining their intentions, the authors spoke about the desire to "develop the movement of containerization of software 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's executable environment (by default, the containerd already mentioned), orchestration, infrastructure management, network support, data storage, security, assembly, distribution of images, etc .;
- tools for assembling components into running 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 by modifying, or as an example to create your own versions.
As is the case with Docker itself, the Moby project is designed to provide a flexible solution, the design of which follows strict guidelines. They consist in the following:
- All components needed to create a complete container system are available, but are replaceable (other implementations) due to the modular architecture. By the way, this example of a replacement for the mentioned containerd could be the rkt project from the authors of CoreOS.
- Security is provided by default without compromising usability.
- Container Orientation: "Moby is created with containers and for launching containers."
How does Moby relate to Docker
With the advent of Moby, the Docker platform finally ceases to be a "monolith", becoming a product of assembling components from Moby :
The Moby project provides a moby console utility that assembles components. At the moment, it collects downloadable images of the operating system, but it will soon be used in Docker to build it from components, many of which will become independent projects.This explains the reason for the disappearance of the docker / docker Git repository itself (and its forwarding to moby / moby ): developers are now offered not a single product (an already assembled system), but a framework for building such a product according to their needs (i.e. . That same constructor). One such product would be Docker CE (and Docker EE), and the other would be your development.
With Moby, the Docker platform is built ... and your container system
Since the advent of Moby (and the transfer of the main repository) provoked clear questions from a large number of Docker end-users, the founder of the company Solomon Hykes was forced to publicly clarify that “users [the appearance of Moby] will not be affected; 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 technology;
- Open source developers who are going to test their projects on a variety of systems;
- all curious about how the docker is built inside and going.
A separate list lists who Moby doesn't need : application developers (individual 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 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).
The Docker company itself uses Moby "as a research and development laboratory for experimenting, developing new components, and working together on an ecosystem for the future of container technology."
Perspectives
In the near future, thanks to Moby, we can expect additional components separated from Docker, as it happened with runC and containerd, as well as supporting tools, alternative implementations of various functions from enthusiasts and companies, new Docker-like platforms focused on special cases of container usage. .
The first project, conditionally connected with Moby, was LinuxKit , announced simultaneously with it, a set of utilities for building its compact, secure, portable Linux distributions for containers. He uses Moby to build distribution images. A simple practical demonstration of how Moby and LinuxKit work in tandem can be found in this article .
From the moment of Moby’s announcement, only a month passed, and a month later (June 19, 2017) the first dedicated and “advanced container users” event, the Moby Summit , would be held annually.
PS Read also “ Why is containerd needed and why was it separated from Docker? »And subscribe to our hub for updates!
Source: https://habr.com/ru/post/329136/
All Articles