Ubuntu Server 18.04 – What is containerization?

How to manage remote IIS on Windows Server 2019

In the last chapter, we covered virtualization. Virtualization allows us to run multiple virtual┬áservers in one physical piece of hardware. We allocate CPU, RAM, and disk space to these VMs, and they run as if they were a real server. In fact, for all intents and purposes, a virtual machine is a real server. However, there are also weaknesses with VMs. Perhaps the most glaringly obvious is the resources you allocate to a VM, which are likely being wasted. For example, perhaps you’ve allocated 512 MB of RAM to a virtual machine. What if the application only rarely uses more than 100 MB of RAM? That means most of the time, 412 MB of RAM that could otherwise be used for a useful purpose is just sitting idle. The same can be said of CPU as well. Nowadays, virtual machine solutions do have ways of sharing unused resources, but effectively, resource efficiency is a natural weakness of the platform.

Containers, unlike virtual machines, are not actual servers. At least, not in the way you typically think about them. While virtual machines typically have a dedicated CPU, containers share the CPU with the host. VMs also generally have their own kernel, but containers share the kernel of the host. Containers are still segregated, though. Just like a virtual machine cannot access the host filesystem, a container can’t either (unless you explicitly set it up to do so). What is a container, then? It’s probably best to think of a container as a filesystem rather than a VM. The container itself contains a file structure that matches that of the distribution it’s based on. A container based on Ubuntu Server, for example, will have the same filesystem layout as a real Ubuntu Server installation on a VM or physical hardware. Imagine copying all the files and folders from an Ubuntu installation, putting it all in a single segregated directory, and having the binary contents of the filesystem executed as a program, without an actual operating system running. This would mean that a container would use only the resources it needed.

Portability is another strength of containerization. With a container, you can literally pass it around to various members of your development team, and then push the container into production when everyone agrees that it’s ready. The container itself will run exactly the same on each workstation, regardless of which operating system the workstation uses. To be fair, you can export and import virtual machines on any number of hosts, but containers make this process extremely easy. In fact, portability is at the core of the design of this technology.

The concept of containerization is not necessarily new. When Docker hit the scene, it took the IT world by storm, but it was by no means the first solution to offer containerization. (LXC, and other technologies, predate it). It was, however, a clever marketing tactic with a cool-sounding brand that launched containerization into mainstream popularity. By no means am I saying that Docker is all hype, though. It’s a huge technology and has many benefits. It’s definitely worth using, and you may even find yourself preferring it to virtual machines.

The main difference with containerization is that each container generally does one thing. For example, perhaps a container holds a hosted website, or contains a single application. Virtual machines are often created to do many tasks, such as a web server that hosts ten websites. Containers on the other hand are generally used for one task each, though depending on the implementation you may see others going against this norm.

When should you use containers? I recommend you consider containers any time you’re running a web app or some sort of service, and you’d benefit from sharing resources instead of dedicating memory or CPU. The truth is, not all applications will run well in a container, but it’s at least something to consider. Any time you’re running a web application (Jenkins, and so on) it’s probably better off in a container rather than a VM. As an administrator, you’ll most likely experiment with the different tools available to you and decide the best tool for the job based on your findings.

Comments are closed.