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?
This article was originally published on mkdev.me here: mkdev.me/en/posts/dockerless-part-1-which-tools-to-replace-docker-with-and-why
Not exactly. Industry tries its best to avoid the 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 the initiatives around standardization of container technology.
Since 2015 we have the Open Containers Initiative (OCI) and specifications for how to run containers and manage container images. In addition, we also have the Container Runtime Interface (CRI) and Container Network Interface(CNI). If you struggle to understand how all new container standards fit together, then watch the 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. For example, they might be concerned by certain security downsides of using Docker. Or they might not see any sense in an extra daemon running as root on every node of the cluster. Docker might have made container popularity explode, but it doesn't mean it's the best technology for working with them. If you are interested in the differences between 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 to 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 - though you are still free to install Docker from the Docker repositories.
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 its 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 for using Buildan and Podman, let me first clearly state the obvious and big disadvantages of using both Buildah and Podman when compared to Docker:
Currently only runs on Linux.
Unlike Docker, there is no convenient wrapper for Windows and MacOS. In the case of Windows this will be less of a problem with WSL 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 the last article of this series.
It's still very new and moves forward fast!
As 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.
If none of these two points apply however, you will hardly notice a difference after switching from Docker. But will you gain anything?
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 too - it gives 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 a 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 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 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!
Disclaimer: I do not attempt to re-write existing content on topics like containers and containerization standards. There are plenty of fantastic articles and videos out there and I link the ones I find most useful. If you don't understand some parts of the article, then follow all the links I have put in the text or get in touch directly via https://mkdev.me/en
A note from Cirtus Global: Kirill Shirinkin has been one of our deployed subcontractors and trusted collaborators for almost 2 years. He has been writing material for his own website since then and we would like to promote Kirill’s insight via our website. We hope you enjoy his content around “Dockerless”.
DO YOU HAVE QUESTIONS/ COMMENTS OR YOUR OWN QUALITY CONTENT TO SHARE?
We are interested in connecting high calibre DevOps professionals across our network so should you look for an introduction to any the writers showcased or if you'd like to submit your own content for our website, please get in touch.