Name any technology company, and with almost 100% probability it turns out that it is interested in promoting container technologies. Google, of course. IBM - yes . Microsoft - of course . So VMware could not pass by.
Taking into account the fact that the VMware portfolio has a complete set of software for virtualized data centers, we are looking forward to the company's interest in popular technology. In the past, systems based on vSphere worked with containers as usual virtual machines, and this made management difficult and led to security problems. ')
“Now containers will become full vSphere elements. You can manage both traditional applications inside virtual machines and next-generation container-based applications. Both technologies will work side by side on the same platform, ” said Kit Colbert, director of cloud VMware applications.
To support the technology, the company's engineers modified the virtual machine and brought some of its functions to the hypervisor level. This allowed us to add support for the containers, while maintaining the usual qualities of the virtual machine. It turns out that VMware introduced the ability to immediately get all the benefits of Linux-containers and traditional virtualization on a single platform vSphere.
And, perhaps, this decision is the most correct. Containers can fit much more applications on a single physical server than any virtual machine. VMs occupy a lot of system resources, since each of them contains not only the operating system, but also the virtual equipment necessary for operation, and this immediately takes away a lot of RAM and processor cycles.
In the case of containers, the situation is quite different - you can place only the application and the necessary minimum of system libraries. In practice, this means that when using containers, you can run two to three times more applications on one server. In addition, containerization allows you to create a portable and holistic environment for development, testing and subsequent deployment.
It seems that the containers are laid on the blades of the VM in all respects. And that would be true if the comparison ended there. However, the question is still somewhat more complicated and wider than the simple "where more applications fit."
The first and most serious problem that is often overlooked is security, no matter what anyone says. Daniel Walsh, security engineer at Red Hat, published the article “Empty Containers”. It discusses Docker, which uses libcontainers as the basis. Libcontainers interacts with five spaces: Process, Network, Mount, Hostname, Shared Memory.
At the same time, it turns out that many important subsystems of the Linux kernel function outside the container. These include various devices, SELinux, Cgroups, and the entire file system inside / sys. This means that if the user or application has superuser rights in the container, the operating system can be cracked.
There are many ways to secure Docker and other containerization technologies. For example, you can mount a read only partition / sys, force container processes to work with certain partitions of the file system, and configure the network so that you can connect only to certain internal segments. However, this will have to take care of yourself.
Here are three tips Walsh gives on this:
Remove privileges;
Try not to start services with root-rights;
Always keep in mind that root-rights can act outside the container.
But security is not the only problem. There is still the problem of quality assurance. Suppose the NGINX web server is able to support X containers, but is that enough for you? Is there an updated TCP balancer? Deploying an application in a container is pretty easy, but if you make a wrong choice of components, you just waste time.
“Dividing the system into many smaller individual parts is a good idea. But this also means that a large number of elements will have to be managed. There is a fine line between decomposition and uncontrolled sprawl, ” comments Rob Hirschfeld, CEO of RackN.
Remember that the whole essence of the container is to run a single isolated application. A large number of tasks per container is contrary to its concept. Docker allows you to pack your application and all its dependencies in a single image. The difficulty lies in the fact that you usually “pack” a lot more resources than you need, and this leads to an expansion of the image and a large container size.
Most people who start working with Docker use the official Docker repositories, which, unfortunately, just lead to an image the size of a skyscraper when it could be no more than a birdhouse. They have too much rubbish. The standard size of the Node image is at least 643 MB, which is a lot.
Here microcontainers come to the rescue, which contain only the libraries of the operating system and other dependencies required to run the application, and the application itself. You will see how the application, which occupied 643 MB, will take 29 MB, which is 22 times less.
Microcontainers offer many benefits. The first, of course, is the size, the second is the fast and simple transfer to different machines, and the third is increased safety. Less code means fewer vulnerabilities.
On this subject there is a good explanatory video:
So how do you create these microcontainers? It is best to start with a scratch image, in which there is absolutely nothing. With it, you can create the smallest image for your application, if you can compile the project into one binary file without dependencies, as Go allows you to do. For example, this image contains a web application on Go and weighs only 5 MB.
However, not everyone writes programs on Go, so you will probably have several dependencies, and the scratch image will not work for you. We use Alpine Linux. The image of Alpine weighs only 5 MB. Therefore, for our simple application on Node, the Docker file will look like this:
FROM alpine RUN apk update && apk upgrade RUN apk add nodejs
Now, to add code to the image, you need to add a couple more lines:
FROM alpine RUN apk update && apk upgrade RUN apk add nodejs WORKDIR /app ADD . /app ENTRYPOINT [ "node", "server.js" ]
Application code and detailed instructions can be found here .
Such Docker images contain only the necessary components for the application to work. Nothing extra. Such is the world of microcontainers.