Introduction to Podman

Podman 介紹

Podman was once a part of the CRI-O project, but was later separated into an independent project, libpodThe goal of Podman (Pod Manager) is to provide a container CLI with an experience similar to Docker, allowing users to create and run containers.

Before You Begin

Let's start by reading a passage presented in the 'All Systems Go: Replacing Docker with Podman' talkfrom the manifesto

I promise
To say container registries rather than docker registries
I promise
To say container images rather than docker images
I promise
To say containers or OCI containers rather than docker containers

Installing Podman

Fedora

Podman is currently available in the Fedora repositories; you can simply install it using the built-in package manager.

sudo dnf install podman

Ubuntu

For Ubuntu, you will need to build it from source. First, install the required packages:

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 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

Of course, there is an even simpler way: use the Project Atomic PPA directly:

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

Using Podman

Using Podman is very simple; you just need to add this line to your .bashrc to get started:

alias docker=podman

I'm not joking—Podman's commands are 87% identical to Docker's. Adding this line basically allows for a painless migration, though there are a few small details to watch out for, which I'll explain later.

Why Podman?

No Bloated Daemons

Unlike Docker Engine, Podman does not have a daemon.

When using the Docker CLI, it communicates via an API to tell the Docker Engine, "I want to start a container." The Docker Engine then uses an OCI Container runtime (defaulting to runc) to launch the container. This means the container process is not a child process of the Docker CLI, but rather a child process of the Docker Engine.

Podman does not use a daemon; instead, it launches containers directly through the OCI runtime (also defaulting to runc). Consequently, the container process is a direct child process of Podman. This more closely resembles the traditional Linux fork/exec model. This also means system administrators can identify exactly who started a container process. Furthermore, if you use cgroups to impose limits on the Podman command, those same limits will apply to all its containers.

This model also allows Podman to leverage advanced systemd features by placing Podman within a systemd unit file. For example, systemd can use "notify" to manage service startup sequences. If a service inside a container needs to start before other services, subsequent services will wait for the container to send a notify signal to systemd, confirming the container has finished starting before they begin running. This cannot be achieved through the Docker CLI, but Podman forwards systemd information to the child process, allowing the container process to notify systemd once it is ready.

Has Restart Disappeared?

Most people starting out with Podman might notice that the --restart flag has been removed. This is because Podman does not use a daemon, so it cannot implement an auto-restart feature through one.

So, how do you automatically start containers after a system reboot?
It's simple: you can achieve this by using systemd as well.

Using Nginx as an example:

First, let's run an Nginx container.

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

The reason for running as root is that rootless containers do not yet support port binding.

Then, in /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, enable 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 using the status command.

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.

Afterwards, systemd will automatically start this service (the container) every time the system reboots.

Conclusion

Podman is one component of the current container ecosystem; others include CRI-O, BuildahSkopeo. I will write an introduction to Buildah when I have the chance; as for Skopeo, you can refer to this article: Skopeo: A Way to Manage Container Images and Registries

Reference


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

One Reply to “Introduction to Podman”

  1. The author's explanation is very clear, but there's one part I don't quite understand:
    If Podman does not rely on a container runtime daemon, such as Docker Engine, CRI-O, etc.
    How does it communicate with runc? Sorry, I'm not very familiar with runc, but it doesn't look like a daemon,
    I'm curious, for example, when running `sudo podman ps`, where does it get the list of currently running containers?

Leave a Reply