Podman Hands On

TsundereChen | Blog

2019-11-17

container

fedora, linux, podman

Podman Hands-on

Recently, Fedora released version 31, and in this release, Fedora removed Docker package from Fedora 31. Although you still can get moby-engine from upstream, and it includes Docker CLI and Docker Engine, but Fedora recommends you to switch to podman.

OK, so if it didn’t break, why switch from Docker to Podman ?

Because it did break, Docker broke in Fedora 31.

In short, Fedora 31 uses Cgroups v2 by default, and moby-enginestill uses Cgroups v1, didn’t support v2. There’s a way to run moby-engine on Fedora 31, though.

You may ask, “Okay…so no more Docker from now on, long live Podman?”, and this is a good question. But before answering this question, let’s take a look at Podman

What’s Podman

What is Podman? Simply put: alias docker=podman

Podman is a daemonless container engine for Open Container Initiative(OCI) containers and container images on Linux.

Wait, what? Daemonless? What daemon?

The daemon in Docker. Let’s take a look at how Docker works on your computer.

When you use docker on your computer, you didn’t use Docker directly. Instead, you’re using Docker CLI, which is connected to Docker daemon, running in the background of your computer.

Let’s say you want to run a container, you typed docker run ..., now, Docker CLI sends out command to Docker daemon, and if the image doesn’t exist on your computer, daemon will pull the image from registry, whether it’s Docker Hub or 3rd party registry. Then, Docker daemon use the image to create a container.

Basically, Docker daemon handles images/containers management, kernel operation, and more.

So, what’s wrong with this kind of architecture?

Docker daemon owned all the child process (running containers)
If the daemon failed, the child processes may fail
All Docker operation had to be conducted by a user with the same full root authority

On the last one, it’s actually a serious issue. In the page Post-installation steps for Linux, it says

Warning
The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface

For now, if you want to control Docker, you still need root permission to do so, which can be dangerous.

Podman solved these issues, how you ask? Let’s take a look at Podman’s architecture.

Instead of using “daemon”, Podman directly control all the stuff, registry, container, image, and Podman interact with kernel using runC. Even better, Podman uses “user namespace”, this means no more “sudo”. If you(or anyone who doesn’t have root permission) want to create a container, simply type “podman run”, and the container will be there.

runC is a container runtime used by lots of container tools, like Docker, Kubernetes…and others. Docker uses daemon to interact with runC, but Podman interact with runC directly.

Switch to Podman

To use Podman is simple, just install it. For example, if you want to install Podman in Fedora, just run

1	$ dnf install podman

After installation, run this line.

1	$ alias docker=podman

Yes, go ahead, do it. You won’t notice the difference, at least for the most part.

If you got error message related to /etc/subuid or /etc/subgid, maybe it’s because this file doesn’t in your Linux.

The file /etc/subuid and /etc/subgid are being used to map user in host to user in container, for example,

1	user:165536:65536

If user started a container using Podman, then Podman will map container’s UID 0 to host’s 165536, and container’s UID 1 will be host’s 165537…etc

Checkpoint

podman checkpoint can stops the container while writing the state of all processes in the container to disk. This container can be restored and run exactly at the same point when you executed podman checkpoint. To restore your container, just use podman restore.

The checkpoint function also means you can perform migration on containers, just use -e <FILE> parameter on podman checkpoint, then send the file to target machine, then use podman restore to put the container back into system.

Podman with Systemd

If you’ve been using Docker, you must know --restart=always parameter. But in Podman, it doesn’t have this feature.

Podman wasn’t designed to manage container start-up, dependency checking, or failed container handling, so if you want to start your container automatically, you need to use tools like systemd

For example, if you want to run nginx container

1 2	$ podman pull nginx:alpine $ podman run --name nginx -d -p 8080:80 nginx

Now, if you want to auto-restart the container, or start the container at boot time, write systemd unit file, like below.

[Unit]
Description=Nginx Podman container
Wants=syslog.service
[Service]
Restart=always
ExecStart=/usr/bin/podman start -a nginx
ExecStop=/usr/bin/podman stop -t 10 nginx
[Install]
WantedBy=multi-user.target

Then enable and start the service, and you’re done!

Buildah.io

Buildah is another program, it’s a project from CRI-O, just like Podman.

Buildah is a tool that facilitates building OCI container images. But it’s another day’s story, not today.