This is a creation in Article, where the information may have evolved or changed.
"The editor's words" Now, when it comes to "containers," almost all people first think of Docker. As the most mainstream container standard, Docker masks the brilliance of many predecessors and successors. In fact, Docker is neither the first container class product (OpenVZ, LXC, etc.), nor the last. Today we're going to talk about a new container that has a recent ignition standard: AppC.
APPC is a community project launched by CoreOS in December 2014 to design standards for a new cross-platform container in terms of image format, operating mode, and service discovery mechanisms.
Officially, the project was first born because the mainstream container tool Docker is becoming the self-contained ecosystem from a simple container tool. The central management of Docker (unified control by the docker-d background process on each host) is not friendly to SYSTEMD and third-party task orchestration tools (for specific reasons later on).
So CoreOS wants to design an application container that is centralized, more pure, and more focused on performance and security, handing out tasks such as log management, container scheduling, and cluster orchestration to external tools.
Docker is the initiator of DotCloud company, the company's original business is to do PaaS platform, which also determines the development of Docker is to become a "chatty" platform nature of the product. This approach is in itself in line with the majority of the market "public users" want "one-stop solution" appeal.
It can be said that the basic point of the two is not the same as the problem to be solved. Therefore, we hope that everyone holds an open and tolerant attitude to look at the comparison between Docker and AppC. Instead of embracing the goal of choosing "which is the best container standard", because the problem may be the same as "which programming language is the best language", it can only be given time to conclude.
Now the AppC standard container has several (all very small), it is impossible to compare each other. The following is a comparison of Docker with the CoreOS officially launched Rkt container. The following are the results of individual tests and do not represent the official views of either Docker or CoreOS.
From the very word. First, there are some differences that are most likely to be felt.
How to manipulate commands
As you can see, all of the Docker commands are included in the Docker command-line tool.
The image-related commands in Rkt are provided by the AppC Unified command-line tool Actool, and the operations of the container itself are provided by the individual containers, such as Rkt.
Docker containers will be stopped later by the background of the docker-d process record, but also can again restart, and Rkt in the container running the application is more like a common application, the end of the real end.
It can also be seen that RKT provides only a subset of the Docker, which provides a whole lot of support for logging, mirroring, and management.
Then, consider a very important difference between Docker and Rkt.
How container processes Run
Each container process of the Rkt is directly forked out by the Rkt command. The Docker process is a Docker command-line tool that is executed by the user to send messages to the background of the docker-d process, which is indirectly forked by the docker-d process. That doesn't make any difference, but Docker's approach poses some problems for third-party task-scheduling tools.
Some process management tools, such as SYSTEMD, control and track the lifecycle of a process through Cgroup, while SysV tracks the process life cycle through process numbers and inheritance relationships. For example, when a process needs to be ended, the process management tool will find all the child processes of the corresponding process to end together.
But this process of Docker runs the model, making it impossible to see whether the Docker command line that creates the container has any relation to the container itself, either through the process tree or the cgroup tree. As a result, many task management tools do not manage the process in a Docker-initiated container without special treatment of the Docker process.
Look at the structure of the mirror
The Docker exported image is a tar file with layered content.
After the decompression of each directory is actually a layer of mirroring.
The Rkt image is a gzip file that has no layering and is directly packaged with all the files in the container.
Personally feel that although the layering is a bit complicated, but can reuse space, in fact, is more useful.
Finally, consider the security and performance aspects of AppC's emphasis.
Security
Docker downloads an image, directly Docker pull, and the transfer process can be encrypted and unencrypted, and Docker will not ask you if you know the source of the image.
Rkt, by default, requires all transfers to be encrypted, and the user must first add a trust to the image source signature before the image is downloaded, unless the user explicitly specifies to cancel the authentication, or the mirror will refuse to run it even if it has downloaded Rkt.
Container performance
In terms of performance, you can explain from one side: what is required to build a minimal, operational image.
The following hello this file is a static compilation (no non-system library dependent) program, when run will print a "Hello World".
Put it in a blank Docker image.
Running the container will find that the Docker hint could not find Bash.
Put the same program in a blank AppC image.
Running the container will work correctly.
This shows that when Docker is running any program in the container, it will actually start a shell in the container and then the shell to execute the specified command. The Rkt is purely straightforward to run the specified program, in contrast to the performance and image content of "signal-to-noise ratio" slightly superior.
If you are interested in the APPC and RKT containers, you can refer to my article in Infoq: CoreOS those things Rkt container early adopters (UP)
Q&a
Q: Can I create a problem with mirroring based on a local source? I personally think that the local source is important for the enterprise.
A: The image creation method of APPC is not the same, it is not supported in the way of writing dockerfile, but the file is placed in the directory of the specified structure, and then directly packaged with the Actool tool to create.
Q: Can I support a different release version?
A: APPC is a cross-system, just a standard. Rkt can be used in any version of Linux hairstyles.
Q: What is the minimum image for Rkt?
A: The minimum image of Rkt can be small to only one executable program inside.
Q: The concept of "signal-to-noise ratio" is not very clear.
A: The content "signal to noise ratio" means the actual user to the ratio of files and other auxiliary files.
Q: Can rkt containers be multi-process?
A: As with Docker, the portal command can only be one, which allows multiple processes to run in the background.
Q: "But this process of Docker runs the model, making it impossible to see whether the Docker command line that creates the container has any relation to the container itself, either through the process tree or the cgroup tree." As a result, many task management tools do not manage the process in a Docker-initiated container without special treatment of the Docker process. "The task tools mentioned here are particularly specific to the Docker process and often need to be handled to make it easier for the user's task tool to manage the processes in the Docker boot container."
A: In the case of an end container process, it is not possible to trace the process within the container by starting the PID or cgroup of the container's command, but with the Docker background service process.
Q: What about the Rkt log network?
A: This rkt, let the user choose other tools themselves, such as kubernetes or mesos these frameworks can be used, APPC purpose is to focus purely on the container itself function (environmental isolation) container.
Q: What is the difference between a RKT running its own image and a docker image?
A: There are some differences in the image format, but in fact the two should be very easy to convert, the Docker container to the APPC container conversion tool has been, not reversed, it is estimated that Docker is now the mainstream, and do not intend to do this kind of thing.
Q: Does the Rkt provide restful APIs?
A: No, because implementing a RESTful API requires a process that is resident in the background, which violates the RKT as a purely container tool and minimizes the design intent of the system intrusion.
Q: Do you feel that both Rkt+coreos and Docker+machine/swarm/compose are doing a cluster thing?
Answer: Yes, there is a certain competitive relationship. But CoreOS that Docker is more complex, not in line with their application scenarios, a new set of, by the way, to improve some of the small problems of Docker. But CoreOS still continues to provide long-term support for Docker solutions.
Q: Can rkt use Docker's image?
A: Yes, Rkt supports direct download of Dockerhub or other Docker repo images, but is automatically converted to APPC format to be stored locally after download.
===========================
The above content is organized according to the May 19, 2015 Night Group sharing content.
Linfan, a member of the ThoughtWorks Chengdu Cloud&devops Group, currently focuses on the application of containerized and CoreOS system-related fields. Recent major articles include CSDN's "CoreOS Practice Guide" series, Infoq's "CoreOS" series, and the May 2015 issue of the programmer's Magazine "Linux containers: Docker vs Rkt". Dockone Weekly will organize a targeted technology sharing, welcome interested students plus me (LIYINGJIESX) participation.
