Docker ?

There was a time when the docker was the only option, when you thought about making microservices and trying to break the monolithic and finally having a scalable and service-oriented architecture. however the world is changing and we have to keep up with trends and if possible to anticipate the next waves of innovation my idea in this article is precisely to evaluate alternatives to the docker.

Where not to use docker?

If you have been a docker user for a long time, I think it will take a while for you to consider switching to different tools. So, here it goes:

First, Docker is a monolithic tool. It is a tool that tries to do everything, which is generally not the best approach. Most of the time, it is better to choose a specialized tool that does just one thing, but that does it very well.

If you are afraid to switch to a different set of tools, because you would have to learn to work with a different CLI, different API or, in general, different concepts, then this will not be a problem. The choice of any of the tools shown in this article can be completely perfect, since all of them (including Docker) adhere to the same specification under OCI, which is the abbreviation for Open Container Initiative. This initiative contains specifications for the container runtime, container distribution and container images, which covers all the resources needed to work with containers.

You can choose a set of tools that best suits your needs and, at the same time, you can still use the same APIs and CLI commands as Docker.

So if you’re open to experimenting with new tools, let’s compare the advantages, disadvantages and features of Docker and its competitors to see if it really makes sense to even consider abandoning Docker

Container Engines Alternatives

When comparing Docker with any other tool, we need to divide it by its components and the first thing we should talk about is the container engines. Container engine is a tool that provides a user interface for working with images and containers so you don’t have to mess with things like SECCOMP rules or SELinux policies. Your job is also to extract images from remote repositories and expand them to your disk. Apparently, he also runs the containers, but in reality his job is to create the container manifest and directory with image layers. It then passes them on to the container runtime, such as runc or crun.

There are many container mechanisms available, but Docker’s most prominent competitor is Podman, developed by Red Hat. Unlike Docker, Podman does not need daemon to run and also does not need root privileges, which is an old concern of Docker. Based on the name, Podman can not only run containers, but also pods. If you are not familiar with the concept of pods, then pod is the smallest computing unit in Kubernetes. It consists of one or more containers — the main and the so-called side-cars — that perform support tasks. This makes it easier for Podman users to later migrate their workloads to Kubernetes.

Finally, Podman provides exactly the same CLI commands as Docker, so you can simply use the docker = podman alias and pretend that nothing has changed (nothing like being wrong, right).

There are other container engines in addition to Docker and Podman, but I would consider all of them to be dead end technology or not a suitable option for local development and use. But to have a complete view, let’s at least mention what’s out there:

• CRI-O — When you google what it is to create it, you can find it described as a container mechanism. However, it is actually the run time of the container. In addition to the fact that it is not really an engine, it is also not suitable for “normal” use. And by that I mean that it was created specifically to be used as a runtime for Kubernetes (CRI) and not for the end user.
• rkt — rkt (“rocket”) is a container engine developed by CoreOS. This project is actually quoted here just for completeness, because the project has ended and its development has been halted — and therefore should not be used.
• LXD — LXD is the container manager (daemon) for LXC (Linux Containers). This tool offers the ability to run system containers that provide a container environment more similar to VMs. It is in a very narrow space and doesn’t have many users, so unless you have a very specific use case, it’s best to use Docker or Podman.

Building Images

First, let me introduce Buildah. Buildah is another tool developed by Red Hat and works very well with Podman. If you’ve already installed Podman, you may have noticed the podman build subcommand, which is actually just Buildah in disguise, since its binary is included in Podman.

As for its resources, it follows the same path as Podman — it has no daemon or root and produces images compatible with OCI, so it is guaranteed that your images will be executed in the same way as those built with Docker. It is also capable of constructing images from the Dockerfile or (more appropriate name) Containerfile, which is the same thing with different names. In addition, Buildah also provides more precise control over image layers, allowing you to commit many changes to a single layer. An unexpected, but (in my opinion) nice difference from Docker is that the images built by Buildah are user-specific, so you can only list the images you have created.

The next is Google’s Kaniko. Kaniko also creates container images from the Dockerfile and, similar to Buildah, also does not need a daemon. Buildah’s main difference is that Kaniko is more focused on building images on Kubernetes.

Kaniko should be run as an image, using gcr.io/kaniko-project/executor, which makes sense for Kubernetes, but is not very convenient for local builds and kinda defeats the purpose, as you would need to use Docker to run the Kaniko image to build your images. That said, if you are looking for a tool to build images in your Kubernetes cluster (for example, in CI / CD pipeline), Kaniko can be a good option, considering that it has no daemon and (maybe) more

The third contender here is the buildkit, which can also be called the next generation docker build. It is part of the Moby project (just like Docker) and can be enabled with Docker as an experimental feature using DOCKER_BUILDKIT = 1 docker build … Well, but what exactly will this bring you? It introduces a lot of improvements and interesting features, including parallel building steps, skipping unused phases, better incremental builds and rootless builds. On the other hand, however, it still requires a daemon to run (buildkitd). So, if you don’t want to get rid of Docker, but want some interesting new features and improvements, using the buildkit may be the way to go.

As in the previous section, here we also have some “honorable mentions” that fulfill some very specific use cases and would not be one of my main choices:

There are also some alternatives for very specific cases.

• Jib is another tool from Google, specifically for building Java images. Includes Maven and Gradle plug-ins, which can make creating images easier without messing with Dockerfiles.
• Source-To-Image (S2I) is a toolkit for building images directly from source code without Dockerfile. This tool works well for simple and expected scenarios and workflows, but it quickly becomes annoying and awkward if you need a lot of customization or if your project doesn’t have the expected layout. You can consider using S2I if you are not yet very confident with Docker or if you build your images on the OpenShift cluster, as S2I builds are an integrated feature.
• This is not just for building container images, but a complete building system. If you just want to build an image, diving into Bazel can be a bit of a stretch, but definitely a good learning experience, so if you want, the rules_docker section is a good starting point for you.

Conclusion

the idea of ​​the article is not to say that you have to abandon the docker and migrate everything now, but rather to show that we already have some alternatives on the horizon and that sometimes in specific scenarios we can have better tools than the docker. I hope I showed you some tools that you didn’t know and let’s do a lab to test the alternatives, right!