Ubuntu Server 18.04 – Understanding the differences between Docker and LXD

Initial Server Setup with CentOS 8

In this chapter, we’re going to explore both Docker and LXD and see examples of containers running in both. Before we start working on that though, it’s a good idea to understand some of the things that set each solution apart from the other.

Docker is probably the technology most of my readers have heard of. You can’t visit a single IT conference nowadays without at least hearing about it. Docker is everywhere, and it runs on pretty much any platform. There’s lots of documentation available for Docker, and various resources you can utilize to deploy it. Docker utilizes a layered¬†approach to containerization. Every change you make to the container creates a new layer, and these layers can form the base of other containers, thus saving disk space.

LXD (pronounced Lex-D) finds its roots in LXC, so it’s important to understand that first before we talk about LXD. LXC is short for Linux Containers (pronounced Lex-C) and is another implementation of containerization, very similar to Docker. This technology uses the control groups (cgroups) feature of the Linux kernel, which isolates processes and is able to segregate them from one another. This enhances security, as processes should not be able to read data from other processes unless there’s a good reason to. LXC takes the concept of segregation even further, by creating an implementation of virtualization based solely on running applications in an isolated environment that matches the environment of an operating system. You can run LXC containers on just about every distribution of Linux available today.

LXD is, at least, in part, specific to Ubuntu. That’s not completely true these days, as the technology has been made to work on other platforms, too. This is due to the fact that the LXD software is distributed via snap packages, so any distribution of Linux that is able to install snap packages should be able to install LXD. Created initially by Canonical (the company behind Ubuntu itself) LXD enhances LXC, and gives it additional features that it otherwise wouldn’t have, such as snapshots, ZFS support, and migration. LXD doesn’t replace LXC; it actually utilizes it to provide its base technology (you even utilize the lxc command to manage it). Perhaps the best way to think of LXD is LXC with an additional management layer on top, that adds additional features.

How does LXD/LXC differ from Docker? The main difference is that while they are both container solutions and solve the same goal in a very similar way, LXD is more similar to an actual virtual machine while Docker tries harder to differentiate itself from that. By comparison, Docker containers are transactional (every task is run in a separate layer) and you generally have an ENTRYPOINT command that is run inside the container. Essentially, LXC has a filesystem that you can directly access from the host operating system, and has a simpler approach to containerization. You can think of LXC as a form of machine container that closely emulates a virtual machine, and a Docker as an application container that provides the foundation needed to run an application. Regardless of these differences, both technologies can be used the same way and provide support for identical use cases.

When should you use Docker and when should you use LXD? I actually recommend you practice both, since they’re not overly difficult to learn. We will go over the basics of these technologies in this chapter. But to answer the question at hand, there are a few use cases where one technology may make more sense than the other. Docker is more of a general-purpose tool. You can run Docker containers on Linux, macOS, and even Windows. It’s a good choice if you want to create a container that runs everywhere. LXD is generally best for Linux environments, though Docker runs great in Linux too. The operating system you’re running your container solution on is of little importance nowadays, since most people use a container service to run containers rather than an actual server that you manage yourself. In the future, if you get heavy into containerization, you may find yourself forgoing the operating system altogether and just running them in a service such as Amazon’s Elastic Container Service (ECS).

Another benefit of Docker is the Docker Hub, which you can use to download containers others have made or even upload your own for others to use. The benefit here is that if someone has already solved the goal you’re trying to achieve, you can benefit from their work rather than starting from scratch, and they can also benefit from your work as well. This saves time, and is often better than creating a solution by hand. However, always make sure to audit third-party resources before you put them to use in your organization.

Comments are closed.