My podman quadlet setup is getting out of hand, how do you all manage yours?
I've been running rootless podman with quadlets, no compose, everything as systemd units. I'm on Fedora so it only felt native, and I really love how clean it feels, though the day to day is starting to bother me when I am hand editing .container files every…
I've been running rootless podman with quadlets, no compose, everything as systemd units. I'm on Fedora so it only felt native, and I really love how clean it feels, though the day to day is starting to bother me when I am hand editing .container files every time I need to change something, and running podman ps -a on repeat just to remember what's running. I should also mention that I don't have a dedicated server, so no Proxmox, TrueNAS, or Unraid like most people seem to have. This is all running on a laptop, so I'm hoping for something that doesn't assume that setup (yet.) I know I'm not the first person to hit this wall. What are you all using to manage a growing quadlet setup without it turning into a second job? It really doesn't need to be fancy, just something better than me squinting at a terminal every time, I guess. EDIT: Thank you all for the insightful comments, and I’ll be sure to check out ansible as many have recommended!
已收录讨论
Expand the replies to this comment to learn how AI was used in this post/project.
This is what I do too I do however have my files “compiled” from templates using gomplate and with data from YAML config files
IaC, Infrastructure as Code. I use Ansible for quadlets myself.
I didn't want to go full ansible, it felt overkill for my NAS. Just a git repo that holds all my quadlets, with a bash script that does an rsync and then a systemctl daemon-reload on the target server via SSH.
many comments here mentioning ansible, +1 to those, IaC is great. i’ll give a shoutout to pyinfra, same concept but it’s just all python. been using it for a couple weeks now and switched from ansible in my homelab, it’s so much faster and nice change of scenery imo, give it a shot!
When I ran Fedora mine was all applied with Ansible and managed in GIT. I have since moved to NixOS so it is all still containers-as-code, just a different config.
+1 for Nix: https://github.com/SEIAROTg/quadlet-nix
IaC, whether it's through Nix, Ansible, Kubernetes... It also makes things a lot easier to maintain overall.
Like this: https://github.com/vonrobak/fedora-homelab-containers But as others in the thread, I am heading towards Ansible to finalize the Infrastructure-as-code trajectory I have going on.
Used Ansible, now pyinfra, but in the end, it's the same things. Everything deployed on a single Fedora CoreOS box, work as expected.
for a dozen containers on one laptop, ansible and nix are more machine than the problem needs. keep the quadlets, just put the .container files in a git repo with a tiny makefile to reload changed units, and let podman auto-update plus systemctl --user handle the day to day. the pain you are describing is hand-editing and forgetting whats running, not lack of a config-management stack, so id fix that before signing up to maintain ansible too.
the ansible answers fix file generation but not your "podman ps -a on repeat" pain, thats a visibility thing: lean on systemctl to list your *.service quadlets + journalctl per unit instead of re-listing containers. for a single host ansible is overkill though, a git repo + a justfile is plenty, and the real ceiling is quadlets have no compose-style dependency ordering, so once services depend on each other you're hand-writing After=/Requires=, which is when grouping them in a .pod earns its place.
While I'll move to git+ansible at some point, it's a lot of work and I find ansible syntax unwieldy. So I use some usual file organization techniques, one folder for all related services, their mounted folders, config files etc (eg: immich or Prometheus+Grafana+Loki). Then 1 file to keep all related unit specifications (networks, volume, containers) together using my project https://github.com/apparle/multiquadlet . And finally clear rules on how services are connected to reverse proxy to avoid confusion later. And everything linked for autostart at boot. You'll still be staring at a terminal but it'll be much better organized, so less confusing.
A couple of things that aren't well described but can be useful are the way that systemd merges config files in a tiered way, and templating. By way of example, if you create a folder called [container-unit].container.d systemd and the quadlet generator will treat all .conf files in that folder as overrides to be merged into the generated unit file, this is even what systemd does behind the scenes with normal units if you run systemctl edit on a unit. What's more interesting though is that it will also treat anything contained in the folder container.d as an override for every container unit, so any common settings you have that apply to all containers can be set in one override file instead, you can even do things like db.service.container and main.service.container and have both set up on a common network using a service.container.d override. The other is templates, if you name a unit service@.container you can instance it by symlinking e.g. service@1.container to service@.container and use systemd's templating features to configure it, I don't find this one as useful since it interacts strangely with non-templated units but it's there.
I use podman-compose and couldn't be happier. Wrote some auto update scripts and it all works flawlessly for a year now. Only issue is me having nothing to do anymore, but my wife knows how to solve that now.
Use Nix That way you can manage everything under one config and Yes even Docker Containers or Podman pods
Thanks for sharing.