Additionally, podman has nice systemd integration for such kube services, you just need to write a short systemd config snippet and then you can manage the kube service just like any other systemd service.
Altogether a very nice combination for deploying containerized services if you don't want to go the whole hog to something like Kubernetes.
Last I tried using the .kube files I ran into issues with specifying container networks (https://github.com/containers/podman/issues/12965).
This is sort of "fixed" by using a Quadlet ".kube" but IMO that's a pretty weak solution and removes the "here's your compose file, run it" aspect.
Recently (now that Deb13 is out with Podman 5) I have started transitioning to Podmans Quadlet files which have been quite smooth so far. As you say, its great to run things without all the overhead of kubernetes.
Claude recently hallucinated this for me:
[Container]
ComposeService=my-service
Yaml=/path/to/your/podman-compose.yaml
Can you really use "ComposeService" in the systemd unit file? I can't find any reference to it
You're absolutely right to question that - I made an error. There is no ComposeService directive in systemd or Quadlet.
It would be a nice best of both worlds...
How would you configure a cluster? I’m trying to explore lightweight alternatives to kubernetes, such as docker swarm, but I think that the options are limited if you must support clusters with equivalent of pods and services at least.
My setup is a bit clunky (having a Hetzner cloud instance as controller and a local server as a node throught Tailscale), from which I get an occasional strange error that k3s pods fail to resolve another pod's domain without me having to re-create the DNS resolver system pod, and that I so far failed at getting Velero backups to work with k3s's local storage providers, but otherwise it is pretty decent.
Yes. Though unless you have a very dynamic environment maybe statically assigning containers to hosts isn't an insurmountable burden?
So, unless you have a service that requires a fixed number of running instances that is not the same count as the number of servers, I would argue that maybe you don't need Kubernetes.
For example, I built up a Django web application and a set of Celery workers, and just have the same pod running on 8 servers, and I just use an Ansible playbook that creates the podman pod and runs the containers in the pod.
Just FYI, `podman generate systemd --files --name mypod` will create all the systemd service files for you.
https://docs.podman.io/en/latest/markdown/podman-generate-sy...
Quadlets now make it much easier to create the units by hand, and ‘ `podman generate systemd` is deprecated.
My usage is fairly basic though and I'm sure mileage varies, but for my basic web dev setup it's been perfect.
”just” is a big statement here. Performance between colima and OrbStack are from different planets.
Apple just released their own runtime so that is also worth inspecting.
And that's just half of it. Want to build an image on two native architectures (ARM64 and AMD64) and then make a multi-arch image out of them. Might blow someones mind on how complicated that is with 2025 docker technologies: https://docs.docker.com/build/ci/github-actions/multi-platfo...
I think the better long-term approach though is to use systemd user units for deployment, or the more modern approach of using Podman Quadlets. There's a bit of a learning curve, but these approaches are more native to the Podman platform, and learning how systemd services work is a great skill to have.
However, for single server deployments, where I don't need Kubernetes, I now exclusively use Quadlets to run apps and I couldn't be happier. It's a much nicer experience that using typical Docker/Podman setup. It feels integrated into the system.
The straw that broke the camels back was a bug in `podman compose` that funnily enough was fixed two hours ago[1]; if `service1` has a `depends_on` on `service2`, bringing down `service1` will unconditionally bring down `service2`, even if other services also depend on it. So if two separate services depend on a database, killing one of them will kill the database too.
Another incompatibility with Docker I experienced was raised in 2020 and fixed a few months ago[2]; you couldn't pass URLs to `build:` to automatically pull and build images. The patch for this turned out to be a few lines long.
I'm sure Podman will be great once all of these bugs are ironed out, but for me, it's not quite there yet.
[1]: https://github.com/containers/podman-compose/pull/1283
[2]: https://github.com/containers/podman-compose/issues/127
cyprien_g•3h ago
I have tried to find a good comparison between the two, but I find it hard to have a clear opinion on which one is best for me.
rockyj•3h ago
dizhn•3h ago
privatelypublic•2h ago
cmiles74•3h ago