[tekeous]

Podman was good when it supported systemd unit files, so I could auto start and auto update containers, even entire pods with systemd.

Then they removed that in favor of Quadlet. Now in order to do a single container I can do a unit file, but for a pod, I need to use a Kubernetes cluster definition.

Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable to access mapped directories.

So what is it, Podman? Should I just use Kubernetes? Should I just make dedicated directories for everything instead of mapping logical places for things?

[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>`

[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?

[bonzini]

> unlike Docker their containers bow to SELinux definitions,

That's a bug in docker. If your system isn't configured for SELinux, disable it.

Also the systemd files generated by podman-generate-systemd are just executing "podman start containername", you can write them on your own easily but (unlike e.g. docker-composr) the containers are black boxes pretty much.

The advantage of quadlet is that the definition of the container is declared in the .container file; before I used to write the podman run command line manually in a handwritten systemd unit, and quadlet is a big improvement in that respect and can be an alternative to docker-compose (with advantages and disadvantages).

[INTPenis]

>That's a bug in docker. If your system isn't configured for SELinux, disable it.

I feel obligated to say that you should set it to permissive mode, never disable SElinux.

    sudo setenforce 0

[bravetraveler]

Long time fan, yet - agreed.

I keep forgetting this transition happened until I try to 'podman generate systemd [...]'

This is rare because I wrote an Ansible role to do this in a way that feels nice.

Anyway, it really feels like podman lost the mark. I've already subscribed to the unit file maintenance/relationship planning thing. Just let me use the generator. I don't care about Quadlets or how they might be better.

[emerongi]

> Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable to access mapped directories.

Add the following to containers.conf if you don't want to deal with it:

   [containers]
   label=false

If you don't like podman's default security level, there is usually a way to turn things off.

[sph]

The only times I had issues with SELinux and podman, it was because I forgot to add the z flag to the volume:

    podman run -v .:/app:z image

This only happens locally as files in your home have strict security rules, never had any issue on a CentOS server.

[Cyph0n]

I recently migrated over to NixOS which treats systemd as the source of truth for everything, including containers. I found this model extremely intuitive, but it was difficult to apply this to Docker Compose without a lot of manual migration. So I ended up writing a tool that handles this for you — it converts your Compose files into a NixOS config that can be interpreted and managed natively.

https://github.com/aksiksi/compose2nix

[jay-aye-see-key]

This is a cool idea. Two questions:

Arion can wrap docker-compose and run as a project or part of a nixos config. Did you come across Arion before creating this, and have you compared them?

I had a brief look through your examples and it doesn’t look like compose2nix implements docker-compose’s network per compose file. Is this something you want to add?

[BossingAround]

> Plus, unlike Docker their containers bow to SELinux definitions

Isn't that great? You want SELinux if you deploy containers on prod.

> I have repeatedly struggled with containers unable to access mapped directories.

Use the `z` or `Z` flag, e.g. `podman run -v mydir:podman_dir:z nginx` to get SELinux labels updated automatically (and temporarily) by podman.

[freedomben]

That was a cool feature (I didn't realize it was gone, that's unfortunate), although I felt the generated code wasn't super great, and if the container is stateless (excepting what's stored in volumes of course) then it's so simple to write your own systemd unit file that I just do that now. I wrote it once and pretty much just copy/paste it when needed, changing the podman run command for image names, port numbers, volumes, etc. For example, here's what I use for Jellyfin. Just drop at `/etc/systemd/system/jellyfin.service`:

    [Unit]
    Description=Jellfyin
    After=NetworkManager-wait-online.service
    
    [Service]
    Restart=always
    ExecStart=/usr/bin/podman run --rm --volume '/srv/jellyfin/config:/config:Z' --volume '/srv/jellyfin/cache:/cache:Z' --volume '/media/media:/media:Z' --publish '8096:8096' --publish '8920:8920' --publish '1901:1900/udp' --publish '7359:7359/udp' --name 'jellyfin' 'docker.io/jellyfin/jellyfin:latest'    
    ExecStop=/usr/bin/podman stop -t 5 jellyfin ; /usr/bin/podman rm -f jellyfin
    
    [Install]
    WantedBy=local.target

Note: You can also just `s/podman/docker/g` and reuse the same service file with docker, which is really convenient for systems where you have no choice

[rcarmo]

This. Quadlet wasn't really needed and just complicated matters for me, so I went back to docker-compose.

[hinkley]

I’ve been complaining about our OPs people pushing Colima over podman and now you’re making me think my podman info is outdated. Ouch.

[madspindel]

You can generate Kubernetes yaml files with podman kube generate. Then you can use systemd to run the generated files: https://www.redhat.com/sysadmin/kubernetes-workloads-podman-...

[runiq]

AFAIK podman either already supports pods in quadlet container files, or will in the near future. https://github.com/containers/podman/pull/20762

[starttoaster]

> So what is it, Podman? Should I just use Kubernetes?

If you're talking about a production system for any business larger than a 10 person tech startup; yeah, probably. Alternatively there's Docker Swarm and Hashicorp Nomad. Though Swarm is not nearly as flexible, it's just easy to use. And Nomad... well, let's just say I've been paying closer attention to Hashicorp's build processes in their open source repos like Packer and Vault as of late and they do some stuff that seems shady to me so use at your own risk.

[asmor]

`podman generate systemd` is still there, and I see no reason you couldn't use it. it's just a bunch of podman commands wrapped in a unit file, no magic.

feels like a lot more cruft than quadlets to me though.

[cpuguy83]

Docker does use selinux policies.

Mapping directories from the host requires that you change selinux labels on those files so that the container process can access the files. That's just how selinux works.

[INTPenis]

What are you talking about? Quadlet generates ordinary systemd service units with podman commands. Isn't that what you were using?

It's just a simplified layer ontop of those old systemd units.