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

61–70 of 88 posts

Re: Make systemd better for Podman with Quadlet

#61

Post by INTPenis »

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/

Thanks I just realized that.

So really for a developer it would potentially be this simple;

    cp my-app.container $HOME/.config/containers/systemd && systemctl --user daemon-reload
Just to compare with docker-compose again.

Re: Make systemd better for Podman with Quadlet

#62

Post by bongobingo1 »

INTPenis wrote: post #54
bongobingo1 wrote: post #49

Earlier quoted context omitted.

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.

Yes, what I mean is, ideally kubelet files + podman would be a sufficient replacement. Not drop-in, but close enough, but it's not there ergonomically (yet?).

Re: Make systemd better for Podman with Quadlet

#63

Post by alexlarsson »

bonzini wrote: post #60
alexlarsson wrote: post #59

Earlier quoted context omitted.

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.

The generator doesn't do that atm no. Seems like it would be useful though.

On the other hand, I belive systemd would load override files for the generated .service file, although those can just override details on the systemd level, not the generated podman command.

Re: Make systemd better for Podman with Quadlet

#64

Post by bongobingo1 »

INTPenis wrote: post #61
alexlarsson wrote: post #59

Earlier quoted context omitted.

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

Thanks I just realized that. So really for a developer it would potentially be this simple; cp my-app.container $HOME/.config/containers/systemd && systemctl --user daemon-reload Just to compare with docker-compose again.

You should be able to use `systemctl --user link` which is a bit nicer than copying.

       link PATH...
           Link a unit file that is not in the unit file search path into the unit
           file search path. This command expects an absolute path to a unit file.
           The effect of this may be undone with disable. The effect of this command
           is that a unit file is made available for commands such as start, even
           though it is not installed directly in the unit search path. The file
           system where the linked unit files are located must be accessible when
           systemd is started (e.g. anything underneath /home/ or /var/ is not
           allowed, unless those directories are located on the root file system).

Re: Make systemd better for Podman with Quadlet

#65

Post by KronisLV »

dusanh wrote: post #44
IceWreck wrote: post #39

Earlier quoted context omitted.

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.

Can second this: I've seen companies that wanted the benefits of containers but didn't need orchestration yet do just fine with Docker Compose in prod.

Of course, when orchestration became a necessity, almost everyone looked in the direction of Kubernetes, as opposed to something like Nomad or Swarm, probably due to its popularity.

Re: Make systemd better for Podman with Quadlet

#66

Post by mhitza »

jacooper wrote: post #50

I still don't see how this more convenient than just using compose, or what do you gain for leaving it.

For my projects I use on system configured and deployed services without containers, and in production what my clients use (generally managed container orchestrators like ECS). If I were to use this on my servers, one benefit I can think of is that (as a Linux connoisseur) is that it would have separate logs per container which I can inspect with a unified command I use for all the other services (journalctl -u systemd-unit-name), whereas on projects where I've wrapped docker-compose with a systemd service I've had all logs dumped under a single service.

Re: Make systemd better for Podman with Quadlet

#67

Post by guipsp »

imiric wrote: post #47
pxc wrote: post #26

Earlier quoted context omitted.

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.

nspawn cannot download or update containers for one

Re: Make systemd better for Podman with Quadlet

#68

Post by jacooper »

mhitza wrote: post #66
jacooper wrote: post #50

I still don't see how this more convenient than just using compose, or what do you gain for leaving it.

For my projects I use on system configured and deployed services without containers, and in production what my clients use (generally managed container orchestrators like ECS). If I were to use this on my servers, one benefit I can think of is that (as a Linux connoisseur) is that it would have separate logs per container which I can inspect with a unified command I use for all the other services (journalctl -u syste…

Actually you cab see per container logs `docker compose logs -f {container name}`

Although of course it won't be integrated into journalctl.

Re: Make systemd better for Podman with Quadlet

#69

Post by trialect »

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros.

RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever version your distro has.

Re: Make systemd better for Podman with Quadlet

#70

Post by rhatdan »

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.

It works in the home directory. Just place the quadlet file in $HOME/.config/containers/systemd $ systemctl --user daemon-reload $ systemctl --user start QUADLETNAME.service

If you want this to work at boot, you need to do loginctl enable-linger $USERNAME

Post reply on HN