3 ms·

One of the nastiest aspects of migrating from docker to podman really is "what to do about docker compose?" coz there are three wildly divergent ways to answer

by pydry 5mo ago

One of the nastiest aspects of migrating from docker to podman really is "what to do about docker compose?" coz there are three wildly divergent ways to answer that all of which really suck under certain specific circumstances. Im no fan of docker and podman by itself is a step up but orchestration headaches are enough to ruin that.

PxldLtd 5mo ago
This is what stopped me from picking up Podman more, all our devs use Docker and have been writing compose files for years now. When the response at the time was "you're using Podman wrong, Quadlets are the hot stuff now" it just felt like too big a risk and commitment to jump to at the time. Have things settled more? Getting away from Docker is a bigger priority nowadays for us.
- pydry 5mo ago
  podman compose has shifted from "basically never works" to "if an existing YAML isnt too complex it works" but it's not a drop in replacement yet. i also want to stay the hell away from quadlets or any other software which tries to make me use systemd more.
figmert 5mo ago
> "what to do about docker compose?" I don't understand what you're asking here. The answer to that is probably nothing. That is unless you want: - systemd to manage your containers - You want to use K8s primitives (which are mostly compatible) I'm unsure what the 3rd method is you're talking about. The nice thing about Podman's compose API is you don't have to change anything (mostly). You can point all your docker tooling to Podman's socket, and it'll (mostly) magically work.
- pydry 5mo ago
  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.
  - stryan 5mo ago
    > * 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.
    - pydry 5mo ago
      >Systemd is a tool for managing services It's a tool for user age verification that happens to be something you can use to manage services. Did you miss my point about it being a filthy kitchen sink? >This is the same system state as using docker compose with docker One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash. This shit is also incredibly fiddly. Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have. Podman should stop trying to piggyback off docker if it's trying to be an alternative. >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 Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something. They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.

by pydry 5mo ago

PxldLtd 5mo ago

This is what stopped me from picking up Podman more, all our devs use Docker and have been writing compose files for years now. When the response at the time was "you're using Podman wrong, Quadlets are the hot stuff now" it just felt like too big a risk and commitment to jump to at the time. Have things settled more? Getting away from Docker is a bigger priority nowadays for us.

pydry 5mo ago
podman compose has shifted from "basically never works" to "if an existing YAML isnt too complex it works" but it's not a drop in replacement yet. i also want to stay the hell away from quadlets or any other software which tries to make me use systemd more.

figmert 5mo ago

> "what to do about docker compose?" I don't understand what you're asking here. The answer to that is probably nothing. That is unless you want: - systemd to manage your containers - You want to use K8s primitives (which are mostly compatible) I'm unsure what the 3rd method is you're talking about. The nice thing about Podman's compose API is you don't have to change anything (mostly). You can point all your docker tooling to Podman's socket, and it'll (mostly) magically work.

pydry 5mo ago
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.
- stryan 5mo ago
  > * 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.
  - pydry 5mo ago
    >Systemd is a tool for managing services It's a tool for user age verification that happens to be something you can use to manage services. Did you miss my point about it being a filthy kitchen sink? >This is the same system state as using docker compose with docker One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash. This shit is also incredibly fiddly. Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have. Podman should stop trying to piggyback off docker if it's trying to be an alternative. >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 Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something. They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.