The five major Docker myths that Java programmers need to be aware of

Docker is now very fire, container technology is not omnipotent, but this is actually a misunderstanding, not to be hyped out of the bubble fascinated eyes, this article thrown away speculation, rationally from the Java Programmer's point of view, listed Docker current five myths, to help you better understand the advantages and problems Docker.

Throw away the hype of the media and vendors, how can we better and rationally use Docker?

Docker has recently been a source of concern for obvious reasons. How to successfully deliver the code has been troubling everyone. Traditional container technology is mess in many needs and templates. Docker can create containers simply and repeatedly. With Docker, you can deliver code faster and more naturally than in other containers. Duang,docker the Fire! There are also misunderstandings and misunderstandings. Don't be too sure that Docker works or doesn't. Thinking about Docker rationally and comprehensively will help you really understand whether you really need it.

This article lists the five major Docker misreading from the Java perspective. But first, let's introduce some background knowledge. To better understand Docker, we consulted Fewbytes's Avishai Ish-shalom, who has extensive Docker experience and is also the organizer of the DevOps days conference. We have enumerated these misconceptions with him.

Main misunderstanding

1. Docker is a lightweight virtual machine

This is the most important misunderstanding when we beginners to Docker. This misunderstanding is understandable, Docker does look a bit like a virtual machine. There is even a comparison between Docker and virtual machines on the Docker site. However, Docker is not actually a lightweight virtual machine, but an improved Linux container (LXC). Docker and virtual machines are completely different, and if you use a Docker container as a lightweight virtual machine, you will encounter a lot of problems.

Before using Docker, you must understand that there are many essential differences between Docker containers and virtual machines.

Resource isolation: Docker does not reach the level of resource isolation that virtual machines can provide. Virtual machine resources are highly isolated, and Docker needs to share some resources from the beginning of the design, which Docker cannot isolate and protect, such as page caching and kernel entropy pooling. (Note: The kernel entropy pool is interesting, it collects and stores the random bits generated by the system operation.) The machine uses this pool when it needs to be randomized, such as password-related. If the Docker container consumes these shared resources, other processes can wait until those resources are freed.

Overhead: Most people know that the CPU and RAM of a virtual machine can provide a similar performance to a physical machine, but there is a lot of extra io overhead. Because the package of guest Os,docker for a virtual machine is smaller, it requires less storage overhead than a virtual machine. But that doesn't mean that Docker doesn't have any overhead problems. Docker containers still need to pay attention to IO overhead, except that there is no virtual machine to be serious.

Kernel usage: Docker containers and virtual machines are completely different in kernel usage. Each virtual machine uses a single kernel. The Docker container shares the kernel between all the containers. The shared kernel brings some efficiency gains, but at the expense of high availability and redundancy. If the virtual machine has a kernel crash, only virtual opportunities on that kernel are affected. In the case of a Docker container, all containers will be affected if the kernel crashes.

2. Docker makes applications extensible

Because Docker can deploy code on multiple servers in a very short period of time, it's natural for someone to think that Docker can make the application itself extensible. Unfortunately, this is wrong. The code is the cornerstone of the application, and Docker does not rewrite the code. The scalability of the application still depends on the programmer. Using Docker does not automatically make your code easy to scale, just makes it easier to deploy across servers.

3. Docker is widely used in production environments

Because Docker is gaining momentum, many people think that Docker can be used on a large scale in production environments. In fact, this is wrong. Notice that Docker is still a new technology, immature and growing, which means there are a lot of annoying bugs and features to be perfected. It's right to be interested in new technologies, but it's best to figure out the right use scenarios for new technologies and where to look. Docker is now easy to apply to the development environment. Using Docker makes it easy to build a lot of different environments (at least, the feeling is to be able to build a different environment), which is useful for development.

In production environments, the immaturity and imperfection of Docker also limits the use of scenarios. For example, Docker does not directly support the monitoring of multiple machine networks and resources, which makes it almost impossible to use in a production environment. There are, of course, many potential places, such as the ability to deploy the same package directly from the development environment to the production environment. There are also some Docker runtime features that are useful for production environments as well. But in general, in the production environment, currently less than the advantages. This is not to say that it cannot be successfully applied to the production environment, but it cannot be expected to mature and perfect at the moment.

4. Docker is a cross-os

Another misconception is that Docker can work on any operating system and environment. This may come from the analogy of loading and unloading containers, but the relationship between the software and the operating system is not as straightforward as the shipping position.

In fact, Docker is just a technology on Linux. And Docker relies on specific kernel features and must have the latest version of the kernel. Depending on the differences in the OS, if you are not using the most common features across the OS, you will encounter a lot of problems. These problems may only be 1%, but when you deploy on more than one server, 1% is also fatal.

Although Docker runs on Linux only, it can also use Docker on OS X or Windows. Using Boot2docker will run a Linux virtual machine on OS X or a Windows machine so that Docker can run in this virtual machine.

5. The security of Docker enhanced applications

It is also a misconception that Docker can improve the security of the Code and the process of delivering the code. This is also true of container and software on the difference between containers. Docker is a containerized technology that adds orchestration methods. However, Linux containers have some security vulnerabilities that could be exploited. Docker does not add any security layer or patches to these vulnerabilities. It is not yet an iron cloth to protect the application.

From the Java point of view

Some Java developers have started using Docker. Some of the features of Docker make it easier to build a scalable context. Unlike Uber-jar,docker, you can help package all dependencies (including the JVM) into a ready-to-publish image. This is also the most fascinating place for developers to be Docker. However, this also poses some pitfalls. In general, programmers need to interact with the code in different ways – monitor it, debug it, connect it, tune it ... if you use Docker, this will require additional work.

For example, we want to use Jconsole, which relies on JMX functionality, and JMX requires a network to use RMI. Using Docker is not straightforward and requires some tricks to open the desired port. We initially discovered that the problem was that when we wanted to build Takipi Docker applications, we had to run a daemon outside the JVM in the container. The detailed solution is on GitHub.

Another serious problem is that the performance tuning of Docker containers is quite difficult. When using containers, you don't know exactly how much memory each container allocates. If you have 20 containers, the memory will be assigned to them in a way you are unsure about. If you plan to tune the heap size with parameter-xmx, it is difficult, because the processing of the JVM within the Docker container depends on the ability to automatically get the memory size allocated to the container. If you do not know how much memory is allocated, performance tuning is almost impossible.

Conclusion

Docker is a very interesting technique and has some real and effective usage scenarios. As an emerging technology, it also takes a lot of time to solve missing features and known bugs. However, there is a lot of hype in this field now. But remember, the hype is not a success ~ (Source: Dockone)

?

The five major Docker myths that Java programmers need to be aware of