Exploring Container Technologies: Beyond Docker

When talking about container technologies, the name Docker soon comes up. Docker has played a huge role in the story of containers, but other technologies have since emerged. We’d be happy to give you some insight into the alternatives on the market. They might even offer added value for your project.

Containers are often lumped together with virtualisation, but there’s a fundamental difference. A container is not a virtual machine. Think of it instead as a process that is tricked into believing it’s in an optimal fake world. Let’s take a look at the different types.

Container technologies can be divided into application containers and system containers.
Application containers “containerise” a single process or application along with the required software dependencies and configuration files. These containers are always stateless. This means that no data remains stored in the container when it is restarted. To store data in application containers, you need to explicitly configure the container to save its data to persistent storage.

System containers, in turn, simulate a complete operating system. This allows this type of container to contain multiple processes and applications within a single container. You would therefore treat system containers more like virtual machines. However, they are still containers because they use the kernel of the operating system they run on. So they don’t have their own kernel like virtual machines do. System containers are stateful. This means that data generated by the container remains stored in the container and is therefore not lost when it reboots.

Application containers

The best-known container technology is, of course, Docker. Docker falls into the application container category. In fact, Docker laid the foundations for the use of application containers, which is why the name is so familiar to most application developers.

You create Docker containers using a Dockerfile. In the Dockerfile, you define the following configuration steps:

• the dependencies
• the application
• the required files

Dockerfiles can easily be shared with others. You can be sure that the environment you created with your Dockerfile will work elsewhere too. This is, of course, very powerful and demonstrates the potential added value of container technology.

Over the years, drop-in replacements for Docker have also emerged. They are primarily intended to address its shortcomings. Docker came first and is very robust, but technology evolves quickly, and some interesting alternatives soon appeared.

A well-known drop-in replacement is Podman. Podman does not run as a single daemon. To explain: if the Docker service crashes, all Docker containers will crash. This is not the case with Podman. An additional advantage is that Podman containers can also be started by non-root users. This is a major security advantage.

System containers

For system containers, the main technology people look to is LXC Containers. As mentioned, they simulate a complete virtual machine. They also use the host kernel, so they don’t have their own kernel. You can find an LXC container template for every well-known Linux distribution. This means you can use your favourite package manager (yum, apt, pacman,...) in an LXC container. Because they are stateful and behave like virtual machines, it’s best to use a configuration manager (Ansible, Puppet,..) to automate tasks. LXC has no equivalent of a Dockerfile.

Which type of container should you choose?

The choice is entirely yours, depending on which system administration style suits you best. If you have plenty of experience with virtual machines and Ansible, it’s easier to get the most out of LXC containers.

Would you rather build an application using a configuration file, with all the steps neatly automated? What’s more, you can easily share it and use Git source control with it. If so, an application container might be just what you’re looking for.

Want to know more? Contact us!