[lolinder]

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/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.

[ape4]

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]

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]

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.

[scrozart]

Sure looks like documentation to me, but I don't need pretty webpages. 'man' is more than sufficient for tools like these.

[ClumsyPilot]

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?

[notatoad]

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]

> 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.

[kccqzy]

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

[notso411]

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

[lolinder]

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]

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]

Why not docker swarm then?

[morelisp]

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.

[lmeyerov]

It's great in prod. Doesn't make $ for companies marketing k8s iaac devops, so no one to advertise.

[dboreham]

Why?