A container is any receptacle or enclosure for holding a product used in storage, packaging, and shipping.
Wikipedia, “Container,” https://en.wikipedia.org/wiki/Container , 2018.
In this chapter, you will learn the basics of containers and how they are used in the software industry. You will also see how containers differ from virtual machines and discover some of the pros and cons of using containers. This chapter puts you on the path to learning about Docker in depth.
What and Why?
You can’t work in a software company today and not hear about software containers: Docker, Kubernetes, Mesos, and a host of others. But before we dive into any of this, let’s look at what really changed in the world that led to the need for containers.
When you run a program on your machine in a certain environment, and the environment that supports your program on a production machine is not identical, problems arise. You test using a certain version of the programming language, and it runs a different version in production, so something weird happens, owing to the lack of forward or backward compatibility. Alternatively, you rely on a certain version of an SSL library, and a different version is installed in production. The network topology or the security policies might be different. These inconsistencies can cause all sorts of problems. Let’s take a step back. What is a container in the traditional sense of the word, and how can containers solve this problem?
“A container is any receptacle or enclosure for holding a product used in storage, packaging, and shipping,” right? Now let’s apply this to software.
The concept of container technology uses this same paradigm of shipping containers in transportation. The idea is that before shipping containers were invented, manufacturers had to be prepared to ship goods in a wide variety of modes—ships, trains, or trucks—with different sized containers and packaging. By standardizing the shipping container, goods could be seamlessly transferred among shipping methods, without any additional preparation. Before the advent of this standard, shipping anything in bulk was a complicated, laborious process.
The promise behind software containers is essentially the same. Instead of shipping via a full operating system (OS) and your software (and maybe the software that your software depends on), you simply pack your code and its dependencies into an image that can then run anywhere, and because these are usually pretty small, you can pack lots of containers onto a single computer.
Put simply, a container consists of an entire runtime environment: an application, plus all the dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package. By containerizing the application platform and its dependencies, differences in OS distributions and underlying infrastructure are abstracted away.
By allowing software code to be prepped in ready-made software containers, the code can quickly be moved around to run on servers running the Linux OS or be connected to run a distributed app in the cloud. This approach also has the benefit of speeding up the testing process and building large, scalable cloud applications. While this approach has been around in software development circles for many years, it has recently become more popular with the growth of Linux and cloud computing. Earlier projects taking the container approach have included BSD Jails, Solaris Zones, and Unix V7.
Containers vs. Virtual Machines
Heard the terms virtualization or virtual machine? First, what are virtual machines (VMs)? In the present day and age, when collaborating and working remotely have become commonplace, virtualization is key. Historically, as server processing power and capacity increased, bare metal applications weren’t able to exploit the new abundance in resources. Thus, VMs were born, designed by running software on top of physical servers, to emulate a particular hardware system.
At the heart of it, a VM is an app! Typically called hypervisor, it emulates an OS. Hypervisor is a program that enables you to host several different VMs on a single hardware. Everything in the VM is self-contained, and it typically has all the capabilities of the OS it is imitating.
Sounds like a fake computer, doesn’t it? However, there are some important distinctions. A VM is indeed entirely virtual, in that it doesn’t have any hardware of its own, except for the storage drive it comes from. More modern and complex VMs are supported by server setups.
Virtualization services are usually provided by specific companies, such as VMware, for example.
How do containers compare to VMs, though? Are they the same thing? When do you use what? And what is the key difference, really?
VMs take up a lot of system resources. Each VM runs not just a full copy of an OS but a virtual copy of all the hardware that the OS requires to run. This quickly adds up to a lot of RAM and CPU cycles. In contrast, all that a container requires is enough of an OS, supporting programs and libraries, and system resources to run a specific program.
What this means in practice is that you can put many more applications on a single server with containers than you can with a VM.
OS virtualization has grown in popularity over the last decade, to enable software to run predictably and well when moved from one server environment to another. But containers provide a way to run these isolated systems on a single server or host OS.
Containers sit on top of a physical server and its host OS, for example, Linux or Windows. Each container shares the host OS kernel. Binaries and libraries are the only elements created from scratch. Containers are thus exceptionally “light”—they are only megabytes in size and take just seconds to start, as opposed to gigabytes and minutes for a VM.
Containers also reduce management overhead. Because they share a common OS, only a single OS requires care and feeding for bug fixes, patches, and so on. This concept is similar to what we experience with hypervisor hosts: fewer management points but slightly higher fault domain. In short, containers are lighter weight and more portable than VMs.
VMs and containers differ in several ways, but the primary difference is that containers are isolated processes running on an OS that are implemented using namespaces. With VMs, the hardware is virtualized to run multiple OS instances. Containers’ speed, agility, and portability make them yet another tool to help streamline software development.
Containers vs. virtual machines
Pros and Cons of Containerizing Applications
Let us start with understanding how applications are run traditionally. That will help us understand what containerization is not.
Running an Application on a Host Machine
Traditionally, you would install an application on a host computer and run it directly from a host computer’s file system. The environment this application runs in would include the host’s file system, network interfaces, ports, devices, etc. To get the application working, you would additionally require other packages that your application depends upon. You might also want different versions of the same package running on your system.
Besides this, running multiple instances of your service on the host computer might get tricky, because the application might bind to a particular network port by default; other services might bind to the same network port; the service might have to read configuration files on service startup; etc.
Running an Application on a Virtual Machine
Running an application on a VM can overcome some of the drawbacks of running applications directly on the host OS. A VM also runs on the host, but it has its own kernel, file system, network interfaces, etc. This makes it easy to keep almost everything inside the OS separate from the host.
Because a VM is a separate entity, you don’t have the same issues of inflexibility that arise from running an application directly on hardware. You could run an application ten times on the host by starting up ten different VMs. The service on each VM could listen on the same port number and not cause a conflict, because each VM could have a different IP address, as if it’s a different computer altogether, except that it’s not.
Likewise, if you have to shut down a host computer, you could either migrate the VM to another host (if your virtualization environment supports it) or just shut it down and start it again on the new host.
The downside of running each instance of an application in a VM is the resources it consumes. Your application might require only a few megabytes of disk space to run, but the entire VM could consume many gigabytes of space. Also, the startup time and CPU consumption of the VM is almost sure to be higher than the application itself would consume.
Containers offer an alternative to running applications directly on the host or in the VM, which can make the applications faster, more portable, and more scalable.
Advantages of Using Containers
Containers offer both efficiency of resources and flexibility of usage. While VMs take up several gigabytes of space, containers are sized within the range of tens to hundreds of megabytes. A server can host significantly more containers than VMs because of the lack of the need to run multiple copies of OSs. Flexibility comes from the container being able to carry all the files it needs with it. As with an application running in a VM, it can have its own configuration files and dependent libraries, as well as its own network interfaces that are distinct from those configured on the host. So, a containerized application is easier to move around than its directly installed counterparts, and it doesn’t have to contend for such resources as port numbers, because each container they run in has separate network interfaces.
Because the container can hold the application and its dependencies it requires to run, the startup time, disk space consumption, and processing power is much lower than those of a VM. Containers also don’t have a separate kernel, as does a VM. Using containers can decrease the time required for development, testing, and deployment of applications and services. Testing and bug tracking also become less complicated, because there is no difference between running your application on a test server vs. production.
Containers are a very cost-effective solution and can potentially help you decrease your operating and development costs. Container-based virtualization is a great option for microservices, developer operations, and continuous deployment.
Challenges of Using Containers
One of the main disadvantages of container-based virtualization compared to traditional VMs is security. Containers share the kernel and other components of the host OS. This means that containers are less isolated from each other than VMs, which have their own OS. If there is a vulnerability in the kernel, it can jeopardize the security of all containers. VMs only share the hypervisor, which makes them less prone to attacks than the shared kernels of containers.
While VMs with any kind of OS can reside next to each other on the same server, you must start a new server, to be able to run containers with different OSs. For complex enterprise applications, this can be a serious constraint.
In addition to that, deploying containers in a sufficiently isolated way while maintaining an adequate network connection can be tricky too. Also, containers, as they are designed, cannot see other containers by default. So, what happens when you want your container to work closely with another container? For example, what if your service requires access to a database server?
Some of these problems are addressed by Docker, which you will read about in the next chapter.
Summary
This chapter described the basics of containers, their use in the software industry, and how they differ from VMs. It also described the difference between running an application on a host machine vs. a VM vs. a container. It discussed the advantages and challenges of using containers.
This chapter has put you on a path along which you can start from scratch, if you’re new to the world of virtualization, by comparing the differences between all options available today and the reasons the software industry has moved toward containerization rather than other available options.