We can install Podman on your system by following the steps in Podman Installation Instructions. Podman also provides a graphical interface for managing containers, images, and other resources called Podman Desktop.

Accessing Container Images

To create a container first, we have to download its image from a registry. A container image is a file that contains all the dependencies and executable code for the container.

Images could be fetched from container registries such as DockerHub or Quay.io.

Login to Container Image Registry

A container image registry is a service that handles the storage and distribution of container images. It is necessary to log in to the container registry to access private images.

podman login docker.io

After executing this command a prompt will ask for your username and password, for that we need to have a container registry account. Images used in this article are public so we don’t need to create an account or log in.

Once login is successful, Podman stores the encrypted user information in file ${XDG_RUNTIME_DIR}/containers/auth.json. XDG_RUNTIME_DIR is an environment variable set by systemd that stores the path of the directory containing user-specific runtime files.

Pulling Container Images

Pulling container images from registries

Public registries provide an interface for searching images or Podman’s subcommand search could also be used.

podman search httpd

Once we have the image name we can pull it on our machine using the pull subcommand

podman pull docker.io/library/httpd 

or using the Podman Desktop app you can go to Images -> Pull an Image.

Pulling container image using Podman Desktop

Different versions/variations of container images are managed by Tags. The image tag latest is pulled by default. You can view the list of available tags on the registry’s webpage or use skopeo list-tags. Skopeo requires the transport (docker in our case) to be mentioned explicitly with the image name.

skopeo list-tags docker://docker.io/library/httpd

Managing Container Lifecycle

Once we have access to the container image we can easily create one or more containers.

Creating a Container

Creating a container from the container image

We use the run subcommand for creating containers. If the image specified in the command is not present in the system then Podman will attempt to pull it from the registry.

podman run --name httpd-test docker.io/library/httpd

After executing this command a container named httpd-test will be created on your system and its output will be attached to your terminal. To exit you can use the shortcut Ctrl+C. To run the container in the background --detach flag could be used.

podman ps command will list running containers on the system.

On Podman Desktop, the Containers section provides utilities for managing the state of containers.

Creating container using Podman Desktop

Executing Commands inside a Container

To run a container and access its shell we have to use options --interactive & --tty.

--interactive will allow us to provide inputs to the process running inside the container and --tty will attach a pseudo-terminal to the container.

Entrypoint specifies a command that is executed during container initialization. It could be defined by default in the image, but you can override it with the --entrypoint flag.

podman run -it --name httpd-test \
               --entrypoint="/bin/bash" \
               docker.io/library/httpd

To execute a command or script inside the container we use Podman’s exec subcommand.

podman exec httpd-test echo "Hello, world"

Attaching Volumes

Directories from the host could be mounted on a container. It is useful when scripts are edited outside the container (an IDE/Code Editor on the host) or the files have to be shared between multiple containers.

To mount a directory from host to container flag --volume could be used with run subcommand and values are passed as <HOSTDIR>:<CONTAINERDIR>.

podman run -it --name python-test --detach \
               --entrypoint="/bin/bash" \
               --volume $(pwd):/app:Z \
               docker.io/library/python:3.10.6-slim-bullseye

This command starts a python container with contents of the present working directory (fetched from the pwd command) mounted on the /app directory inside the container. Both directory paths have to be absolute.

Before mounting the host directory we have to change its SELinux context to container_file_t otherwise we could encounter permission issues while accessing directory contents. To change the SELinux context you can append either :z (if multiple containers need read-write access) or :Z (if only the current container needs read-write access).

Accessing volumes on Podman Desktop

Port Forwarding

To communicate with the services running inside the container, port forwarding has to be established from the host using the --publish flag in the run subcommand. The port specified for the host and container could be different for example the following command forwards the output from the httpd-test container’s port 80 to port 8080 on the host.

podman run --name httpd-test --detach \
           --publish 8080:80 \
           docker.io/library/httpd           

To view the output we can visit localhost:8080 in our browser. It is advised that only the necessary network ports should be forwarded from container to host.

Pausing an Executing Container

Pausing running container

To demonstrate a paused container we will take the help of the following Python script

# This script runs an infinite loop 
# with the time interval of 2 seconds to slow down the output

import time
i=0
while True:
    print("Value of i: {}".format(i))
    time.sleep(2)
    i+=1

Assuming that this script is saved in the current directory with name counting.py, we run a container created from image docker.io/library/python:3.10.6-slim-bullseye in detached mode.

podman run -it --name python-test --detach \
               --entrypoint="/bin/bash" \
               -v $(pwd):/app:Z \
               docker.io/library/python:3.10.6-slim-bullseye

Then we execute the script inside the container in interactive mode

podman exec -it python-test python3 /app/counting.py

An infinite loop will be initiated and the output should be visible on the terminal. Now we open a new terminal window and pause this container.

podman pause python-test

If we go back to the first terminal we can observe that the script execution is paused. When unpaused the container will restart right where it left.

podman unpause python-test

Stopping an Executing Container

Stop running containers

While pausing a container stops its execution in its current state, stopping a container kills the executing process.

podman stop python-test

Upon restarting container will run the entrypoint command, starting a new process.

podman start python-test

Deleting a Container

Deleting containers

Before we delete a running container we have to stop it or we can use the --force flag along with the rm subcommand.

podman rm python-test

Metrics and Logging

Listing Containers

