Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make systemd better for Podman with Quadlet

redhat.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Make systemd better for Podman with Quadlet

#51

Post by INTPenis »

hosh wrote: post #46
INTPenis wrote: post #33

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.

Yeah I didn't really think before I typed that. If it requires you to install systemd files then it's not really equivalent.

I don't understand why they made it so complicated, if you have a file format just let the user run it from their CWD.

Re: Make systemd better for Podman with Quadlet

#52

Post by INTPenis »

davewood wrote: post #48
INTPenis wrote: post #33

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)

why wouldnt you recommend podman-compose?

I haven't used it for well over a year now but last time it had issues with networking.

Re: Make systemd better for Podman with Quadlet

#53

Post by bonzini »

INTPenis wrote: post #51
hosh wrote: post #46

Earlier quoted context omitted.

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

Yeah I didn't really think before I typed that. If it requires you to install systemd files then it's not really equivalent. I don't understand why they made it so complicated, if you have a file format just let the user run it from their CWD.

Because the idea is that this is a declarative configuration, not something that the user has to run. You first write the configuration, and then running it is just "systemctl start foo".

Generators are the same mechanism by which systemd reads /etc/fstab; just like /etc/fstab entries are treated by systemd as "normal" mount units, systemd will treat .container files just like any other system service.

Re: Make systemd better for Podman with Quadlet

#54

Post by INTPenis »

bongobingo1 wrote: post #49
INTPenis wrote: post #33

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 `syst…

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

People have been telling me this for years now and I have yet to see a working example.

Re: Make systemd better for Podman with Quadlet

#55

Post by bonzini »

zephyros wrote: post #37

I'm using the podman ansible module[1] to manage the podman container atm, it's ... Okish. I wrote a spaghetti mess with ansible conditionals and loops to manage multitude of systemd files made from podman-generate-systemd. If I had some time maybe I'll try this out, a more declarative approach would certainly be nicer. [1]: https://github.com/containers/ansible-podman-collections

I do something similar but I don't use podman-generate-systemd; instead I create the systemd service by hand using a Jinja template[1], and then start the service[2]. This has the advantage that there's no hole where the container is running but systemd configuration has not been updated yet.

Either way, it's indeed quite tempting to use quadlet instead of the nasty templates that build the podman commandline.

I also want to check if quadlet supports override files like systemd's, because that would be quite interesting as a customization mechanism that does not require forking the playbooks.

[1] https://github.com/patchew-project/patchew/blob/master/scrip...

[2] https://github.com/patchew-project/patchew/blob/master/scrip...

Re: Make systemd better for Podman with Quadlet

#56

Post by asabil »

This is really neat. I have been using `podman generate systemd` for a large number of deployments. This just makes it so much simpler.

For anyone wondering, the main difference between this and docker/docker-compose is that podman can run in a daemonless mode such as containers are running directly under systemd which makes them integrate into the existing systemd infrastructure and appear as any other normal service.

Re: Make systemd better for Podman with Quadlet

#57

Post by INTPenis »

bonzini wrote: post #53
INTPenis wrote: post #51

Earlier quoted context omitted.

Yeah I didn't really think before I typed that. If it requires you to install systemd files then it's not really equivalent. I don't understand why they made it so complicated, if you have a file format just let the user run it from their CWD.

Because the idea is that this is a declarative configuration, not something that the user has to run. You first write the configuration, and then running it is just "systemctl start foo". Generators are the same mechanism by which systemd reads /etc/fstab; just like /etc/fstab entries are treated by systemd as "normal" mount units, systemd will treat .container files just like any other system service.

Yeah but they have invented the declarative file format, but they put it in /etc, why not put it in $HOME/.config/systemd instead? That would make it more on-par with docker compose.

I'm hoping this is in the future of quadlet. Being able to run the files from CWD, using systemd units in $HOME, and not requiring root.

Re: Make systemd better for Podman with Quadlet

#58

Post by mike_hearn »

Interesting!

For my own servers I use an internal tool that integrates apps with systemd. You point it at the output of your build system and a config file, and it produces a deb that contains systemd unit files and which registers/starts the server on install/reboot/upgrade, as a regular debian package would. Then it uploads it to the server via sftp and installs it using apt, so dependencies are resolved. As part of the build process it can download and bundle language runtimes (I use it with a JVM), it scans native binaries to find packages that the app should depend on, and you can define your config including package metadata like dependencies and systemd units using the HOCON language [1].

Upshot is you can go from native binaries/Gradle/Maven to a running server with a few lines of config. Oh and it can build debs from any OS, so you can push from macOS and Windows too. If your server needs to depend on e.g. Postgres, you just add that dependency in your config and it'll be up and running after the push.

It also has features to turn on DynamicUser and other sandboxing features. I think I'll experiment with socket activation next, and then bundled BorgBackup.

Net/net it's pretty nice. I haven't tried with containers because many language ecosystems don't seem to really need them for many use cases. If your build tool knows how to download your language runtime and bundle it sans container by just setting up paths correctly, then going without means you can rely on your Linux distribution to keep things up to date with security patches in the background, it means networking works as you'd expect (no accidentally opened firewall ports!) and so on. SystemD knows how to configure resource isolation/cgroups and kernel sandboxing, so if you need those you can just write that into your build config and it's done. Or not, as you wish.

With a deployment tool to automate builds/pushes, systemd to supervise processes and a big beefy dedicated machine to let you scale up, I wonder how much value the container part is really still providing if you don't need the full functionality of Kubernetes.

[1] https://github.com/lightbend/config/blob/main/HOCON.md

Re: Make systemd better for Podman with Quadlet

#59

Post by alexlarsson »

INTPenis wrote: post #57
bonzini wrote: post #53

Earlier quoted context omitted.

Because the idea is that this is a declarative configuration, not something that the user has to run. You first write the configuration, and then running it is just "systemctl start foo". Generators are the same mechanism by which systemd reads /etc/fstab; just like /etc/fstab entries are treated by systemd as "normal" mount units, systemd will treat .container files just like any other system service.

Yeah but they have invented the declarative file format, but they put it in /etc, why not put it in $HOME/.config/systemd instead? That would make it more on-par with docker compose. I'm hoping this is in the future of quadlet. Being able to run the files from CWD, using systemd units in $HOME, and not requiring root.

For rootless use, put the files in ~/.config/containers/systemd/

Re: Make systemd better for Podman with Quadlet

#60

Post by bonzini »

alexlarsson wrote: post #59
INTPenis wrote: post #57

Earlier quoted context omitted.

Yeah but they have invented the declarative file format, but they put it in /etc, why not put it in $HOME/.config/systemd instead? That would make it more on-par with docker compose. I'm hoping this is in the future of quadlet. Being able to run the files from CWD, using systemd units in $HOME, and not requiring root.

For rootless use, put the files in ~/.config/containers/systemd/

Alex, since you're here does quadlet support override files like systemd's /etc/systemd/system/foo.service.d directories? I couldn't find it in the documentation.
Post reply on HN