Viewing Docker and rocket from container specifications

"Editor's note" in "Choose Docker or Rocket do container?" Why not choose two? In the article, the founder of Polvi and Docker, who had mentioned CoreOS founder Sonomon, believed that rocket and Docker were not competitive. The Docker platform is a product, and rocket is a component. Enterprises can choose Docker to replace Cloud Foundry, or you can use rocket to build cloud Foundry. CoreOS when he released rocket that Rocket appeared because some people needed a more "pure" container. In other words, Rocket is a standard implementation of the APP Container specification. Based on the "APP Container specification", the author analyses the difference of rocket and Docker in technology realization. The following is the original text:

Docker and Rocket, the same

First of all, for those who compare Docker with Rocket, I would like to advise you to investigate them properly first. If there are two software: A history of more than 1 years, as an Open-source project by thousands of developers around the world to participate, and has been or is about to be deployed in the actual production environment, testing, while the other software is "fresh out". If the more mature software is not particularly bad, chances are that it will be the winner.

So it would be fairer to compare Docker0.1.1 with the most recent pre-release rocket. In addition, CoreOS CTO Brandon Philips has repeatedly stressed that docker some of the features will not be planned to join rocket-not just now, perhaps never. Why? Because the focus of the rocket project, at least for now, is not to achieve Docker. Rocket is the "app Container specification" implementation, so to compare the two, it's best to compare "app Container specification" with the original Docker list or other specifications implemented by Docker.

The following comparisons will be based on the above consensus:

systemd

The most common topic of discussion about Rocket is systemd-spawn or systemd. CoreOS has systemd as the init system for their Linux distributions. They can then use init scripts or Upstar, but they choose to use the INIT system that will become the standard for all the mainstream Linux versions in the future. To tell the truth, I don't have any original opinions about SYSTEMD, but I have read some articles of Lennart and others. For CoreOS, it would be unwise to use SYSTEMD as the init system for a new Linux distribution. In addition, CoreOS has gained my trust, and I have no doubt about it. You may throw btrfs and argue with me, but that will soon disappear, and I hope it will be repaired or replaced by other reliable alternatives. Stability, after all, is more important than function.

Well, let's get back to the problem. One of the things that SYSTEMD does or can do is process management. You might think that the way systemd solves this problem is somewhat overlapping the concept of service, process management, and complicates tasks that could have been simple beyond PID1, but because CoreOS is a loyal user of systemd, it would be strange to use other tools to implement it.

In addition, according to Brandon, Rocket's initial implementations used Systemd-nspawn because they wanted to use systemd,systemd-naspawn and were doing what they wanted to do, so it helped start the project. Frankly, in the 0.1.1 version, I'm not concerned about the technology they use, which may change later, because the rocket is designed to be pluggable. If you do not like Systemd-nspawn, you can use your own STAGE1 implementation, Rocket has provided detailed command-line parameters.

It's also important to note that those who think they want to use rocket must run Systemd are completely wrong. Rocket don't need systemd. It can also work with other init systems, such as SYSV or upstart. I tested rocket on the upstart and did not encounter any problems. Rocket is simply "reusing" systemd and Systemd-nspawn, dealing with Stage1 and stage2.

App Container

Some people may not have an accurate understanding of "APP Container specification". They've been talking about systemd and saying how good Docker is and don't need to run a process in a container with systemd. Docker a container that manages a single process through a background process. The Docker background process is not written as a process management tool, and when your container stops, the drawbacks of the design are revealed. You end up coping with the process management tools in the host or container. If you have not experienced such a thing, either you may be lucky, or you might not be able to run a large number of containers in your environment.

We need process management, or some functionality provided by process management. If you read "APP Container specification", you'll understand that. I would like to extract a few of them as follows:

The

container executes one or more applications, sharing PID namespace, receptacle namespace, mount namespace, IPC namespace, and UTS namespace. Before execution, each application will begin to convert to (for example, chroot) its own unique read-write root file system. A container is defined to contain a series of applications that should be started together, and an isolator to apply to the entire container.

The above explicitly mentions several processes that share Linux namespaces. In other words, the pod of kubernetes is much like the definition of the container above, and I don't know if it has anything to do with CoreOS's active involvement in kubernetes development. But Kubernetes pod is a set of containers, not a set of processes in a container. This allows you to benefit from the formation of a pod from multiple Docker mirrors. This is where the app Container specification defines dependencies, so your container can depend on other containers, so the final container created through STAGE0 runtime may be.

Now that you have run multiple processes in the container, some of which may be background processes and may need to be supervised, you need a process manager. The best manager I've ever used is runit, but then again, when you've accumulated a lot of experience with SYSTEMD, why do you want to write Runit scripts or use other managers? If I were coreos, I would make the same decision--SYSTEMD.

Docker and Namespace

Now, let's go back to Docker. Docker has been advocating a container to run a process. In general, I agree with this, because the Linux container is mainly to implement process isolation of the host, and each container running a process, will give you more flexibility and complex, independent updates, rollback, etc., the operation is simpler. However, when you create a new Docker container or de facto LXC container, the container is reassigned to a new Linux namespace provided by Libcontainer. To tell you the truth, I think it's a bit wasteful. Docker also make sense because you want to run a separate process in a container, and if you want to provide a more general process environment to cover most of the use cases, you may need to libcontainer a large number of available namespaces that are efficiently provided.

Creating a set of namespaces for a single process increases the amount of extra management work for the kernel. If you run a lot of containers on your host, there may be bottlenecks in some aspects of the kernel. You might say that the overhead is small, but why do you have to overdo the kernel?

Therefore, to save overhead, you can share namespaces between processes. But there's a problem, if you start sharing the namespace, and the container that created it is terminated, it deletes all the processes that share the namespace. Kubernetesde the problem when designing pod. The first container created in Kubernetes pod is assigned an IP address from the INTERNAL/24 VLAN, which is also shared by a receptacle namespaces container within the pod.

You can see the subtleties here. Whenever a container created by network is stopped, he revokes all other containers in the pod because there is no namespace to share, so it is necessary to create a new pod from scratch and reassign the IP. What's worse, your connection is gone. So, when your container stops, you can't automatically reboot them. I believe that we can find a solution by observing the process of Docker destroying the container, but that's a bit of a detour. So if you want to run multiple processes in the Docker container, you'll need a process management tool.

Regulatory Log

Finally, let's talk about the log. The log is the responsibility of the management process. Typically this process manager captures the stdout/stderr of a process and logs it to a log. The log descriptions on the APP Container specification are as follows:

applications should log on to stdout and stderr. The container execution program is responsible for capturing and continuously outputting.

For CoreOS, Systemd seems to be an obvious choice. Runit is doing well in this area, but it goes back to what I've already mentioned, professionally speaking, which is unnecessary extra work.

Docker's approach is to record nearly six months of logging to the log plug-in prosposal document. Although not yet realized, I have confidence in it, given that it was proposed by Michael Crosby.

user experience and usage

Another complaint about Rocket is the user experience. But keep in mind that the latest release of Rocket is 0.1.1. Do you know what the first car looks like? It looks like this. This is certainly not the best user experience, but this is the first step towards Ferrari and Porsche.

But also the most important thing is that rocket is the implementation of App Container specification and will not impose anything on you. Likewise, Dockerfiles, Docker daemon, and everything else you want to achieve, are on your own. Even stage1!. You want Docker to be the manager? Crack it and pass it as a parameter to Rkt run to become a Stage1 process. I can imagine that in the future, CoreOS is likely to implement some great tools and even enhance the OPS and devs user experience. But those tools may be a separate project, not a core part of rocket. At this point I think the most important thing is the stability of the project.

Concluding remarks

I want to make it very clear that I like Docker and have been paying attention to Docker. This blog post is not about Docker or rocket good or bad. Most people do not read "APP Container specification" to always compare the two.

Finally, it is strongly recommended that you get to know Docker and rocket. If you like coding in C, you should try LXC or other similar techniques. There are many things you can do and many opportunities that will make you a part of the current upheaval in this industry! (Compile/Wang revisers/Zhou Xiaolu)

SOURCE Link: Docker vs rocket Gimme a break

"Related activities" Docker Shanghai Meetup event will be held on January 18, 2015 at Ucloud Moore's conference room, where 鞥 Fu: co-partner of the joint branch, Dr. Wu Bingzong, "Application Container" Docker "and Infrastructure container" Joyent " Smartmachines integration, point-thaw network operation and maintenance technology director Wan Lintao "Docker in the DevOps process of use (to point to the Internet financial applications as an example)", Cisco Senior Engineer Yang Zhangxin " Kubernetes system Architecture (Kuberenetes of the core components of the implementation of the principles and work together), as well as Ucloud senior technical experts Rocheng to the "Docker and database application of the combination." Registration Address: http://huiyi.csdn.net/activity/product/goods_list?project_id=1646

If you need more information about Docker or technical documentation to access the Docker technology community, if you have more questions, please put it in the Dcoker Technical Forum and we will invite experts to answer. CSDN Docker Technology Exchange QQ Group: 303806405.