4 ms·

I already was defining my infrastructure with docker-compose.yml files, and found out that podman-compose has a poorly documented feature that generates systemd

I already was defining my infrastructure with docker-compose.yml files, and found out that podman-compose has a poorly documented feature that generates systemd units. It doesn't use the now-deprecated podman feature, it writes the unit files itself, and I find the process much smoother than the podman feature anyway. To enable the feature: $ podman-compose systemd -a create-unit To register a systemd unit: $ podman-compose systemd -a register $ systemctl --user enable --now "podman-compose@$PROJECT_NAME" Updating looks like this: $ podman-compose pull $ systemctl --user restart "podman-compose@$PROJECT_NAME" ($PROJECT_NAME is usually the directory name.) Source code for the feature is here if you care to inspect it: https://github.com/containers/podman-compose/blob/f6dbce36181c44d0d08b6f4ca166508542875ce1/podman_compose.py#L1817-L1896 https://github.com/containers/podman-compose/blob/f6dbce3618... Admittedly, I'm still on podman 4.3.1, but I don't see any reason why this would stop working in later versions of podman.

kccqzy 3y ago
That's much more elegant than my hacky hand-written systemd unit (one-shot, remain after exit) to start podman containers.
ape4 3y ago
Its documented. If you just type `podman-compose` in the command line you get... usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args] [--env-file env_file] [-f file] [-p PROJECT_NAME] [--podman-path PODMAN_PATH] [--podman-args args] [--podman-pull-args args] [--podman-push-args args] [--podman-build-args args] [--podman-inspect-args args] [--podman-run-args args] [--podman-start-args args] [--podman-stop-args args] [--podman-rm-args args] [--podman-volume-args args] [--no-ansi] [--no-cleanup] [--dry-run] {help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill} ... command: {help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill} ... systemd create systemd unit file and register its compose stacks When first installed type `sudo podman-compose systemd -a create-unit` later you can add a compose stack by running `podman-compose systemd -a register` then you can start/stop your stack with `systemctl --user start podman-compose@<PROJ>`
- lolinder 3y ago
  Yeah, I eventually found that, but only after I finally stumbled upon someone referencing the feature in a GitHub issue. The --help is fine documentation for the people who have already installed the tool, but it doesn't help people like OP who just want a simple way to run multiple containers as a systemd unit and don't yet know that podman-compose has a solution. That's why I said "poorly documented" instead of "undocumented". It's there once you know where to look.
- tw04 3y ago
  That’s… not documentation. That’s a CLI helpfile. It’s better than nothing but also what is completely broken with the “move fast and break things” mindset.
  - notatoad 3y ago
    it's documentation enough to not call it an undocumented feature. the concern with truly undocumented functionality is that it's not included intentionally: either it's a bug or an experimental feature that could be removed or changed with no notice. a poorly-documented feature, on the other hand, will probably at least get a deprecation notice before it disappears
    - lolinder 3y ago
      > it's documentation enough to not call it an undocumented feature. Which is why I didn't call it that, I called it poorly documented.
  - scrozart 3y ago
    Sure looks like documentation to me, but I don't need pretty webpages. 'man' is more than sufficient for tools like these.
    - ClumsyPilot 3y ago
      How would I ever read this documentation without installing postman? Am I suppose to download and install every tool just to read about how it works?
notso411 3y ago
I thought docker compose was for local dev only and not meant to be used for production workloads?
- lolinder 3y ago
  I'm using podman-compose for my homelab, which is obviously fine. But even for small-scale single-node production use cases, I suspect that podman-compose with systemd doesn't have the same concerns as docker-compose does. Since you're registering the workload with systemd, it'll restart with the node as easily as any other service, and rootless containers are a big win for security. Where you can't keep using (podman|docker)-compose is when you have to scale up a service beyond a single node.
  - morelisp 3y ago
    You can keep using x-compose on several nodes, you just need e.g. ansible or salt on top of it. For many things this is still a local maximum compared to a K8s cluster or "just ssh in'.
    - jmnicolas 3y ago
      Why not docker swarm then?
      - morelisp 3y ago
        For a lot of the services I'm thinking of for this case the scheduling may be across multiple nodes but it may not be flexible - e.g. this is my preferred way to run things which need guaranteed local iops. So Swarm maybe helps with service discovery etc. but its main purpose is lost. I have a lot of complaints about Docker Swarm but they're either about its ownership issues or relatively minor (but - lots of minor) issues, if you want to use it it's fine. But you do still need an orchestration layer above it anyway.
