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.
>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?).
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
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).
The cool thing is you can also create .kube file which points to a kubernetes pod definition yaml. This also generates a service definition which takes care of running a full pod with all your containers.
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.
>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.
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.
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.
