It’s funny to me that this post calls out Podman-Compose as “not actively maintained” with its last commit being 5 months ago, then turns around to recommend Podlet (whose last commit was…5 months ago) as an alternative.
Podlet can be useful and helpful, but ultimately it doesn’t support many of the features of Docker Compose and doesn’t always provide a clean translation. In particular, Podlet doesn’t support stacking multiple yaml files (e.g., -f docker-compose.yml -f docker-compose.override.yml)
If you're a fan of compose files, then you can use Docker's own compose application [1] with Podman [2]. It seems that the compose cli controls the engine using its socket. Both podman and docker engines have the almost same API. I'm using this approach since podman-compose didn't work as expected. Docker-compose is usually installed as a plugin for the docker client. However, I use it as a standalone application for use with Podman. In addition, I prefer using docker 'contexts' instead of the DOCKER_HOST environment variable to set up the integration.
Also, note that if plain quadlets aren't powerful enough for you, quadlets [3] and plain podman [4] also support running a limited set of kubernetes manifests.
Added later: I still haven't figured out how podman handles the 'restart' option in compose files, since podman doesn't have a supervisor daemon. Meanwhile, I know that the 'healthcheck' option depends on systemd timers. Automatic health check didn't work for me when using Podman on a non-systemd distribution (Gentoo). However, I could trigger the health check manually and that would lead to the rest of the setup running to completion.
> How on earth is that possible? Docker compose requires a daemon and the DOCKER_HOST var fo be set.
Docker contexts [1] is an alternative to DOCKER_HOST variable. It may have been inspired by kubectl contexts (just a speculation). It's more principled than the variable, in my opinion.
> I always thought using it defeated the point of podman.
Podman doesn't have a persistent daemon like Docker's that monitors the running containers. However, taking inputs over a socket is a useful feature in Docker. Podman achieves this without a persistent daemon using systemd socket units [2]. Whenever a request is received at the socket, systemd spins up podman to serve it. Podman keeps listening on the socket and then exits after a short period of inactivity (like 5s). So it's not quite comparable to what Docker does.
It doesn't require the daemon afaik, you can set the DOCKER_HOST to the podman.sock and it will work more or less transparently. Fedora has a podman-docker package that configures this.
Commit date isn’t very accurate for showing something is maintained, but can show if something is unmaintained. 5 months doesn’t mean something is unmaintained. Try 2 years. It does raise concern though. 5 months absolutely doesn’t show something is maintained though. There are so many reasons to update a repo of something that’s unmaintained and only the recent and awful IMHO GitHub archive feature prevents this.
Podlet can be useful and helpful, but ultimately it doesn’t support many of the features of Docker Compose and doesn’t always provide a clean translation. In particular, Podlet doesn’t support stacking multiple yaml files (e.g., -f docker-compose.yml -f docker-compose.override.yml)