- dboreham 3y ago
  Why?

kccqzy 3y ago

That's much more elegant than my hacky hand-written systemd unit (one-shot, remain after exit) to start podman containers.

ape4 3y ago

Its documented. If you just type `podman-compose` in the command line you get... usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args] [--env-file env_file] [-f file] [-p PROJECT_NAME] [--podman-path PODMAN_PATH] [--podman-args args] [--podman-pull-args args] [--podman-push-args args] [--podman-build-args args] [--podman-inspect-args args] [--podman-run-args args] [--podman-start-args args] [--podman-stop-args args] [--podman-rm-args args] [--podman-volume-args args] [--no-ansi] [--no-cleanup] [--dry-run] {help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill} ... command: {help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill} ... systemd create systemd unit file and register its compose stacks When first installed type `sudo podman-compose systemd -a create-unit` later you can add a compose stack by running `podman-compose systemd -a register` then you can start/stop your stack with `systemctl --user start podman-compose@<PROJ>`

lolinder 3y ago
Yeah, I eventually found that, but only after I finally stumbled upon someone referencing the feature in a GitHub issue. The --help is fine documentation for the people who have already installed the tool, but it doesn't help people like OP who just want a simple way to run multiple containers as a systemd unit and don't yet know that podman-compose has a solution. That's why I said "poorly documented" instead of "undocumented". It's there once you know where to look.
tw04 3y ago
That’s… not documentation. That’s a CLI helpfile. It’s better than nothing but also what is completely broken with the “move fast and break things” mindset.
- notatoad 3y ago
  it's documentation enough to not call it an undocumented feature. the concern with truly undocumented functionality is that it's not included intentionally: either it's a bug or an experimental feature that could be removed or changed with no notice. a poorly-documented feature, on the other hand, will probably at least get a deprecation notice before it disappears
  - lolinder 3y ago
    > it's documentation enough to not call it an undocumented feature. Which is why I didn't call it that, I called it poorly documented.
- scrozart 3y ago
  Sure looks like documentation to me, but I don't need pretty webpages. 'man' is more than sufficient for tools like these.
  - ClumsyPilot 3y ago
    How would I ever read this documentation without installing postman? Am I suppose to download and install every tool just to read about how it works?

notso411 3y ago

I thought docker compose was for local dev only and not meant to be used for production workloads?

lolinder 3y ago
I'm using podman-compose for my homelab, which is obviously fine. But even for small-scale single-node production use cases, I suspect that podman-compose with systemd doesn't have the same concerns as docker-compose does. Since you're registering the workload with systemd, it'll restart with the node as easily as any other service, and rootless containers are a big win for security. Where you can't keep using (podman|docker)-compose is when you have to scale up a service beyond a single node.
- morelisp 3y ago
  You can keep using x-compose on several nodes, you just need e.g. ansible or salt on top of it. For many things this is still a local maximum compared to a K8s cluster or "just ssh in'.
  - jmnicolas 3y ago
    Why not docker swarm then?
    - morelisp 3y ago
      For a lot of the services I'm thinking of for this case the scheduling may be across multiple nodes but it may not be flexible - e.g. this is my preferred way to run things which need guaranteed local iops. So Swarm maybe helps with service discovery etc. but its main purpose is lost. I have a lot of complaints about Docker Swarm but they're either about its ownership issues or relatively minor (but - lots of minor) issues, if you want to use it it's fine. But you do still need an orchestration layer above it anyway.
dboreham 3y ago
Why?