Podman Introduction

Podman 介紹

Podman was originally part of the CRI-O project, later split off into an independent project libpodPodman (Pod Manager) aims to provide a container CLI experience similar to Docker, enabling users to create and run containers

Before Getting Started

Let's begin with a brief All System Go: Replacing Docker with Podman Presentationintroduction to this section

I promise
To use the term container registries instead of docker registries
I promise
To use the term container images instead of docker images
I promise
To use the terms containers or OCI containers instead of docker containers

Install Podman

Fedora

Podman is already available in the Fedora repository and can be installed using the built-in package manager

sudo dnf install podman

Ubuntu

Ubuntu users will need to build from source, first install some required dependencies

sudo apt-get update
sudo apt-get install libdevmapper-dev libglib2.0-dev libgpgme11-dev golang libseccomp-dev \
                        go-md2man libprotobuf-dev libprotobuf-c0-dev libseccomp-dev python3-setuptools

Next, build conmon:

export GOPATH=~/go
mkdir -p $GOPATH
git clone https://github.com/kubernetes-sigs/cri-o $GOPATH/src/github.com/kubernetes-sigs/cri-o
cd $GOPATH/src/github.com/kubernetes-sigs/cri-o
mkdir bin
make bin/conmon
sudo install -D -m 755 bin/conmon /usr/libexec/podman/conmon

Create the necessary configuration files:

sudo mkdir -p /etc/containers
sudo curl https://raw.githubusercontent.com/projectatomic/registries/master/registries.fedora -o /etc/containers/registries.conf
sudo curl https://raw.githubusercontent.com/containers/skopeo/master/default-policy.json -o /etc/containers/policy.json

Install the CNI plugin:

git clone https://github.com/containernetworking/plugins.git $GOPATH/src/github.com/containernetworking/plugins
cd $GOPATH/src/github.com/containernetworking/plugins
./build.sh
sudo mkdir -p /usr/libexec/cni
sudo cp bin/* /usr/libexec/cni

Install runc:

git clone https://github.com/opencontainers/runc.git $GOPATH/src/github.com/opencontainers/runc
cd $GOPATH/src/github.com/opencontainers/runc
make BUILDTAGS="seccomp"
sudo cp runc /usr/bin/runc

Finally install Podman

git clone https://github.com/containers/libpod/ $GOPATH/src/github.com/containers/libpod
cd $GOPATH/src/github.com/containers/libpod
make
sudo make install PREFIX=/usr

Project Atomic PPA

Alternatively, there is an even simpler option—use the Project Atomic PPA directly:

sudo add-apt-repository ppa:projectatomic/ppa
sudo apt update
sudo apt install podman

Use Podman

Using Podman is extremely simple—just add this line to your .bashrc Add this line and you're ready to go:

alias docker=podman

This isn't just a game. Podman's commands are 87% compatible with Docker's. With this line, you can seamlessly migrate with minimal effort. However, a few minor details require attention, which will be explained later.

Why Podman?

No Large Daemons

Unlike Docker Engine, Podman does not have a daemon.

When using the Docker CLI, the Docker CLI communicates via API with the Docker Engine, saying "I want to start a container." Only then does the Docker Engine use the OCI Container runtime (default is runc) to launch the container. This means the container's process is not a child process of the Docker CLI, but rather a child process of the Docker Engine.

Podman doesn't use a daemon—it directly uses the OCI runtime (default is also runc) to launch containers, so container processes become direct child processes of Podman. This is similar to the traditional Linux fork/exec model. It also means system administrators can clearly see which container process actually started, and if cgroups are used to impose limits on the Podman command, all associated containers will similarly be subject to those limits.

This model also allows Podman to leverage systemd's advanced features by placing Podman in a systemd unit file. For example, systemd can use notify to track the startup order of services. If a service inside a container needs to start before another service, the subsequent service will wait for a notify signal from the container, confirming that the container has finished starting before beginning its own execution. This functionality is not possible via Docker CLI, but Podman forwards systemd's notifications to its child processes, so container processes can notify systemd that they've completed execution.

Restart Lost?

Most users may initially notice that some flags in Docker commands have been removed. --restart This is because Podman does not use a daemon, so it's not possible to implement auto-restart features through the daemon.

So, how do you automatically restart containers after system reboot?
Very simple, using systemd will achieve it.

Use nginx as a proxy example:

First, we run an nginx container

sudo podman run -t -d -p 80:80 --name nginx nginx

The reason it runs as root is because rootless containers currently do not support port binding.

After that, /etc/systemd/system<code> 下建立一個 </code>nginx_container.service

[Unit]
Description=Podman Nginx Service
After=network.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/podman start -a nginx
ExecStop=/usr/bin/podman stop -t 10 nginx
Restart=always

[Install]
WantedBy=multi-user.target

Next, use this service

sudo systemctl daemon-reload
sudo systemctl enable nginx_container.service
sudo systemctl start nginx_container.service

You can check the status of this service

sudo systemctl status nginx_container.service
● nginx_container.service - Podman Nginx Service
   Loaded: loaded (/etc/systemd/system/nginx_container.service; enabled; vendor preset: disabled)
   Active: active (running) since Sat 2018-10-20 05:59:24 UTC; 1min 41s ago
 Main PID: 845 (podman)
    Tasks: 16 (limit: 4915)
   Memory: 37.6M
   CGroup: /system.slice/nginx_container.service
           └─845 /usr/bin/podman start -a nginx

Oct 20 05:59:24 fedora-dev.novalocal systemd[1]: Started Podman Nginx Service.

After each system reboot, systemd will automatically start this service (i.e., container).

Conclusion

Podman is currently one of the key components in the container ecosystem, others include CRI-O, BuildahSkopeo. Next, there will be a detailed introduction to Buildah, and as for Skopeo, you can refer to this article. Skopeo: Method for managing container image repositories and registries

Reference


Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stated otherwise.

One Reply to "Podman Introduction"

  1. The version is clearly and concisely explained, though there's a part that's not very clear,
    If Podman does not rely on a container runtime daemon, such as Docker Engine, CRI-O, etc.
    How does it communicate with runc? Not very familiar with runc, but looking at it, runc is not a daemon,
    Good example: when running `sudo podman ps`, where does it get the list of currently running containers?

Leave a Reply