Dockerless, part 1: Which tools to replace Docker with and why

Series "Dockerless"

1. Dockerless, part 1: Which tools to replace Docker with and why
2. Dockerless, part 2: How to build container image for Rails application without Docker and Dockerfile
3. Dockerless, part 3: Moving development environment to containers with Podman
4. The tool that really runs your containers: deep dive into runc and OCI specifications 

Dockerless, part 1: Which tools to replace Docker with and why 

Why Dockerless?

The title of this series - "Dockerless" - requires an explanation. Why would you not use Docker? Why would you use Docker? Are there really no alternatives to it? Did we -- the IT-community -- came up with the perfect solution for containers from the first attempt, right back in 2013?

Not exactly. Industry tries its best to avoid situation we have with virtualization technologies, where, despite having fantastic tools like libvirt, we still don't have a single set of standards that every virtualization provider would follow. And we should give credit to Docker as a company for actually starting or actively supporting many of initiatives around standardization of container technology.

Since 2015 we have Open Containers Initiative (OCI) and specifications for how to run containers and manage container images. In addition, we also have Container Runtime Interface (CRI) and Container Network Interface(CNI). If you struggle to understand how all new container standards fit together, then watch Understanding Container Standards talk by Scott McCarty, where he even demos swapping one container engine with another without any loss of functionality.

If you can just replace Docker Daemon with CRI-O (or any other engine) in your Kubernetes cluster and, as a developer, never notice a difference, then does it matter which engine is actually running there? Just like containers made you care less about what is running on the host server, container standards make you care less about what is managing the container itself. Do you, after all, care if AWS EC2 is running on Xen or KVM? You just need a virtual machine. Or a container.

Engineers behind your Kubernetes cluster who need to maintain, extend and upgrade this cluster, do care for sure. They might be concerned by certain security downsides of using Docker, as one example. They might not see any sense in an extra daemon running as root on every node of the cluster, as another example. Docker might have made containers popularity explode, but it doesn't mean it's the best technology for working with them. If you are interested in differences in various container engines, take a look at this comparison as a starting point: Kubernetes Container Runtimes.

If, as a developer, you start relying on standards and on a number of companies not to screw developing and supporting of these standards up, then you are free to choose your tools for local development. If all of your tools are working with the same API in the end, then you don't have a lock-in into a specific tool. So the answer to the question "Why not Docker?" is "Because we don't have to use Docker anymore". What will we use instead of it then?

 

Buildah and Podman

We will use Buildah for managing container images and Podman for managing containers. Both tools are developed by RedHat and there are packages available for most of the RedHat-based Linux distributions. Even more, starting from RedHat Enterprise Linux 8 there will be no Docker package available out of the box. You are still free to install Docker from the Docker repositories, though.

Note when I say "developed by RedHat" I don't mean these tools are developed only by RedHat. Buildah and Podman are Open Source projects, with source code hosted on Github in Containers organization. RedHat pays it's employees to work on these tools and there is also a larger community of developers who maintain and extend both projects.

 

Huge downsides of using Buildah and Podman

Before we proceed to reasons why to use Buildan and Podman, let me first clearly state the obvious and big disadvantages of using both Buildah and Podman when compared to Docker:

1. It currently only runs on Linux. There is no convenient wrapper for Windows and MacOS, like Docker has. In case of Windows it will be less of a problem with WSL 2.
2. There is no Docker Compose replacement for Podman. There is a way to just run Kubernetes-compliant Pod YAMLs locally, but it's not mature yet. That might also change though. We will look at Pod YAMLs in last article of the series.
3. It's still very new and moves forward fast!

If you are a Windows or MacOS user, you will definitely miss the comfort of Docker client tools, as you probably have to run Buildah and Podman inside a Linux VM that you spin up manually.

If you have a very sophisticated Docker Compose setup (or you even deploy to production with the help of Docker Compose), you won't get a replacement with the new set of tools.

But if none of these two points apply, you will hardly notice a difference after switching from Docker. But will you gain anything in return?

Reasons to switch to Buildah and Podman from Docker

To see that there is an alternative to Docker

When you start using a new set of tools for managing containers, you quickly realize that Docker is just another tool. You will see that there are no "Docker Containers", there are just "Containers", and that there are no "Docker Images", there are only "Container Images". It's important to be able to think about base technologies and principles and avoid locking your thinking into one single technology.

Just like a good programmer realizes that his favorite language is just one of many programming languages, we should realize that Docker is just one way to interact with containers. Knowing and trying out the alternatives is important, it gives you a different perspective and diversifies your knowledge.

To realize what containers really are

Once you stop thinking "Docker" and start thinking "Containers", you inevitably learn what containers really are and gain deeper knowledge of what's happening behind commands like "docker run" or "podman exec". If you are a web developer, then this knowledge might not be something that helps you with your daily job. It's up to you if you want to dig deeper into certain aspects of how things work. My personal opinion is that understanding how everything works and fits together is an important skill for every engineer.

To prepare for the future

While you are trying to replace "Docker" with "Containers" in your brain, the industry does the same. As mentioned before, CRI-O moves forward to being a default runtime for Kubernetes and different companies promote different set of tools for working with containers. RedHat pushes for Buildah, while Google promotes Kaniko and there are always less known tools out there that might at some point become mainstream.

You can make a big bet on Docker and use only that. Or you can learn what is happening in the industry and be prepared for the times when Docker stops being a default and is replaced by next generation tools for container technology.

One word about lower level tools

You could go one level beyond Podman and use runc directly. That would be even more fun and rewarding in terms of learning the container technology. It would also result in a reduced productivity when you actually want to containerize your application and run it locally. Podman aims to be a user-friendly CLI, a complete replacement for Docker CLI, so it makes a bit more sense to use Podman when you actually want to get the job done. Ping me in comments if you want to see an article on using just runc and other low level tools for working with containers!

Road ahead

In the next article we will learn how to use Buildah for building container image for Ruby on Rails application. We will also see what container image really is and take a look at OCI image-spec. In the final article we will use Podman to completely automate development environment in a Docker Compose-like manner.

We are not going to use some artificial examples here. mkdev.me core web application with all supporting services was moved to containers in local development environment with the help of Buildah and Podman. mkdev.me is a good case for this exercise: we have a medium-sized Ruby on Rails application, that uses PostgreSQL database as primary storage, and Redis for cache and background jobs. We also have Mattermost as the core of our messaging platform, which requires it's own database. It's not as boring and straightforward as just a web app and a database and not as complex as a microservices setup with a dozen of applications.