Using podman to run systemd services (Silverblue)

I had first used rpm-ostree to install things like dnscrypt-proxy, aide, etc. Now I am trying to start from scratch and see how far I can go without using it all.

For reference, I’m using this as a rough guide: Chapter 4. Running Containers as systemd Services with Podman Red Hat Enterprise Linux Atomic Host 7 | Red Hat Customer Portal

So my approach is, create a new container with toolbox create, install the necessary daemon, then try to expose it with podman with a systemd wrapper. But, I am having a problem seeing the toolbox container listed in podman. It is not referring to any local images, only those from a fedora registry or similar.

Any advice is appreciated

I usually setup the container with podman and when I get it to where it should be, I use podman generate-systemd -nto create the service file and add it to /etc/systemd/system. You can tweak this file accordingly to edit environmental vars or pull image on run, etc.

One other consideration is if you’re building an image locally, rootless built images won’t be accessible as root locally, so you’ll want to set User= in the service file as the user you’re using to build the image. You can skip this if you’re just running something from quay or Docker Hub.

Once you’ve setup the service file, systemctl daemon-reload should pick it up and you can run it with systemctl start or systemctl enable --now (if you want it to come up on reboot).

Hopefully, this is enough info to get you started and not too much info at the same time. I would refer to man podman-generate-systemd if you get stuck on anything from here.

Lastly, I would be careful about using RHEL7 docs. A lot has changed for containers even between EL7 and EL8, let alone Fedora.

4 Likes

Thank you Scott. Podman generate-systemd looks promising, and that’s good to know about the RH docs.

May I ask what your workflow for setting up containers with podman looks like (as opposed to toolbox)? I wonder if I am on the wrong track starting with toolbox for this use case. Maybe it is better suited for setting up dev environments.

1 Like

I don’t really have a standard here. That entirely depends on what I’m working on (ie, webapp, database, dev sandbox), where it’s ultimately going to run (ephemeral, persistent, on a kubernetes cluster, etc.), and the complexity (ie, one pod, several that need to talk to each other on an isolated network). If it’s helm, I usually skip podman entirely and focus solely on kubernetes. In most cases, I just try to figure out how to run it with podman run and tweak ports, environment variables, and storage mounts until I’m able to achieve whatever it is I’m trying to do and then go from there.

As far as toolbx goes, I see it being most useful for development environments. I tend to especially containerize nodejs, ruby, and python stuff where dependencies can get out of hand quickly.

2 Likes