How to Revolutionize Container Management with Podman

Introduction

Podman is an OCI-compliant container management solution that provides container management functionalities comparable to Docker.

One of Podman’s best advantages is its ability to run rootless containers. A rootless container is a container that runs and manages without root capabilities (normal user). Rootless containers provide additional protection by not enabling root access even if an attacker exploits the container.

Podman is also daemonless (unlike Docker), which means it does not have a daemon and communicates directly with the runc (which executes containers according to the OCI specification). Also, suppose there are two Linux users. User-a and User-b are two different people. User-a’s podman-created containers cannot be edited by user-b, and vice versa.

Running containers in Pods is another intriguing and complex feature of podman. Podman, like Kubernetes pods, allows you to create multi-container pods locally. You may export the podman Pod as a Kubernetes manifest and deploy it using a Kubernetes pod manifest.

Benefits of Podman

Containerization has transformed software development and deployment, and Podman stands out among the several technologies available. Unlike its predecessor, Docker, Podman takes a unique approach, providing many benefits that redefine container management.

1. Security Reigns Supreme

The design of Podman is centered on security. The ability to run rootless containers, which eliminates the requirement for root capabilities, is a huge advancement in security. Even in a compromised circumstance, blocking root access strengthens the container ecosystem and reduces possible threats.

2. Daemonless Flexibility

Podman’s design differs significantly from Docker’s in that it is daemonless. The lack of a central daemon minimizes complications and potential vulnerabilities while allowing direct contact with the kernel via runc integration. This streamlined procedure improves performance and allows for more effective container management.

3. Supporting Pod Concept

Podman’s support for pods, which mirrors Kubernetes’ pod structure, is one of its notable features. This process enables the grouping of several containers into a unit, allowing for coherent management and better networking capabilities on a local level.

4. Effortless Compatibility

Podman does not just portray itself as a separate entity; it also supports Docker’s ecosystem admirably. Podman’s instructions and features are identical to Docker’s, allowing for an easy transfer for Docker users.

5. Rootless Containers: A Security Breakthrough

The notion of rootless containers in Podman assures that users can create and manage containers safely, even without elevated rights. This strategy decreases the attack surface dramatically, making Podman a good choice for security-conscious developers and operators.

6. Portability and Consistency

The ability to run containers consistently across diverse environments and platforms is a significant benefit of Podman. Podman supports seamless container execution in development, testing, and production environments, supporting portability and consistency in deployment pipelines.

7. Community-Driven Innovation

Podman is constantly evolving, thanks to an active and robust open-source community. Podman remains at the forefront of containerization innovation, addressing user needs and industry expectations through regular updates, bug fixes, and new features.

8. Ecosystem and Compatibility

Aside from its inherent functionalities, Podman interfaces seamlessly with a variety of tools and frameworks. It is compatible and adaptable within complicated infrastructure environments since it is compatible with other container-focused technologies and platforms.

Podman Pods

Kubernetes pioneered the Pod idea. Podman pods are comparable to Kubernetes pods.

Every Podman pod comes with an “infra” container. This container does nothing but rest. Its function is to store the namespaces connected to the Pod and to allow podman to connect with the Pod from other containers. This allows the start and stop containers within the POD while the Pod continues to run, which would not be feasible if the primary container controlled the Pod. Unless you specify differently, all pods will use the default image based on the k8s.gcr.io/pause image.

Most Pod’s properties are assigned to the “infra” container. The “infra” container is responsible for port bindings, cgroup-parent values, and kernel namespaces. This process is crucial because these attributes are allocated to the “infra” container once the Pod is built and cannot be modified. For example, if you construct a pod and then wish to add a container that connects new ports, Podman will be unable to do so. Before adding the new container, you must regenerate the Pod with the additional port bindings.

Notice the box above each container in the diagram above; this is the container monitor. It is a little C program whose task is to monitor the container’s primary process and preserve the exit code if the container dies. It also keeps the container’s tty open to be hooked up later. This process enables the podman to run in detached mode (background), allowing the podman to depart while the conmon continues to run. Each container has its common instance.

Podman Setup

Go to the official podman installation guide. Installation commands for Windows, MAC, and Linux are also available here.

Podman Container Registries

Podman comes with two container registries by default.

• io
• io

The following file contains the default Podman container registry setup.
/etc/containers/registries.conf

• Custom or private container registries can be added to this setup. Self-hosted private registries, AWS ECR, Google Container Registry, and so on.
• If you want to use other private container images from the registries, use the podman command to log in to the registry.
• For instance, to access the Docker Hub,

podman login docker.io

• Once logged in, you can use the podman command to retrieve container images from the Docker Hub.
• You can create registries if you want to have a different registry configuration for each user. Conf files in the user directory contain the container registry information.

$HOME/.config/containers/registries.conf

Container Storage: Podman

Each user of the system has a container storage. If you try to retrieve photos from multiple user logins, the image is pulled from the remote registry rather than the local image.

As an example,

• The containers are stored in the /var/lib/containers/storage directory for root users.
• The containers are saved in the $HOME/.local/share/containers/storage/ directory for other users.

Podman Container Management

To manage containers, you can use the Podman command, which any user can use without sudo privileges.

