Podman: Difference between revisions

From CSCWiki
Jump to navigation Jump to search
 
Line 43: Line 43:
--gateway=2620:101:f000:4901::1 \
--gateway=2620:101:f000:4901::1 \
bbbnet
bbbnet
</pre>

Then create a pod in which the containers will be run:

<pre>
podman pod create \
--name bbbpod \
--network bbbnet \
--share net \
--ip=129.97.134.173 \
--ip6=2620:101:f000:4901:c5c::173
</pre>
</pre>



Latest revision as of 08:28, 16 August 2024

Podman is a very neat Docker-compatible container solution. Some of the advantages it has over Docker are:

  • no daemon (uses a fork-and-exec model)
  • systemd can run inside containers very easily
  • containers can become systemd services on the host
  • non-root users can run containers

Installation

As of bullseye, podman is available in the official Debian repositories. I suggest installing it from the unstable distribution, since podman 3.2 has many useful improvements over previous versions:

apt install -t unstable podman podman-docker 

The podman-docker package provides a wrapper script so that running the command 'docker' will invoke podman. Recent versions of podman also provide API compatibility with Docker, which means that docker-compose will actually work out of the box. (For non-root users, you will need to set the DOCKER_HOST environment variable to unix://$XDG_RUNTIME_DIR/podman/podman.sock).

I suggest adding the following to /etc/containers/registries.conf so that podman automatically pulls packages from docker.io instead of quay.io:

[registries.search]
registries = ['docker.io']

Networking

As of this writing (2024-08-16), the latest network backend in Podman is netavark. Hosts which are still using the legacy CNI backend should switch to netavark as soon as possible, because support for CNI will be removed in Podman 5.0. Unfortunately, the officially recommended way to migrate from CNI to netavark is to run "podman system reset", which deletes everything (containers, images, networks, etc.). This is usually undesirable. Here's what I suggest instead (assuming you don't have custom Podman networks):

  1. Stop all running containers.
  2. Run echo -n netavark > /var/lib/containers/storage/defaultNetworkBackend.
  3. Restart the stopped containers.

If you had custom networks before, this is trickier. You will need to manually convert the CNI JSON file into the netavark JSON format (under /etc/containers/networks).

Directly exposing a container to a public network

The easiest way to do this, in my opinion, is with a macvlan network. Here's an example of how this was done for BigBlueButton on xylitol:

podman network create \
  --driver=macvlan \
  --ipv6 \
  --opt parent=br0 \
  --subnet=129.97.134.0/24 \
  --gateway=129.97.134.1 \
  --subnet=2620:101:f000:4901:c5c::0/64 \
  --gateway=2620:101:f000:4901::1 \
  bbbnet

Then create a pod in which the containers will be run:

podman pod create \
  --name bbbpod \
  --network bbbnet \
  --share net \
  --ip=129.97.134.173 \
  --ip6=2620:101:f000:4901:c5c::173

Systemd

Podman integrates with systemd in both directions - systemd can run in podman, and podman can run in systemd.

Systemd in podman

To run systemd in podman, just create a Dockerfile like the following:

FROM ubuntu:bionic  
    
ENV DEBIAN_FRONTEND=noninteractive    
RUN apt update && apt install -y systemd
RUN passwd -d root    
    
CMD [ "/bin/systemd" ]

Then run:

podman build --privileged -t ubuntu-systemd:bionic -f ubuntu-bionic-systemd.Dockerfile

If you're running this as root, I suggest using the --privileged flag. I am pretty sure that there some specific capabilities you can add instead to make it work (via the --cap-add flag), but this is easier.

Then, to run a container with this image:

podman run -it --privileged ubuntu-systemd:bionic

Podman in systemd

Podman has a built-in command to generate systemd service files to start containers and pods. For example, let's say we have a pod named bbbpod. Run the following:

podman generate systemd --files --name bbbpod

This will create .service files for the pod and the containers inside it. Now you just need to enable them:

mv *.service /etc/systemd/system/
systemctl daemon-reload 
systemctl enable pod-bbbpod.service

If you now run systemctl start pod-bbbpod, the pod and its containers will start.

Pods

Podman pods are similar to Kubernetes pods; they can share namespaces with each other, such as network namespaces and UTS namespaces. In this example, we will use a network namespace.

First, we create a pod in the network we previously created:

podman pod create --network bbbnet --name bbbpod --share net

Then run a container inside the pod:

podman run -it --name bbb --hostname bbb --pod bbbpod --privileged ubuntu-systemd:bionic

You can add more containers to the pod:

podman run -d --name greenlight --pod bbbpod --env-file $PWD/env bigbluebutton/greenlight:v2

The bbb and greenlight containers can now communicate with each other over localhost.

Important: Make sure to edit /etc/hostname and /etc/network/interfaces (or whichever network manager you decide to use) in each container.

Volumes

Unfortunately podman does not currently have functionality to allocate a separate volume to each container. Instead, I suggest mounting each root-level folder in a separate volume.

Let's say you created a new LVM volume mounted at /vm/bigbluebutton. So create your container like the following:

podman run ... --name bbb -v /vm/bigbluebutton/bin:/bin -v /vm/bigbluebutton/boot:/boot -v /vm/bigbluebutton/etc:/etc -v /vm/bigbluebutton/home:/home -v /vm/bigbluebutton/lib:/lib -v /vm/bigbluebutton/lib64:/lib64 -v /vm/bigbluebutton/media:/media -v /vm/bigbluebutton/mnt:/mnt -v /vm/bigbluebutton/opt:/opt -v /vm/bigbluebutton/root:/root -v /vm/bigbluebutton/sbin:/sbin -v /vm/bigbluebutton/srv:/srv -v /vm/bigbluebutton/usr:/usr -v /vm/bigbluebutton/var:/var ubuntu-systemd:bionic

It is also a good idea to mount /var/lib/containers in a separate LVM volume to avoid running out of space on the host.