Live data from Hacker News

Make systemd better for Podman with Quadlet

redhat.com

81–88 of 88 posts

Re: Make systemd better for Podman with Quadlet

#81
post #78

Earlier quoted context omitted.

https://podman.io/getting-started/installation "The podman package is available in the official repositories for Ubuntu 20.10 and newer." "CAUTION: The Kubic repo is NOT recommended for production use. Furthermore, we highly recommend you use Buildah, Podman, and Skopeo ONLY from EITHER the Kubic repo OR the official Ubuntu repos. Mixing and matching may lead to unpredictable situations including installation conflic…

You originally said that: > podman creators do not give a damn about how their binary should be run on different linux distros Just to play the devil's advocate here, maybe I missed something so I'll try and be verbose and start from the beginning: Podman is developed by Red Hat, and they have chosen to build for, and support RHEL (and implicitly derivatives thereof). There are no "supported" binaries available for $…

Recently I came about a couple of projects on github where they are making a binary available through docker AND the so called 'bare-metal' (which expression I hate, because up until recently [ok-ok, couple of years] there wasn't any other method than just run it as it is on the hardware/os), meaning you can run it on any linux distro (without docker of course), so open source developers certainly can make software that runs on any (or at least most of) linux distros. Especially when there's a big corp. behind them.

What's more is podman especially is about running software on different distros easily.

What I'm expecting from RH is make software (if that is free and opensource and about running other software without the hassle of packaging, etc.) that can be - sort of easily - used on other distros too. But just to be clear, this expectation is not only towards RH.. it is towards any other linux distros. In this special case it is RH indeed.

The whole idea behind podman is great (especially not having to have a root daemon to run containers), but if they want it to succeed they need a proper and easy way for other linux distro users to use it.

and yes, they also said in https://github.com/containers/podman/discussions/13097#discu...: "if I want to get Real Wise. Only Supported Podman comes from Red Hat Enteprise Linux and perhaps SUSE. (Maybe Oracle Linux)"

> Doesn't it follow then that the responsibility for making Podman available on Ubuntu falls on either Canonical or volunteers that use Ubuntu, and not Red Hat?

As mentioned in https://github.com/containers/podman/discussions/13097, node.js is just an example, but they could do it. Why wouldn't redhat do it with podman?

> Otherwise, you could blame any developer on any software for not making their code available on any distro, and perhaps even any OS.

Yes you could. And in certain cases - like this one - you should too.

Re: Make systemd better for Podman with Quadlet

#82
post #60

Earlier quoted context omitted.

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.

Yeah, my usecase was to override Network or Expose directives.

Re: Make systemd better for Podman with Quadlet

#83

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 versi…

Podman is a community project. Anyone can setup repos to update any distribution. Many distributions are managing versions of Podman. OpenSuse, Fedora, Centos, RHEL, Debian, Arch all supply updates. There is also the Kubic project in which community members are providing versions for Ubuntu.

Red Hat developers primary work in the upstream. There are also Red Hat engineers that work on packaging for Fedora, RHEL and Centos Stream, as well as Clients for Windows and Mac. We work with Fedora to provide CoreOS images for Windows and Mac.

Red Hat engineers work with the community for support of the other distributions, but they don't guarantee or support for all other distributions or versions of distributions.

Re: Make systemd better for Podman with Quadlet

#84
post #56

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 servic…

For those curious why you may want this: consider your service relies on /somelocation

Make that a mount unit in systemd (free from lines in /etc/fstab) and now you can accurately lay out your service's requirement/dependency on this filesystem.

I know systemd gets flack for overreach 'as an init system', but there's a reason - initialization doesn't happen in a vacuum.

Services need filesystems, networks, etc to matter.

Re: Make systemd better for Podman with Quadlet

#85

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.

Can you run your stuff on port 80/443 like this?

Re: Make systemd better for Podman with Quadlet

#86

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

tl;dr it wasn't before, but now it is.

It is true that there once was a disclaimer on the compose homepage that stated that the product was not recommended for production workloads.

Given that disclaimer no longer exists, along with the existence of [1], leads me to advocate using it in production.

[1] https://docs.docker.com/compose/production/

Re: Make systemd better for Podman with Quadlet

#87
post #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.

Podman is also Red Hat do they win either way.

Anyway, I think that Podman is the mature Docker and tries to fit much better into the linux/unix-y way of doing things. Especially, being daemonless allows to integrate into systemd, etc. the way it should, and makes for a mature integration of containers into the ecosystem.

Re: Make systemd better for Podman with Quadlet

#88

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

Other comments. You can also use docker-swarm with just a single master node.
Post reply on HN