39
The purpose of podman quadlets? (lemmy.world)
submitted 1 month ago by dont@lemmy.world to c/selfhosted@lemmy.world
16 comments fedilink hide all child comments

I'm afraid this is going to attract the "why use podman when docker exists"-folks, so let me put this under the supposition that you're already sold on (considering) using podman for whatever reason. (For me, it has been the existence of pods, to be used in situations where pods make sense, but in a non-redundant, single-node setup.)

Now, I was trying to understand the purpose of quadlets and, frankly, I don't get it. It seems to me that as soon as I want a pod with more than one container, what I'll be writing is effectively a kubernetes configuration plus some systemd unit-like file, whereas with podman compose I just have the (arguably) simpler compose file and a systemd file (which works for all pod setups).

I would get that it's sort of simpler, more streamlined and possibly more stable using quadlets to let systemd manage single containers instead of putting podman run commands in systemd service files. Is that all there is to it, or do people utilise quadlets as a kind of lightweight almost-kubernetes distro which leverages systemd in a supposedly reasonable way? (Why would you want to do that if lightweight, fully compliant kubernetes distros are a thing, nowadays?)

Am I missing or misunderstanding something?

top 16 comments
sorted by: hot top controversial new old
[-] misterbngo@awful.systems 10 points 1 month ago* (last edited 1 month ago)

I think the gap you have is in understanding that Podman Compose was meant to line up with the limitations of docker's compose, but technically is more capable.

Quadlet files let you do more complex workflows like deploying multiple copies of a service in your deployment that regular compose doesn't, while not running full kube.

The use I have is that I have something deployed in compose right now that I'd like to scale up on the box since i have the capacity for it, but dont want to deal with a full kube setup or the politic

Personally I've converted most of my single node k3s to using quadlet files instead as its less fragile. I absolutely deploy single containers in the quadlet. They show up in journalctl and the ergonomics are great.

[-] snowfalldreamland@lemmy.ml 2 points 1 month ago

How do you do inter-pod communication witg quadlet? I never figured that out with podman kube play and just moved back to staring conatiners and creating networks from a shell script

[-] dont@lemmy.world 1 points 1 month ago

Thank you for those very convincing points. I think I'll give it a try at some point. It seems to me that what you're getting in return for writing quadlet configuration in addition to the kubernetes style pod/container config is that you don't need to maintain an independent kubernetes distro since podman and systemd take care of it and allow for system-native management. This makes a lot of sense.

[-] just_another_person@lemmy.world 10 points 1 month ago

It's a systemd-style way to manage podman containers that aims to be as easy to manage as compose/swarm. Not quite an integration, but operates similarly, and about as easy to read. Less heavy than managing a local micro-k8s cluster. That's about it.

[-] mosiacmango@lemm.ee 4 points 1 month ago* (last edited 1 month ago)

Yup. I read it as "compose and manage containers with systemd."

Sure, there is a k8s layer abstracted into podman to do this, but you don't manage or interact with it. Everything is a systemd unit file, a simple text document with a well understood structure. Containers are started and logged like services.

Easy, direct, tidy.

[-] dont@lemmy.world 1 points 1 month ago

Understood, thanks, but if I may ask, just to be sure: It seems to me that without interacting with the kubernetes layer, I'm not getting pods, only standalone containers, correct? (Not that I'm afraid of writing kube configuration, as others have inferred incorrectly. At this point, I'm mostly curious how this configuration would be looking, because I couldn't find any examples.)

[-] mosiacmango@lemm.ee 3 points 1 month ago* (last edited 1 month ago)

I'm still new to this myself, but yes that's the gist of it. This isn't k8s or even k3s. It's an easy way to deploy a container via code on a single node system using the already present systemd for management. It let's you pretend that Linux handles containers natively like it does daemons.

This article from redhat has more information about the why and what.

[-] runiq@feddit.org 2 points 1 month ago
[-] dont@lemmy.world 1 points 1 month ago* (last edited 1 month ago)

Awesome, so, essentially, you create a name.pod file like so:

[Unit]
Description=Pod Description

[Pod]
# stuff like PublishPort or networking

