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.
Contents
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 to get started:.bashrc
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 flag has been removed. This is because Podman does not use a daemon, so it cannot implement an auto-restart feature through one.--restart
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, Buildah 跟 Skopeo. 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
- Reintroduction of Podman
- libpod GitHub
- Using Systemd with Podman Containers
- All Systems Go — Replacing Docker with Podman
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.


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?