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
Table of Contents
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 Add this line and you're ready to go:.bashrc
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. This is because Podman does not use a daemon, so it's not possible to implement auto-restart features through the daemon.--restart
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, Buildah 跟 Skopeo. 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
- Reintroduction of Podman
- libpod GitHub
- Using Systemd with Podman containers
- All System Go — Replacing Docker with Podman
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stated otherwise.
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?