OpenMediaVault-Plugin-Developers / openmediavault-compose

openmediavault plugin for docker-compose
18 stars 6 forks source link

Feature Request: Global Override #40

Open dariusaurius opened 4 days ago

dariusaurius commented 4 days ago

Hi,

I would really love to see a possibility to give all my compose files a value, e.g. a label for whats-up-docker, or set my restart policy without needing to edit it for each container every time. Something like this:

services:
    app:
        labels:
          wud.tag.include: ^\d+$$
          wud.watch.digest: true

I'm aware this could be a little bit tricky, since the serivce name can be or is individual for each container. Maybe a wildcard could be used, e.g.:

services:
    *:
        labels:
            wud.tag.include: ^\d+$$
            wud.watch.digest: true

This wildcard would open so much possibilties:

services:
   *-conf2:
        labels:
            wud.tag.include: *
            wud.watch.digest: false

This could be the game changer for the overwrite feature :-)

Regards

ryecoaaron commented 3 days ago

So you would want a wildcard replaced by the same string in all places? Other than the service name, couldn't you just use global environment variables?

dariusaurius commented 15 hours ago

It goes a little further... let's say you have 20 compose files without the labels at all, you would first have to edit all the files and services in them to get the labels before you could change them with a global environment.

As I understand the override can merge compose files a the start of docker compose up. With a global override it could merge the global.override with all compose files.

Let's say the potential global override has this content:

services:
    *:
        restart: always
        labels:
            wud.tag.include: ^\d+$$
            wud.watch.digest: true

And a compose file has this content:

services:
    nginx:        
        image: nginx
        ports:
            - 80:80
        volumes:
            - /var/run/docker.sock:/tmp/docker.sock:ro
    db:
        image: postgres:17
        volumes:
             - db:/var/lib/postgres

So basically while the compose file is started up, it would apply the override to start this configuration and merge them:

services:
    nginx:        
        image: nginx
        restart: always
        ports:
            - 80:80
        volumes:
            - /var/run/docker.sock:/tmp/docker.sock:ro
        labels:
            wud.tag.include: ^\d+$$
            wud.watch.digest: true
    db:
        image: postgres:17
        restart: always
        volumes:
             - db:/var/lib/postgres
        labels:
            wud.tag.include: ^\d+$$
            wud.watch.digest: true

Not sure if this can be done with the global.env without altering the compose file before it can read the variable, and apply even the section lable.

Thanks for reading my request and best regards

ryecoaaron commented 14 hours ago

It can't be done with global.env without adding to existing compose files. But this isn't really an override. It is an intelligent merge. Not only would it have to enumerate the services in your example but it would have to determine if elements were already there. And that is just this example. If someone wanted to do an intelligent merge with volumes or ports or something else, this could be a really complicated change.

Right now, the plugin is just doing a simple search and replace of one string (CHANGE_TO_COMPOSE_DATA_PATH) at the time saltstack is writing the compose file to disk. If you and/or someone else wants to come up with the code, I would think about adding it. I am just too busy with non-OMV projects right now to even look into this one more.

dariusaurius commented 14 hours ago

Do you think this is possible to achieve with salt and jinja? I have experience with jinja, from Home Assistant, but salt would be new for me

ryecoaaron commented 13 hours ago

jinja is doing the work now - https://github.com/OpenMediaVault-Plugin-Developers/openmediavault-compose/blob/main/srv/salt/omv/deploy/compose/files/compose_yml.j2

I guess it would just depend on how many cases it covered.