Let us start by attempting to pull an image. By default, podman looks for images first in quay.io and then in docker.io. If an image is not found in quay.io, podman seeks docker.io and retrieves it. As a result, it is preferable to supply the whole picture name rather than the registry URL. As an example,

podman pull docker.io/nginx

podman pull quay.io/quay/busybox
Let us use the docker hub registry to launch a Nginx container. The following command starts the Nginx container with a host port mapping 8080.

podman run --name docker-nginx -p 8080:80 docker.io/nginx

Note: Ports fewer than 1024 cannot be used in rootless (normal user mode). Because the regular user container namespace can map those ports. If you want to use podman to map host ports less than 1024, execute it as the root user or with sudo capabilities, as described below.

sudo podman run --name docker-nginx -p 80:80 docker.io/nginx

The mapped port can be checked with the following command. -l flat gives information about the most recent container.

podman port -l

The inspect command can be used to inspect the container.

podman inspect -l

To learn about all the various podman commands, use the help command.

podman –help

Making a Pod with Podman

In this module, we will learn to use Podman to create a pod. Podman’s capacity to construct pods similar to Kubernetes pods is one of its advanced capabilities. A pod is a container-holding unit that can hold one or more containers.

What you can do is as follows:

• An infra container k8s.gcr.io/pause holds the namespace and allows communication with other containers in the Pod when you create an empty pod.
• Containers in a pod can be added and removed.
• A pod can contain a whole application stack.
• Within a pod, you can choose start and stop containers.

Create an Empty Pod

First, create an empty pod. If the –name flag is not mentioned, podman will create a pod with a random name.

podman pod create --name demo-pod

Let’s list the created Pod.

podman pod ls

Add containers to Podman Pod

Let us add a Nginx container to the empty Pod. If you list the containers after running the following command, you will see the Nginx container added to the demo pod

podman run -dt --pod demo-pod  nginx

Start, Stop, and Remove containers inside Podman Pod

The same commands used to remove containers with their IDs can be used to start, stop, and delete containers from the podman Pod.
podman start <continer-id>

podman stop <continer-id>

podman rm <continer-id>

Create Pod with Containers

With a single command, we can create a pod and add containers. Make a pod with a Nginx container and 8080 host port mapping. podman run -dt --Pod new:frontend -p 8080:80 nginxYou should be able to see the Nginx homepage if you access port 8080 on the VM’s IP.

Start, Stop, and Delete Pod

Individual containers within the Pod can be selected and stopped using the container id/name, or all containers can be stopped simultaneously with the following command.  podman pod stop <podman>
podman pod start <podman>

To delete a pod, first, stop all of its containers and then run,

podman pod rm  Alternatively, you can use the -f flag to aggressively delete the Pod without halting the containers.podman pod rm -f

Podman vs Docker

Docker

• A central daemon (containerd) is used to manage containers.
• Initially, only limited support for rootless containers was provided.
• Individual containers are managed rather than pods or multi-container systems.
• Controls all container child processes via its daemon, thereby increasing the attack surface.
• With a huge archive of container images and established industry support, it remains a major force in containerization.

Podman

• It works without a central daemon, connecting directly with container runtime tools like runc.
• Supports rootless containers, which allow container execution without root capabilities.
• Allows for the construction and management of pods, similar to Kubernetes pods, allowing for the use of numerous containers within a single unit.
• Through runc, it interacts directly with the Linux kernel, supporting increased security protections.
• Provides Docker command and container image compatibility while delivering a similar user experience without requiring a central daemon.

Podman vs Buildah

Docker

• Without a daemon, it manages running containers, including pods.
• Rootless containers are supported, allowing execution without root rights.
• Allows for the development and management of pods, allowing several containers to be housed in a single unit.
• Through runc, it interacts directly with the Linux kernel, facilitating efficient container administration.
• Focuses on container development and execution, providing a comprehensive container management experience.

Buildah

• Rather than executing containers, it primarily focuses on constructing (making) container images.
• Only handles the generation of container images and cannot directly manage or execute containers.
• It lacks native support for pods and multi-container units, instead focusing on container image construction.
• Builds container images using the host’s container runtime.
• Emphasizes container image creation, which provides a foundation for containerized programs without directly managing their execution at runtime.

Conclusion

Podman continues to push the boundaries of the container landscape. Because of its emphasis on security, usability, and interoperability, it is a vital tool in the containerization environment, pioneering improvements in the industry.

Finally, Podman’s novel method, which emphasizes security, flexibility, and compatibility, represents a substantial shift in container management paradigms. Podman not only answers current challenges but also determines the future of containerization with its rootless containers, daemonless architecture, and pod support.

Utilise Podman’s abilities to streamline container operations, strengthen security measures, and traverse the ever-changing terrain of modern software deployment. Its ability to balance simplicity, robustness, and compatibility puts it at the forefront of container orchestration.

About CloudThat

CloudThat is an official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner, AWS Migration Partner, AWS Data and Analytics Partner, AWS DevOps Competency Partner, Amazon QuickSight Service Delivery Partner, AWS EKS Service Delivery Partner, and Microsoft Gold Partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best-in-industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

To get started, go through our Consultancy page and Managed Services Package, CloudThat’s offerings