Over the last decade, containers have become an essential part of running infrastructure more efficiently. Containers enable productivity, automation, and cost-effective deployments. But there are different types of containers to consider, and this blog explains what Linux containers are, and how they differ from application containers.
Photo by Guillaume Bolduc on Unsplash
Application vs system containers
Application containers (such as Docker) are containers running a single process per container. They run stateless types of workloads so that you can ramp up and down as needed – create new containers and delete them at any time. Usually, you don’t need to care about the lifecycle of those containers, as they are meant to be ephemeral.
The other type of containers, system containers, are much closer to a virtual or a physical machine. They run a full operating system inside them, and you manage them exactly as you would a virtual or a physical machine. That means you can install packages inside them, you can manage services, define backup policies, monitoring, and all other aspects as you usually would with a virtual machine. These containers are usually very long-lasting. If you need to update them, you can do so with the normal tooling of the Linux distribution you are using. It also means that you will get normal security updates from distributions for those containers, so you wouldn’t need to wait for any image to be published to get the security fixes.
A walk down the memory lane
System containers are technically the oldest type of containers. It all started in 1999, when BSD introduced jails, a way of running a second BSD system on the same kernel as the main system. That was followed shortly after with a Linux implementation of the concept through Linux vServer. This was a separate project with a big patch set towards Linux kernel aimed at implementing a functionality similar to BSD jails. Soon after, Solaris grew Zones which was the same concept but a part of Solaris OS. OpenVZ project followed, and started to implement multiple VPSs (virtual private servers) on Linux. All of these projects provided system containers that run a full Linux operating system. Both Linux vServer and OpenVZ were not mainline and were pretty big patch sets on top of a Linux kernel. To enable these containers, you needed to install a specific patch set on a specific distribution, and then use additional tools to append containers.
Linux containers, also known as LXC, was the first implementation of system containers that was entirely based on mainline Linux features. This means that you could take a completely clean upstream kernel, or the kernel as distributed by any Linux distribution, and use that to create containers on Linux. LXC itself is a low-level tool that can create both system containers and application containers. Docker was initially based on LXC, which was later replaced by implementing their own runtime.
LXC containers are often considered as something in the middle between a chroot and a full-fledged virtual machine. The goal of LXC is to create an environment as close as possible to a standard Linux installation but without the need for a separate kernel. LXC containers are essentially a copy of an operating system running on the same kernel as its host, so in this case, you don’t virtualise anything, and there are no overhead processes. As far as the kernel is concerned, all processes running in containers are just normal processes on the system, they just happen to have a slightly different view of the operating system.
When should you use Linux containers?
Anytime when you’re running Linux on Linux, you should be considering using containers instead of virtual machines. There’s not much that virtual machines can do that Linux containers cannot. For almost any use case, you could run the exact same workload in a system container and not get any of the overhead that you usually get when using virtual machines. The only exception would be if you needed a specific version of the kernel different from the kernel of the host, for a specific feature of that virtual machine.
System containers are much easier to manage than virtual machines. You see everything that they’re doing directly from the host system and you see all the processes running in them. You can also easily share your file system directly or share specific files, and you can restrict their resource consumption or increase it without having to restart anything. You can pass any device that you have on your host into the container or remove it anytime you want without needing specific hardware, firmware, drivers, or anything else to achieve that. This makes Linux containers an ideal option for both development and production environments, replacing your usual physical or virtual machines.
What is LXD?
LXD is a system container and a virtual machine manager that runs on top of LXC, enhancing the experience and enabling easier control and maintenance. LXD is image-based and provides images for a wide number of different Linux distributions. A simple command-line tool enables you to easily manage your instances, and it is easy to integrate it with third-party orchestration and management tools. LXD can run clusters, it provides support for different storage backends and network types and scales easily from one instance on your laptop to a full rack in a data center.
LXC vs LXD
|– Linux container runtime allowing creation of multiple isolated Linux systems (containers) on a control host using a single Linux kernel
– Only supports containers
– Low-level tool requiring expertise
|– System container and virtual machine manager built on top of LXC, enabling easier management, control and integration
– Supports container and VMs
– Better user experience through a simple REST API
Linux containers are system containers that are similar to virtual machines in their behavior and manageability, without the usual VM overhead, and with the density and efficiency of containers. They are suitable for running all types of workloads. With LXD, you can easily run and manage Linux containers, and scale it to suit your needs. For learning more about LXC and LXD visit the community website. And in case you would like to try and test LXD without needing to install it on your machine you can do that with the LXD online demo tool.