and join every container into the pod through the following line in the .container files: Pod=name.pod

and I presume this all gets started via systemctl --user start name.service and systemd/podman figures out somehow which containers will have to be created and joined into the pod, or do they all have to be started individually?

(Either way, I find the documentation of this feature lacking. When I tested this stuff myself, I'll look into improving it.)

[-] runiq@feddit.org 2 points 1 month ago* (last edited 1 month ago)

Awesome, so, essentially, you create a name.pod file like so: [...]and join every container into the pod through the following line in the .container files

Yep, that's the way!

and I presume this all gets started via systemctl --user start name.service and systemd/podman figures out somehow which containers will have to be created and joined into the pod, or do they all have to be started individually?

Systemd figures it out iff you have specified your service dependencies correctly, with things like After=, Upholds=, BindsTo=, etc. Have a look at systemd.unit manpage for details. For my paperless service, it goes something like this:

  1. The entrypoint is paperless.container, which I start with systemctl --user start paperless, which depends on:
    • paperless.pod
    • Three other services, which also depend on:
      • paperless.pod
  2. Systemd figures out that the paperless pod should be started first, and does that
  3. Systemd startes the three dependent containers
  4. Finally, systemd starts the paperless container itself

The point of quadlet was to lean as heavily as possible on systemd for the service and dependency bits and use podman only for translating the container bits into something systemd can handle. The one bit of dependency handling that quadlet does is to make sure that paperless.pod is started before all containers that have Pod=paperless.pod in their quadlet file.

Either way, I find the documentation of this feature lacking. When I tested this stuff myself, I’ll look into improving it.

That would be amazing, of course! :) I find that, if you're familiar with unit files, you're like 85% of the way there already. By the way, the unit files that quadlet generates are somewhere in $XDG_RUNTUME_DIR for you to inspect. I'm afraid I'm not at a computer right now andI don't know the exact path off the top of my head.

[-] dont@lemmy.world 2 points 1 month ago

Nice, thanks, again! I overlooked the dependency instructions in the container service file, which is why I wondered how the heck podman figures out the dependencies. It makes a lot of sense to do it like this, now that I think of it.

[-] dont@lemmy.world 3 points 1 month ago

Thank you, I think the "less heavy than managing a local micro-k8s cluster"-part was a great portion of what I was missing here.

[-] scrubbles@poptalk.scrubbles.tech 4 points 1 month ago

From my understanding, I think you're right, it's some hybrid between single docker containers and just running k8s. If you're nearing the point where you need to start distributing your containers, personally you might as well just learn kubernetes. It's a massive learning curve, but frankly it's still the best option.

[-] markstos@lemmy.world 3 points 1 month ago

I like to manage services maximally with systemd so it was a natural fit for me.

It did not seem difficult to set up web and database quadlets so they are properly networked.

[-] oranki@lemmy.world 2 points 1 month ago

I didn't read all the comments, so someone may have pointed this out already.

One of the main ideas is probably something like Fedora CoreOS, where the Quadlet systemd files are automatically created during first boot with something like Kickstart or cloud-init.

Instead of shipping the applications with the image, the OS image can be very minimal, while still being able to run very complex stuff.

When you add the fact that CoreOS and other atomic distros can update themselves in the background, and boot to an updated base image, the box just needs periodic reboots and everything stays updated and running with basically no interaction from the admin at all, best case.

Probably not so useful in the self-hosting / homelab context, but I can imagine the appeal on a larger scale.

I've been using Quadlet+Podman kube YAMLs for a while for my own self-hosted services, and it's pretty rock solid. Currently experimenting with k3s, but I think I'll soon switch back. Kubernetes is nice, but it's a lot more fragile for just a single node. And there's way too much I don't understand...

I wrote a couple blog posts about the homelab setup, planning to add more when I have time. Give a read if you're interested: https://oranki.net/tags/self-hosting-my-way/

[-] dont@lemmy.world 2 points 1 month ago

Thanks, the bootstrapping idea was not mentioned in the comments, yet. And your blog looks promising, will have a more through look soon.

this post was submitted on 02 Oct 2024
39 points (97.6% liked)

Selfhosted

40313 readers
570 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz