We don’t really have a white paper or any marketing material on this, though we are working on a long term guide to capture Red Hat recommended best practices. In the meantime, I want to answer this simple question publicly:
- Red Hat generally recommends Kubernetes YAML instead of Compose, and we’re working towards a roadmap to deliver more and more Compose-like functionality with creating and consuming Kubernetes YAML with the podman-play/generate-kube functionality (image builds, application tear down, intiContainers, and expanded support for Kubernetes primitives in general)
- If you still want to use Compose, Red Hat/RHEL is neutral between podman-compose and docker-compose
- Red Hat/RHEL doesn’t deliver podman-compose nor docker-compose, it’s BYO.
- For any compose-tools, Red Hat recommends running it rootless. Here’s an older article which explains why running as root is bad: Why we don’t let non-root users run Docker in CentOS, Fedora, or RHEL
- The podman-compose utility is part of the github.com/containers project on GitHub and aligns itself closely with Podman. It was first compose-tool to work rootless. It interacts with the Podman CLI, partially because it was developed before the API, but more importantly because the fork/exec model offers some advantages over using a REST based API. For example, imagine you are compiling he Linux kernel in a container. With the fork/exec model you can use all of the data from the local directory, but with the API, you have to copy the context directory across the socket to do the build. The podman-compose community tests podman-compose, but it does not appear to have CI/CD.
- The docker-compose 1.X tool is a Python script provided by Docker and is more aligned with the Docker project, but totally works with the Podman socket/API. The Podman community does have upstream CI/CD testing for docker-compose both rootless and rootful. The downstream RHEL product does have docker-compose testing to ensure that there are no regressions.
- The docker-compose 2.X tools is a Golang binary provided by Docker and is more aligned with the Docker project. Today, docker-compose 2.X binary does not work with the Podman socket/API, but the team is investigating how to make it work. The new docker-compose 2.X utility expands the expands on the Docker API and utilizes new API calls which are part of BuildKit, so there’s some work to be done.
So, today there are two workable options: podman-compose which make CLI calls to Podman, and docker-compose 1.X using the socket/API driver (export COMPOSE_DOCKER_CLI_BUILD=0).
I’ll expand on this article as there are questions, and feel free to ask anything I didn’t cover below.
3 comments on “Should I Use Docker Compose or Podman Compose with Podman?”
I am trying to use a container with podman and podman-compose installed a packages. I am able to use podman to build, push and pull images, but unfortunately could not make the podman-compose work inside the container. Is there any way we can make podman-compose run inside the container?
I am using Jenkins on Kubernetes to run these and my repo iss here – https://github.com/mysticrenji/podman-experiments/. Appreciate any help on this. Thank you!
You usually need to run the container in which you want to run podman and/or podman-compose as a privileged container: https://www.redhat.com/sysadmin/podman-inside-container
Also, this might help: https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container