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