I prefer compose merge because my “downstream” services can propagate their depends/networks to things that depend on them up the stream

There’s an env variables you set in .env so it’s similar to include

The one thing I prefer about include is that each include directory can have its own .env file, which merges with the first level .env. With merge it seems you’re stuck with one .env file for all in-file substitutes

whoa, I never knew that. Great tip!

I don’t like the auto update function. I also use a script similar to the one op uses (with a .ignore file added). I like to be in control when (or if) updates happen. I use watchtower as a notification service.

Sure. Below is an example playbook that is fairly similar to how I’m deploying most of my containers.

This example creates a folder for samba data, creates a config file from a template and then runs the samba container. It even has a handler so that if I make changes to the config file template it will cycle the container for me after deploying the updated config file.

I usually structure everything as an ansible role which just splits up this sort of playbook into a folder structure instead. ChatGPT did a great job of helping me figure out where to put files and generally just sped up the process of me creating tasks to do common things like setup a cronjob, install a package, or copy files around.

- name: Run samba
  hosts: servername

  vars:
    samba_data_directory: "/home/me/docker/samba"

  tasks:
  - name: Create samba data directory
    ansible.builtin.file:
      path: "{{ samba_data_directory }}"
      state: directory
      mode: '0755'

  - name: Create samba config from a jinja template file
    ansible.builtin.template:
      src: templates/smb.conf.j2
      dest: "{{ samba_data_directory }}/smb.conf"
      mode: '0644'
    notify: Restart samba container

  - name: Run samba container
    community.docker.docker_container:
      name: samba
      image: dperson/samba
      ports:
        - 445:445
      volumes:
        - "{{ samba_data_directory}}:/etc/samba/"
        - "/home/me/samba_share:/samba_share"
      env:
        TZ: "America/Chicago"
        UID: '1000'
        GUID: '1000'
        USER: "me;mysambapassword"
        WORKERGROUP: "my-samba-workergroup"
      restart_policy: unless-stopped

  handlers:
  - name: Restart samba container
    community.docker.docker_container:
      name: samba
      restart: true

Just forget about podman-compose and use simple Quadlet container files with Systemd. That way it is not all in the same file, but Systemd handles all the inter-relations between the containers just fine.

Alternatively Podman also supports kubernetes configuration files, which is probably closer to what you have in mind, but I never tried that myself as the above is much simpler and better integrated with existing Systemd service files.

Podman with systemd works better if you just do your podman run command with all the variables and stuff and then run podman generate systemd.

Podman compose feels like a band aid for people coming from docker compose. If you run podman compose and then do podman generate systemd, it will just make a systemd unit that starts podman compose. In my experience having all of the config stuff in the actual systemd unit file makes your life easier in the long run. Fewer config files the better I say.

You can use podman pods and generate the systemd file for the whole pod.

You’re probably thinking about systemd-nspawn. Technically yes they’re containers, but not the same flavour of them. It’s more like LXC than Docker: it runs init and starts a full distro, like a VM but as a container.

Nope, but it integrates very well with Podman.