Live data from Hacker News

Make systemd better for Podman with Quadlet

redhat.com

41–50 of 88 posts

Re: Make systemd better for Podman with Quadlet

#41

Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)

>Similar to Compose or Kubernetes files, you can declare what you want to run without having to deal with all the complexities of running the workload.

Seems to be part of the idea. However, I personally have a bit of a hard time imagining this for the average developer. Maybe it will have the nice side effect of me digging further into systemd. However, most the compose stuff I used had to do with network and mounts. Wonder how to declare this in a systemd manner.

Re: Make systemd better for Podman with Quadlet

#42
post #41

Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)

>Similar to Compose or Kubernetes files, you can declare what you want to run without having to deal with all the complexities of running the workload. Seems to be part of the idea. However, I personally have a bit of a hard time imagining this for the average developer. Maybe it will have the nice side effect of me digging further into systemd. However, most the compose stuff I used had to do with network and mounts…

It feels more like an alternative for the lxc/lxd/nspawn crowds who're using long-running containers in fixed setups, rather than ad hoc spinning up of a bunch of related containers for one particular (and temporary) task.

Re: Make systemd better for Podman with Quadlet

#43
post #23

This looks quite nice. I run a server which is already RHEL+podman+generated systemd units, but this both simpler and more declarative/idempotent than my current setup. Anything that helps convince people that containers running on a single server can be simple, and doesn't require an entire k8s stack.

It's interesting that Redhat promotes this, despite having already invested quite a lot into systemd-nspawn for roughly the same purpose. Between it and lxd there's already some options for these sorts of simple, single-host container runtimes.

Re: Make systemd better for Podman with Quadlet

#44

Earlier quoted context omitted.

> Anything that helps convince people that containers running on a single server can be simple, and doesn't require an entire k8s stack. Docker?

Docker compose isn't exactly meant for production

The company I used to work for, used docker-compose to serve its SaaS product to 100+ clients. I wasn't part of that team, but it seemed to me they were quite happy with it.

Re: Make systemd better for Podman with Quadlet

#45
post #41

Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)

>Similar to Compose or Kubernetes files, you can declare what you want to run without having to deal with all the complexities of running the workload. Seems to be part of the idea. However, I personally have a bit of a hard time imagining this for the average developer. Maybe it will have the nice side effect of me digging further into systemd. However, most the compose stuff I used had to do with network and mounts…

I set up and deploy infra at my company, and I do it with Kubernetes.

I like the self-healing aspects of Kubernetes, but even something like k0s has a large, 1GB footprint that I don't want to have for my self-hosted personal projects.

Using podman and quadlet looks like it solves exactly what I want -- just enough kubernetes on a very small footprint.

This is not a replacement for docker-compose. I've never found a good use for that in infra because it lacks self-healing, so it stayed in the dev stack. If I was more proficient with Nix, I'd probably use that instead of docker-compose.

Re: Make systemd better for Podman with Quadlet

#46

Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)

Not really. This is more to replace kubelet if you want something with an even smaller footprint than k0s.

Re: Make systemd better for Podman with Quadlet

#47
post #26

I heard you like abstract tools to do stuff, so I added an abstract tool to your tool to manage abstract tooling.

This is actually a pretty natural fit, imo. Docker containers are basically processes with fat runtimes, and container orchestration layers are essentially glorified process supervisors. At the same time, most Linux systems already come with a pretty fancy process supervisor. Personally, I think writing systemd units from scratch is already pretty easy. But it makes sense that Linux software which often integrates wi…

> Also, in some ways I think this is simpler.

Not really. Being simpler would be managing containers directly with systemd, as with systemd-nspawn. Why do I need to use a container manager in systemd for something systemd can already do directly? This integration with Podman is Red Hat's way of promoting the tool to stay relevant, but it's not actually simpler.

Re: Make systemd better for Podman with Quadlet

#49

Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)

I think this can replace docker-compose in deployment - if thats how you deploy and are willing to alter your workflow slightly.

I've done this for a while on small or disconnected systems, systemd + podman is very nice, the regular unit file generators are very usable + modifiable.

From the development side, the issue is unit files must be "installed", I can't just have a set of `x.service y.service" files and `systemd start $(pwd)/x.service`, so the overhead is a bit awkward there.

`podman play kubelet` is sort of there, except it doesn't support some networking options in the kubelet file, so its not a complete replacement.

Podman also includes support for running kubelet files via systemd but I don't use that myself.

I think ideally kubelet files with some extra podman annotations are the compose replacement, even if writing them isn't as pleasant as compose files. They you could `podman play kube x` to boot the dev stack and use the systemd-x-kubelet template to deploy.

Post reply on HN