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.
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.
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.
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 with (essentially) process supervisors would want painless integration with systemd!
Also, in some ways I think this is simpler. Anyone who has used a reasonably modern Linux likely has some systemd experience. For local testing and 'orchestration', why rely on some additional one-off layer like docker-compose when the operating system's built-in process supervisor has all of the facilities you need?
Huh, this exactly what I’ve been looking for recently for some local/home-network/homelab setups, even down to the use of systemd-like ini/toml syntax.
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.
>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.
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.
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.
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.
It's a tool that replaces your usual long systemd unit file with a smaller systemd unit file without boilerplate. Seems like a perfectly good choice to me.
It seemed to me that the original target audience for this is users already familiar with systemd's unit syntax, so making these "unit files" use it as well was a sensible choice.
You can apparently use kubernetes YAML with a .kube target and podman will orchestrate the containers, service, volumes appropriately (on a single node). The only systemd config is a minimal boilerplate to point at the kubernetes YAML.
YAML is such a poor default choice for most things, that it's not odd at all to want to improve on that. In the same vein, people used to say that JSON is a bad format to use because everyone just uses XML.
RedHat basically sponsored the development of Systemd (among other things) so their full-throated support isn't surprising
also, fwiw, YAML is a data serialization format, not a configuration format. people who use YAML and pretend it's a config file format are either lazy, incompetent, or both.
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.
Just wait till you see how hard it is to use the arch repos on puppy linux!
The Redhat folks develop software for Redhat. The software will run fine on any other distro with up to date kernels and systemd versions, but there's no guarantee that it does because it's not Redhat's business to work on the OS of their competitors.
If Debian and Ubuntu are too slow to update, that's completely out of Redhat's control. They chose to pin an older version of a piece of software developed in a much more rolling release schedule, it's up to them to fix the incompatibilities their choice introduced. The whole point of an LTS is that you use one older version for several years.
I expect Podman 4.4 to be available in Ubuntu 23.10, as 23.04 is a bit close (current repos list 3.4.4, the version used in 22.04 and 22.10). If Ubuntu can't move fast enough to include it in 23.10, then that's Ubuntus's fault more than anything. You should also consider that Canonical sells their own competing container ecosystem (Charmed/microk8s) to businesses so not supporting their competitors' software may be intentional.
If you want Podman 4.4 but don't want to use Redhat distributions, Arch and derivatives already have it ready to go. You'll also get much more recent versions of the Linux kernel and systemd as a nice bonus.
I mean, Arch has 4.4.1-12 in their repo right now [0]. I don't really get the argument, why is it the software developers fault that distros have old packages? Of course LTS versions of Ubuntu wouldn't have bleeding edge software, that would defeat the purpose.
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.
I agree, today still better to use Docker that is more mature, Podman is half baked, lack of relevant features and moreover still very Red Hat centric, so a sort of lock-in.
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.
asabil|3 years ago
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.
bravetraveler|3 years ago
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.
cpitman|3 years ago
creshal|3 years ago
theteapot|3 years ago
Docker?
PenguinCoder|3 years ago
pxc|3 years ago
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 with (essentially) process supervisors would want painless integration with systemd!
Also, in some ways I think this is simpler. Anyone who has used a reasonably modern Linux likely has some systemd experience. For local testing and 'orchestration', why rely on some additional one-off layer like docker-compose when the operating system's built-in process supervisor has all of the facilities you need?
thayne|3 years ago
dilyevsky|3 years ago
quickthrower2|3 years ago
messe|3 years ago
INTPenis|3 years ago
bongobingo1|3 years ago
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.
hosh|3 years ago
riedel|3 years ago
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.
davewood|3 years ago
config_yml|3 years ago
I’m going to try this tomorrow, because containers are so useful, but I just don’t want to deal with K8s on anything that I run myself.
dicknuckle|3 years ago
MuffinFlavored|3 years ago
mike_hearn|3 years ago
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
zephyros|3 years ago
[1]: https://github.com/containers/ansible-podman-collections
bonzini|3 years ago
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...
Klasiaster|3 years ago
candiddevmike|3 years ago
viraptor|3 years ago
thayne|3 years ago
In fact, I'd prefer if the tools you mentioned used something else besides yaml.
0xC0ncord|3 years ago
qbasic_forever|3 years ago
darthrupert|3 years ago
userbinator|3 years ago
throwaway892238|3 years ago
also, fwiw, YAML is a data serialization format, not a configuration format. people who use YAML and pretend it's a config file format are either lazy, incompetent, or both.
trialect|3 years ago
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.
jeroenhd|3 years ago
The Redhat folks develop software for Redhat. The software will run fine on any other distro with up to date kernels and systemd versions, but there's no guarantee that it does because it's not Redhat's business to work on the OS of their competitors.
If Debian and Ubuntu are too slow to update, that's completely out of Redhat's control. They chose to pin an older version of a piece of software developed in a much more rolling release schedule, it's up to them to fix the incompatibilities their choice introduced. The whole point of an LTS is that you use one older version for several years.
I expect Podman 4.4 to be available in Ubuntu 23.10, as 23.04 is a bit close (current repos list 3.4.4, the version used in 22.04 and 22.10). If Ubuntu can't move fast enough to include it in 23.10, then that's Ubuntus's fault more than anything. You should also consider that Canonical sells their own competing container ecosystem (Charmed/microk8s) to businesses so not supporting their competitors' software may be intentional.
If you want Podman 4.4 but don't want to use Redhat distributions, Arch and derivatives already have it ready to go. You'll also get much more recent versions of the Linux kernel and systemd as a nice bonus.
doix|3 years ago
[0] https://archlinux.org/packages/community/x86_64/podman/
rhatdan|3 years ago
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.
bravetraveler|3 years ago
LTS doesn't only mean long term stability - long term suck applies, too.
The only thing preventing podman from working is the age of their source, which is a deliberate choice -- LTS
hnarn|3 years ago
Can you elaborate on why such a categorical statement is true?
What about https://mpr.makedeb.org/packages/podman ?
f2hex|3 years ago
jacooper|3 years ago
mhitza|3 years ago
unknown|3 years ago
[deleted]