dont

joined 5 months ago
[–] [email protected] 9 points 1 month ago

Finally, I can give it a star, being only on gitlab and not on github

[–] [email protected] 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.

[–] [email protected] 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.

[–] [email protected] 1 points 1 month ago* (last edited 1 month ago) (2 children)

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.)

[–] [email protected] 2 points 1 month ago

I've wondered myself and asked here https://lemmy.world/post/20435712 – got some very reasonable answers

[–] [email protected] 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.

[–] [email protected] 1 points 1 month ago (5 children)

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.)

[–] [email protected] 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.

 

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?