Shulou(Shulou.com)06/01 Report--

Today, I would like to talk to you about how to view the future of Docker network management. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

Recently, there has been a lot of discussion about Docker network management, and people have different opinions on this issue. The main reason for the controversy is that more and more people use Docker in recent years, and users gradually realize that the network defects of Docker need to be solved urgently. Of course, the actual situation is also the case. At present, the network capacity of Docker is seriously insufficient and does not support complex settings. Now the network model of Docker has performance problems and is not easy to expand. But Docker's network model is pretty good for a basic application. However, we can't stay at the level of using "basic applications" forever, which is far from enough with the popularity of cloud computing and microservices. As one of the contributors to libcontainer, I would like to express some of my views through this article.

First of all, I need to talk about some background knowledge related to the Internet. From the beginning, Docker users and developers realized the shortcomings of the Docker network model because they needed to assign more IP addresses to the Docker container, and using LXC as the container engine would not be bothered by this problem. Containers have been around for quite a long time, but because of the advent of Docker, many people learn the Linux namespace, including the network namespace, which is the cornerstone of the Linux container network. Docker Tinkerer Extraordinaire has written a lot of blogs and developed the pipework tool, which can help you understand Docker's network and how to build complex networks in Docker. Although pipework is powerful, it is only a third-party tool, and we hope that Docker will support it natively.

I've been paying attention to its network problems since Docker version 0. 7, but I didn't just dive into the source code. Instead, I first tried to study the LXC network, which I hope will help me find the key points of the problem and apply it to Docker. I contacted Jerome and reached a consensus on embedding golang-pipwork hack in Docker in the future. And then there's a long story. Seven months on, we haven't put much effort into the Docker-network-land** project, and there are few people talking about network-related issues on GitHub. When I open the links to the problems that need to be solved, I think it's time to change. The Docker are concerned with the higher priority issues because we already have pipework and pipework derivatives. At the same time, more and more practical tools enable us to break through the network limitations of Docker. People no longer care about the network problems of Docker, but only through a small number of people to fix those existing problems and add some new features.

In the twinkling of an eye, a few months later, we finally decided to change the status quo. We made [suggestions] () on the Internet to the authorities and set up a chat room about libnetwork, although these are a long way from some of our immature ideas. Now more and more people are taking part in the discussion. From my point of view, this is crucial for Docker. It is gratifying that many people in the community are beginning to realize this problem.

The network problems of Docker are extremely complex, both superficial and deep. It will involve a lot of projects, from the local development environment to similar awesome Kubernetes projects. When you read Kubernates's design document on the web, you will find some good ideas. In the past year, we have developed a lot of tools and libraries to solve network problems. I really hope that the ongoing discussion will not fuck our existing work, but will create a better environment for new people. I use the word Fuck because I've seen how a bad decision disappoints everyone, and that's one of my concerns about Docker. Maybe these are just life experiences, as the saying goes: history gives us nothing, so I just worry about the ancients.

To me, Docker means more than just software delivery, not just DevOps. It is another development tool. To me, Docker should be a tool and, perhaps more importantly, a platform. Well, it's an open platform, and it's not the kind of software platform we often talk about. If Docker is going to let users or companies build their solutions on existing platforms, then it should not rely on other projects. I hope the authorities won't do this, because the guys at Docker already know how to get rid of LXC and use their own libcontainer project instead. Similar ideas should be applied to network problems.

There are some plans to associate the OVS project with Docker, which has been part of the kernel since Linux Kernel 3. 3. When I heard this, I thought the donkey kicked me in the head. First of all, I am not against the use of OVS, in fact, it is a very good suite of web tools. Its setup is complicated and has a steep learning curve for beginners, but once you learn it, OVS can help you get twice the result with half the effort. One discussion I heard on this topic was: "* * if OVS works on Docker, then everything will be fine at work *". Let me tell you, folks: if I spend a lot of time learning it, the end result will be: "OK, it can be used." I don't want to be cynical, but the truth is that OVS crashes in some common situations. So using OVS is just a crazy idea. I don't want everyone to agree with me. Yes, you can do nothing, or you can use it as a basic daily work. You can make system administrators and network engineers happy, but not always, and it can also make developers lonely. This is a complex topic, of course, there is not only one way to solve the problem (there is no silver bullet), so we do not expect to have a silver bullet.

This post is not about whether to make OVS part of Docker. I chose to talk about OVS because it may be one of the solutions to Docker network problems. The scope of our discussion is, and is not limited to, Docker third-party projects, whether it is open source or not. So far, Dockers have done some work to avoid this problem. The important point is what we talked about earlier: avoiding dependence on a project. Once you decide to use a project, your attention has to be focused on avoiding damage to the interdependence of the platform building project that is already an organic whole. As we are now talking about projects such as flannel, weave, docket, etc., there are many more new project platforms that bring many dependent projects.

At present, having a pluggable network back-end setting seems like a good suggestion. But it will take some time until there is a hardware-based pluggable architecture design rather than just solving network problems, with more Docker involvement and time verification. This change takes place at the core of Docker and is currently being transferred from the mobile terminal to the network part. I think it's safe to build a robust default background for Docker, rather than giving users a list of solutions and forcing them to use a fixed path. Inevitably we will refer to and rely on other projects, which will not affect current Docker users and will not affect future Docker users. We all know that it's not possible to satisfy everyone, but you can create a friendly environment to build your own solutions so that different users can work together without affecting each other. If you join the pluggable API project like me, then we are in the same boat.

Speaking of the future of the Docker network, I am really excited, I very much look forward to Docker to make the right decision. Most importantly, I hope this article will inspire more people to participate in this project.

After reading the above, do you have any further understanding of how to view the future of Docker network management? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.