By default, the ps subcommand fetches the list of running containers but to view all the containers regardless of their state we can use the --all flag.

podman ps --all

Resource Utilization Statistics

stats subcommand provides live statistics of resource utilization by containers.

podman stats

Accessing Logs from a Container

To access the logs of a running/completed container we use the logs subcommand. To view the live output from a running container --follow flag is added.

podman logs --follow httpd-test

To access the container logs from Podman Desktop we can click on the container name in the Containers section.

Accessing container logs from Podman Desktop

We can also attach a terminal to the container from the Terminal tab.

Resources

Podman Installation Instructions
Podman Desktop
podman-login
XDG Base Directory Specification
httpd container image
python container image
podman-search
podman-pull
podman-run
podman-exec
podman-pause
podman-stop
podman-stats
podman-logs

If the environment for the deployment of this application is different then the whole process of dependency installation has to repeat. You might have to some other changes, like setting up environment variables and making changes to the configuration files.

This problem becomes more challenging once you start collaborating with other people. The complete installation process has to be repeated on every development machine. Even if complete documentation of the setup process is available the developers could have a different environment. It is also possible that the developers want to work on two different projects simultaneously and there could be a conflict between their configurations (like different versions of the framework).

When an application is deployed directly on the OS running on the physical hardware it is called baremetal deployment.

Baremetal Deployment

Virtual Machines (VMs)

A virtual machine as the name suggests is a machine running upon the OS installed on the physical hardware. It has its virtual CPU, memory, networking interfaces, and other resources that are provided by a hypervisor.

A hypervisor is a program that is used to create and manage virtual machines. Some common hypervisors are:

• Oracle VM VirtualBox
• Hyper-V

Advantages of using VMs for deploying applications

Virtualized Deployment

So, what advantage does development over VMs provide over development on the OS deployed on the physical hardware?

1. The environment is persistent across the machines.
   If you create your application’s development environment inside a VM, then you can share it with anyone else who is interested to run it themselves.
   The environment will be the same irrespective of the OS installed on the physical hardware.
2. Load balancing is easier in the production environment.
   You can run multiple instances of the same application such that the load could be distributed effectively. If one of the instances is down (due to updates or outage) the traffic to it could be re-routed to another instance.
3. Effective distribution of physical hardware resources available.
   The hypervisor creates a pool of resources available to it from the OS. Then these resources could be effectively distributed among the VMs created. A deployment VM could use fewer resources compared to a development VM.
4. Provides an option to run multiple OS on a single hardware.

Containers

A container is a set of one or more isolated processes running on an OS, it could be on a VM or directly on the physical hardware. Usually, it requires fewer resources than a virtual machine and provides similar performance and benefits depending on your use case.

The workloads running inside a container have very limited exposure to the resources of its host i.e its CPUs, memory, network, and storage. It uses the same kernel as its host, that’s why you can’t spin up a Linux container on a machine running Windows (without provisioning the VM through Windows Subsystem for Linux or any other hypervisor).

Advantages of using Containers over Virtual Machines

Containerized Deployment

1. Relatively lighter compared to VMs
   Containers don’t need virtual resources. The size of the container could be shrunk down to the point where only the dependencies required for the application are present on it.
2. Faster deployment
   Due to their smaller size compared to VMs they could be deployed faster.
3. More scalable
   It is possible to execute multiple containers in the same amount of resources required by a VM for an application.

Depending on your use case the deployment could be a mix of both virtualization and containerization. Like a service comprising of multiple containers could be deployed on a VM.

Managing Containers

Container Runtime

The container is executed through a container runtime. It sets up the namespaces for the container.

Examples of container runtimes:

• containerd: Developed by Docker and donated to Cloud Native Computing Foundation (CNCF). Used in Docker Engine.
• cri-o: Container Runtime commonly used in Kubernetes.

Container Images

A container image is a file that contains all the dependencies and executable code for the container. It is a way of storing and sharing containers.

Container Image Registries

A container image registry is a service that handles the storage and distribution of container images.

Some of the common container registries are: DockerHub, Quay.io, etc.

Container Engine

When a container runtime is expanded with CLI and/or GUI utility for

• Creation of containers
• Changing the state of container (starting, stopping, resuming, deleting)
• Managing container images
• APIs for developers to create layered products on top of it

it becomes a container engine. Some examples of container engines are:

• Docker
• Podman

Open Container Initiative (OCI)

Open Container Initiative was established in 2015 for providing open specifications for:

• Container Runtime
• Container Image
• Container Image Distribution

The objective is to establish a standardized format for the containers such that an OCI container image could be used between different container engines without any issues.

Docker

One of the most commonly used container engines. It is developed by Docker, Inc. It uses a daemon (dockerd) that provides all the management services for the container. This daemon runs with root privileges.

Podman

The acronym for Pod Manager tool is a daemonless container engine originally developed by Red Hat.

Unlike docker, it doesn’t use any daemon for interactions with containers. It also has other security-focused features like the containers don’t run as root by default. This reduces the attack surface as the host system cannot be accessed from the inside of the container.

Skopeo

skopeo is a CLI utility used alongside podman for the management, inspection, and transfer of container images.

Buildah

buildah is another CLI utility used alongside podman and skopeo for building OCI container images.

Resources

Oracle VM VirtualBox
Hyper-V
containerd
cri-o
DockerHub
Quay.io
Open Container Initiative
Docker
Podman
Skopeo
Buildah