logoalt Hacker News

pydryyesterday at 6:14 PM1 replyview on HN

the three options are:

* use systemd, red hat's favorite kitchen sink for handling everything from setting up sound services to mounting your home dir to logging so why not this too i guess.

* docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker.

* podman compose which would be the obvious solution if it didnt just plain suck.


Replies

stryanyesterday at 8:55 PM

> * use systemd, red hat's favorite kitchen sink for handling everything

Systemd is a tool for managing services. Containers are services. Why require an entirely separate bespoke service manager when you're already running one?

> * docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker.

This is the same system state as using docker compose with docker: you have a client program speaking to a backing daemon. Only difference here is the Podman service, being daemonless, only runs when needed (assuming you're setting up things the documented way by enabling the podman socket).

> * podman compose which would be the obvious solution if it didnt just plain suck.

Yeah I haven't had the best luck with it either. But part of the reason it's languished is that it makes more sense to just reimplement the Compose spec on the backend rather than re-invent the wheel and create a new compose client as well.

There's also the fourth option of writing Kubernetes yaml and applying that with `podman kube play`. Honestly this is probably closer to being the podman equivalent of docker compose but since it involves writing The Bad YAML (kubernetes) rather than The Good YAML (compose) most people don't use it.

show 1 reply