Podman: all you need to know about Dockerless Docker
In the ever-fast-moving container world there is a silent revolution going on that goes by the name of Dockerless Docker. Docker brought containers into mainstream, however what is the difference between a Docker and a container? Most people would answer none. In the frontline of this revolution is Podman, let’s take a dive.
Containers, Docker images, Daemons and more
Before you start reading I assume you know what a container is, what Docker is, and even better what Moby is, although not required. If you’re unsure you can read this: Container jungle: where do I start?
If you’ve worked with Docker, you surely know what the Docker Daemon is: a daemon sitting on the machine that enables all the goodies Docker provides. But is it really needed? Meet Podman, a daemon-less approach that brings Docker containers up in a Docker-less environment.
Podman is as simple as it sounds: a drop-in replacement for Docker, however keep in mind it is under heavy development. The only major difference between Docker and Podman is the absence of the daemon, this eliminates the overhead required to run the daemon.
Now it is important to understand that both Docker and Podman can run containers, but their images are different. In the next paragraphs you will see that you can reuse existing Dockerfile but you can’t reuse existing Docker images, although that seems overly-complicated it really isn’t.
What do I need to get started? Can I replace Docker with Podman? What about Dockerfiles?
If you want to try Podman, you simply need to install it on your operating system. In the previous paragraph you learned that Podman is a drop-in replacement for Docker. Here comes the best part: all the commands you learnt form Docker are mostly the same! Go ahead and try if you don’t believe me!
What about existing Dockerfiles? Do you need to rebuild them? No! Podman can build containers through Buildah (more in a while) reusing existing Dockerfiles.
There is one thing that’s different between plain Docker and Podman, and you might’ve guessed it: Pods.
Pod: more than just containers…
Pods are the most prominent feature in Podman that doesn’t exist in Docker. In Podman, before spawning containers you must spawn a Pod. A Pod is an aggregation of containers that shares the same namespace. Containers belonging to a Pod may for example interact with one another through networking. The concept is pretty close to Kubernetes Pods, but Podman Pods are not Kubernetes Pod. That said they share a lot and with a simple command you may also generate a Kubernetes-compatible pod definition starting from a Podman Pod.
Podman and Buildah
When you ask Podman to build containers, in turn it asks Buildah. Buildah helps you build OCI-compliant images that will work on Podman. Buildah doesn’t need access to the daemon (that’s just not there) to build its images. While Podman containers require Podman images, just like Docker containers require Docker images, you can’t just mix and match them. What you can do however is build images for both using the same Dockerfile.
You might be perplexed to know that there also exist Buildah containers! It’s nothing you should worry about, just know that you can’t use Buildah containers the same way as Podman containers, however when a Buildah container is committed into an image, it can now be used by Podman too.
Podman, Kubernetes and CRI-O
I assume you know what Kubernetes and CRI, CRI-O are. Now you might think that Podman is an interface that talks to CRI-O, but that is not entirely correct. Firstly Podman doesn’t communicate with CRI-O, instead it uses the same backstores. As stated earlier Podmand Pods != Kubernetes Pods. In the end it all comes down to use cases and Podman is meant to be a Docker replacement, rather than a Kubernetes one.
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments