Docker has been one of the buzzwords in recent years. Containers in itself are nothing new in the Linux world, and anyone using a shared web space is almost certainly using some container implementation. Docker, however, provides management interfaces and isolation mechanisms that make Docker containers more attractive to use in enterprise environments than any prior container implementation.
A good enough reason to have a closer look at Docker.
What are Containers?
Imagine a big cargo ship transporting numerous containers from one end of the world to another. The containers share the ship carrying them including the engine and bridge, but the content of each container is isolated from the other. Some containers might include additional features such as a cooling and monitoring, others might simply be a storing space.
Docker is very similar to our container ship. Each container is isolated from the other having its individual content and features. Yet they all share the host system’s resources. No container can influence another container or affect the workings of the host. Yet it is always in full control of its interior. The host, however, maintains a high-level of control over each container.
Virtualization, in contrast, is more like a naval fleet. Each ship of the fleet has a different task. You have an admiral giving commands and supply ships bringing fuel to each ship. However, each ship has a separate bridge and engine room. Each ship in the fleet has its tasks and can operate entirely independently and even, to a certain extent, ignore the admiral. But if the supply ship does not come, the whole fleet stops working.
In the virtualization world, the supply ship is the hypervisor on the host system, which provides resources to every virtual machine. If the host breaks down or the hypervisor misfunctions, the virtual machines do not work either. The admiral is the hypervisor control program, which can start and stop VMs and connect to their shell, where it still might require a username and password to affect the content of the VM. Each VM has its own operating system that might be different from the host’s one and a particular task.
My blog post on virtualization explains the advantages of virtualization and which impact it has on security and resource usage. However, while virtualization provides the ultimate isolation of the environments, it also entails additional costs and maintenance workload for having to run the entire operating system for each instance.
What is special about Docker?
The main idea behind Docker is to isolate applications from each other. Containers are, however, a small step below virtualization when it comes to isolating applications from each other. Docker Containers utilize specialized interfaces of the Linux Kernel and the file system to create isolated environments. Using the Kernel and file system interfaces, the containers can make use of any of the resources available to the host system without being able to influence other containers.
Union File System
Only a particular number of file systems provide the needed interfaces for running containers. These are called Union File Systems. This type of file system takes the file system from the host OS as a basis and writes all changes done by any application into a unique file. Whenever the container or the host restarts, the container-specific changes and the host file system are combined and presented as the file system inside the container. This ensures that the space on the server is used most efficiently, yet neither the host nor other containers are influenced through these changes.
Many applications require specific library versions. Some require the most recent and others the most proven version. Docker enables the container to choose between using the libraries provided by the host operating system, installing them in a different version or using libraries that are not available on the host. This is particularly helpful if you are running several applications that require different versions that are not compatible with each other.
Paradigms Behind Docker Containers
Most important within a Docker container is, of course, the application. For the end user, this is often all that matters.
From a developers’ perspective, however, there are two different approaches to using the Docker technology. One of the approaches, which we use within the App Center, treats Docker as we would treat virtual machines. So an almost complete operating system is running inside every container including all components of an app and the app itself. This approach allows us to update the app in the container and the UCS basis separately. As the safe operation of applications is more important to us than the reduction of overhead costs, we prefer this approach.
The more traditional idea behind Docker is to make the container as light weight as possible. Reducing it not only to an end user application but down to a single process. For an application comprised of a database, an application server, and a web frontend, this would mean deploying three interchangeable containers. This approach mainly focuses on optimal resource utilization and scalability as spinning up one additional container that seamlessly integrates into the stack is easy. Resources can thus be used more efficiently. However, this method requires that the application was specifically developed for Docker.
Both approaches have their advantages and disadvantages, and none can be said to be superior to the other in all circumstances.
Docker provides many interesting approaches and options to provide lightweight and efficient resource separation. Both the Docker library (“Docker Hub”) and the UCS App Center provide plenty of software using Docker. But as with all software, careful planning is the best insurance for having an efficient and secure environment.