Many think of Podman to be a replacement for Docker (if they have heard of Podman at all). But, this is not the case, as Podman is another option that provides better security and developer features. Podman is a cloud-native, daemonless tool that helps developers manage their Linux containers. Podman is all about security, but also minimizing the friction between your local development environment and production.
Podman uses a microservices approach, creating a network with many other cloud-native products, such as Buildah and Skopeo, to build and push containers. This makes Podman a lighter and faster application than Docker, allowing for customization and changes.
In this article, we will describe three advantages of Podman related to extensions and embedded tools integrated in the Podman Desktop, as well as the underlying technologies for the container engine:
- Podman makes creating pods easy.
- Podman's Kubeify feature lets you move from your container, pod, or volume to a Kubernetes pod with zero friction.
- Podman offers better tools and extensions, such as pulling images, security, and auditing features.
#1: Podman makes creating pods easy
Creating pods, or podify, is a feature that allows you to combine running containers to create pods. It is as simple as selecting the containers you need, clicking the pod symbol, and customizing the pod. You can choose the name, the ports you would like exposed, and more (Figure 1). The ease of creating pods is unmatched by any other container engine, whether CLI or GUI.
After your pod is created, you will see it in the container and pod section. Developers have access to a variety of details about the pod, just like for any Kubernetes cluster. First, you will be greeted with a summary and logs. In the inspect section, you can access all low-level information about your pod, including the infrastructure container ID, all container information, network and namespace options, and more.
#2: Podman's Kubeify feature
The most captivating feature of Podman Desktop is the Kubeify feature. Unlike other OCI container engines, there is zero friction moving from your container, pod, or volume to a Kubernetes pod. For any item, developers simply look under the Kube section, and they will be greeted with a Kubernetes manifest to make that item a Kubernetes pod (Figure 2). If you feel more comfortable with the CLI, the command podman generate kube <name of object> will also work.
Additionally, Podman Desktop takes Kubeify a step further than just generating Kubernetes manifests. Extensions allow developers to connect their Podman Desktop, and therefore all of their manifests, containers, pods, etc, to a cluster of their choice. It comes with three suggested extensions developers can use for a local or remote cluster: the Developer Sandbox for Red Hat OpenShift, Kind, and Red Hat OpenShift Local. Additionally, if developers have another local or remote cluster they prefer to use, they can input the image name and add it to their desktop. For more information about how to install Podman Desktop extensions, visit the Podman Desktop site.
After you have added your preferred local or remote Kubernetes cluster, select which service you would like to deploy and click Deploy to Kubernetes. It is as simple as creating your container/pod, selecting your preferred cluster, and clicking deploy.
#3: Better tools and extensions
Podman offers better tools and extensions, such as pulling images, security, and auditing features.
Pulling images
Evidently, Podman and Docker have to allow developers to pull an image, since both products are container engines. You can do this using the terminal.
Unlike Docker, you can pull an image while in the Podman Desktop application. Docker will force you to head to the terminal. While the switch is annoying and can disrupt the workflow, the real kicker is that when using the Docker free plan, there are limited pulls a day unless you pay to upgrade.
With a team of over 500 employees, Docker is able to provide a breadth to their platform for which Podman seems to be aiming. To a developer, the first feature that stands out in Docker is the variety of extensions they offer, totaling over 60. With suggested offerings from MongoDB, Live Charts, Grafana, and more, it is eye-grabbing. Having these features improves developers' experience and removes the friction of adding them. However, if a developer wants to add their own extensions in Docker, it is very tedious, even downright impossible.
While Podman Desktop is lacking in pre-loaded extensions, they allow developers to add their own extensions by inputting the name of the image for the extensions. Any extensions that Docker has can be added to Podman Desktop.
Docker Desktop continues to flex with dev environments and the learning center. Dev environments, currently in Beta, work to have a code editor integrating the web platform. Additionally, they provide many walkthroughs and samples adding to the experience and growth of developers.
Podman offers better security
While Podman Desktop and Docker Desktop are the user interfaces, the underlying engines have significant differences as well.
Podman has opted for a rootless model, meaning the container system is, by default, run by a non-root user. Even if a user inside the container is the root user, once they are outside of the container, they have as much access as a non-root. Podman opts to run containers with user namespaces and SELinux containers, so if a container is attacked, the attacker only has access to files in the container. They cannot mess with the host or other containers due to incorrect permissions.
While Docker has offered support for a rootless daemon since version 19, by default the Docker daemon runs as root user. Thus, if it is compromised, the attacker has instant access to the entire system. The rootful Docker daemon is a background process on the host, so it needs full access to the system. Since containers are run through the daemon, a malicious container could control the host.
Auditing features
Podman has emphasized the importance of security, opting for a fork/execute model, while Docker has a client/server approach.
All Docker commands trigger the Docker client to send a request to the Docker daemon (the server). The Docker daemon is a child of the init system, causing all systemd, daemon, and container processes to share the same login. If a user ID for the init system is unset, all other recorded processes will have an unset user ID, allowing anonymous use.
Podman runs as a process and when given a command, forks itself, and has the new replica execute the new command. Multiple users can run Podman with each process forked and run separately.
Since Podman runs from a process model, all individual processes and containers are recorded. All processes stem from a certain user, meaning Podman’s logs will record a user ID, allowing for more correct and secure auditing.
Switching to Podman is easy
Podman offers a variety of other developer tools that make building and pulling an image, playing Kubernetes YAML and pruning unused files a one-stop process. Podman and the desktop work together to ensure Podman is integrated into the Linux ecosystem.
Migrating from Docker to Podman has only gotten easier. Podman Desktop has extensions that allow for migration from Docker and Docker compose to the Podman ecosystem. While Podman may be viewed as similar to Docker, it has many developer, security, and Linux-based features that contribute to its advantage. Consider making the leap from Docker to Podman. With the ease of migration, the leap isn’t far.
