Support podman as a backend

[westurner]

Is your feature request related to a problem? Please describe.
I would like to use docker-compose and existing docker-compose.yml files with podman
(which supports socketless and rootless builds and containers, which are preferable for certain configurations where centralized logging and monitoring through the docker socket is not as important and systemd services are sufficient).

Describe the solution you'd like
Specify an environment variable or a CLI option to call podman instead of docker:

DOCKER_COMPOSE_DRIVER=podman
docker-compose --driver=podman

(And implement whichever interface/driver/adapter/plugin pattern is appropriate to call podman with subprocess instead of making socket API requests)

Where podman doesn't support a docker (swarm,) feature, just throw an error message that links to this or the meta-issue for podman support.

Describe alternatives you've considered

• There's podman-compose, which is not at feature parity and really shouldn't need to be separately maintained.

  • https://github.com/containers/podman-compose
    • https://github.com/containers/podman-compose/blob/devel/podman_compose.py
      • This could be an interface.

• There's kompose, which could be useful with e.g. k3s (which recently gained SELinux support) for smaller dev setups where uptime during upgrades is not a priority.

Additional context
Podman: https://github.com/containers/libpod :

Supporting docker-compose. We believe that Kubernetes is the defacto standard for composing Pods and for orchestrating containers, making Kubernetes YAML a defacto standard file format. Hence, Podman allows the creation and execution of Pods from a Kubernetes YAML file (see podman-play-kube). Podman can also generate Kubernetes YAML based on a container or Pod (see podman-generate-kube), which allows for an easy transition from a local development environment to a production Kubernetes cluster. If Kubernetes does not fit your requirements, there are other third-party tools that support the docker-compose format such as kompose and podman-compose that might be appropriate for your environment.

"Refactor to be called as an interface implementation from docker-compose"
containers/podman-compose#126

[westurner]

Is this now almost as simple as just specifying a different socket URI?

From containers/podman-compose#126 (comment) :

FYI the Podman apiv2 aims to be compatible with the docker API https://podman.io/blogs/2020/01/17/podman-new-api.html

[westurner]

I don't think that I understand your question?

• Docker depends upon LXC and the Docker Socket REST API.
• Podman depends upon LXC and now the Docker Socket REST API (instead of the podman v1 API)
• Docker-compose depends upon the Docker Socket REST API.

[ndeloof]

docker-compose does not rely on an external tool, but uses the Docker Engine API. Any alternative runtime to offer the same "Moby" API will be fine (as long as it's actually compatible :P), just need to set DOCKER_HOST or a docker context accordingly

[westurner]

Would this be a helpful example for the docs? So that the docs mention how to use docker-compose with the docker-compose API compatible podman API?

sudo systemctl start podman.socket
curl -H "Content-Type: application/json" --unix-socket /var/run/docker.sock http://localhost/_ping

# AFAIU, this isn't necessary?

DOCKER_HOST=/var/run/docker.sock  docker-compose ps

export DOCKER_HOST=/var/run/docker.sock 
docker-compose ps
docker-compose logs

• https://www.redhat.com/sysadmin/podman-docker-compose

[ndeloof]

As a company, would you expect Docker Inc to host documentation explaining how to use competitor's runtime, even if - from a plain open-source point of view - this is all about implementing a public API?
Haven't checked, but I assume Podman has already documentation on "how to replace docker engine for all docker related client-side tooling"