[goku12]

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.

[1] https://github.com/docker/compose

[2] https://docs.podman.io/en/latest/markdown/podman-system-serv...

[3] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

[4] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...

[pydry]

>In addition, I prefer using docker 'contexts' instead of the DOCKER_HOST environment variable to set up the integration.

How on earth is that possible? Docker compose requires a daemon and the DOCKER_HOST var fo be set.

I always thought using it defeated the point of podman.

[goku12]

> 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.

[1] https://docs.docker.com/engine/manage-resources/contexts/

[2] https://docs.podman.io/en/stable/markdown/podman-system-serv...

[bootsmann]

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.