Docker: when do I need to host a container in a virtual machine?
Application containers guarantee high speed and resource utilization, but they lack the security that virtual machines provide. Therefore, today I want to talk about using Docker inside a VM, in particular, the OpenSource project QEMU / KVM.
If you don’t dive deep into the specifics of various containers, you can briefly characterize Docker as a fast and dynamic solution that allows you to instantly launch millions of containers with specific applications. Docker offers everything you need to run ready-made builds of software with related components, but many still worry about the safety of such loads. The problem is that Docker is still a very young solution, and not all “children's problems” have been resolved. And when you launch multiple Docker environments on one machine, an attacker purely technically allows you to access the resources of one user through hacking another. Agree, this is not good.
Docker inside QEMU
Inside Docker, isolation is implemented today with NameSpaces, but the reliability of this approach is still in doubt. Therefore, it is quite common practice to launch a container inside a virtual machine. As a rule, QEMU is chosen, as it is one of the most popular open source virtualization projects. Inside the QEMU virtual machine, single-user containers are already running. Thus, we find a compromise between security and speed, because users are reliably protected from each other, and applications of the same owner work quite quickly, being launched in a container environment.
Chasing speed
However, over time, as containers become larger, this trade-off begins to be a problem. Therefore, developers are beginning to actively deal with it. So, various technologies appear in the community that help to solve the urgent issue of improving the performance of more secure environments that use Docker.
For example, ClearLinux is Intel's own distribution, which is designed not only to work within the intel architecture ecosystem, but also for extended Docker support. ClearLinux has the ability to configure “layers” - individual components of the file system, from which the root directory of the Docker container is formed. This allows you to significantly increase the efficiency of working with the hypervisor. The solution is very promising, but of course, it shows its main advantages only on Intel equipment.
Another option is to use Unikernel. Specially prepared OS images can reduce the impact on the performance of the presence of the OS kernel in the guest VM (where Docker is already running). Specially lightened kernels of various operating systems with a regulated address space are proven, supported and ready-to-use solutions optimized for working with certain applications. If Unikernel has already been created for the application you want to use in Docker, then you can use VM isolation with much greater efficiency.
We at Virtuozzo also continue to monitor the evolution of Docker and offer our solution to this problem. Thus, the KVM hypervisor based on Virtuozzo not only allows the use of lightweight VMs, but also supports a number of optimizations specifically for launching Docker containers. In addition to this, lightweight VMs on OpenVZ and commercial Virtuozzo add backup and additional security monitoring functions to KVM's capabilities, contributing to the protection of the Docker ecosystem launched as part of the VM.
Docker Support Becomes Needed
Although today we are talking about the fact that it is possible to optimize Docker security by using VMs or light VMs as an intermediate level, in the near future the community will not only increase the performance of VMs as a separate isolation layer, but also the ability to launch Docker containers directly based on the hypervisor.
In the Virtuozzo ecosystem, we generally consider Docker as one of the possible options for launching loads in a common virtual environment - along with lightweight virtual machines and traditional virtual machines (based on different operating systems). Today, work is actively ongoing to expand support for o-Docker services, such as hub, compose, kubernetes, flocker, libnetwork, various security verification tools, etc.
Thus, due to the own efforts of the Docker team, the availability of various projects to optimize the effectiveness of the intermediate VMs for launching Docker and the promising support for Docker at the hypervisor level, Docker application containers will soon be able to declare a decent level of security without compromise with the speed of work, while maintaining the main advantage of docker.
