As Docker is struggling because of security concerns and the debate about whether the Docker daemon is needed or not (what in my opinion is in most cases not), the alternative tools emerged over the last years. This is a short post about my latest experiences with Podman and Buildah.
As there may be a need to control the container environment via a service like the Docker daemon (e.g. for the framework Localstack), in most cases this is unneeded overhead and a security risk. Therefore, I chose to only use Podman and Buildah if there is not need for Docker itself.
It was also found that all major Linux distribution have it available.
The only drawback is the missing integration into Windows, but this was also not very cleanly done with Docker and the usage of either a Virtual Box VM or a Hyper-V VM in order to run the Docker daemon in a Linux environment with only a command line tool for Windows to interact with it. Maybe, this is solve with the further evolution of the Windows Subsystem for Linux.
Podman
Podman is working in the same way like Docker. Even the command line parameters compatible. Therefore, it is also possible to use Podman as docker replacement (https://podman.io/whatis.html):
alias docker=podman
When creating a new container image, the known Dockerfile files can be used, but they can also be renamed to Containerfile, what is more clean in order to indicate the absence of Docker. The syntax inside the Containerfile is the same for Dockerfile, so the documentation can be re-used: https://docs.docker.com/engine/reference/builder.
But, the most important point is: The container images build with Podman can be used with Docker and vice-versa! This is assured as the container images are build according to the Open Container Initiative Image Format Specification.
As I do not want to give a complete introduction to containers, that’s all there is to say for now. For an introduction for containers, have a look to:
- https://www.docker.com/resources/what-container/
- https://opencontainers.org/
- ask Uncle Google, Aunt Bing or anyone else you like…
But, Podman can do more…
systemd integration
Podman can help to create a needed systemd configuration file in order to start a container as system service (https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html)
I used this already and it works like a charm. Package your application into a container, create the systemd configuration, and deploy it to the system.
A complete example can be found here: https://www.redhat.com/sysadmin/podman-run-pods-systemd-services
Pods with Podman
I did not use it myself, yet, but Podman can combine multiple containers into pods (similar to Docker compose): https://docs.podman.io/en/latest/markdown/podman-pod.1.html.
An example is here: https://developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods#create_a_pod
This might be very helpful to orchestrate different containers which have dependencies to each other.
Buildah
Buildah is called behind the scenes when $ podman build ... is called (Buildah also calls Podman to help when Buildah is asked to run a container image). But, Buildah itself brings some new cool functionality: It can be used to script containers. I did not use it so far, as the approach with the definition inside a Containerfile was fine for me and the scripting introduces some more complexity, but for some sophisticated use-cases this may be very handy.
A simple introduction can be found here: https://buildah.io/blogs/2017/11/02/getting-started-with-buildah.html.
A more detailed and complex example is here: https://www.redhat.com/sysadmin/building-buildah
Conclusion
In my opinion, there is no easier way to handle containers right now than using Podman and Buildah. The installation of these tools is easy by using the system packages, there is no dedicated system service needed like the Docker daemon, and the tools can be run by any user.
As the Docker daemon is not explicitly needed to interact with the container infrastructure, use Buildah and Podman.