Environment variables for Compose -> Settings shared folders and File name?

  • Apologies if I've overlooked something in the docs or wanting to do something silly....


    Are there any default environment variables besides CHANGE_TO_COMPOSE_DATA_PATH for the default Docker folders on the Compose Settings screen? Also does a variable exist for the "current compose filename" to be used when building?


    "./" points to "/<location of compose files>/<filename>"

    "CHANGE_TO_COMPOSE_DATA_PATH" points to "/location of persistent container data"


    I like the ./ default including filename as a path however I cannot find the filename as a variable even though Compose must somehow have it available. I would like my persistent data to end up in "CHANGE_TO_COMPOSE_DATA_PATH/<filename>" to separate the data for example multiple Joomla instances (Joomla01, Joomla02, ...)

  • chente

    Hat das Thema freigeschaltet.
    • Offizieller Beitrag

    Are there any default environment variables besides CHANGE_TO_COMPOSE_DATA_PATH for the default Docker folders on the Compose Settings screen? Also does a variable exist for the "current compose filename" to be used when building?

    No. CHANGE_TO_COMPOSE_DATA_PATH is the only one that creates the plugin. You can create any additional environment variables you need using the global environment variables file and use them in any compose file.

    I like the ./ default including filename as a path however I cannot find the filename as a variable even though Compose must somehow have it available. I would like my persistent data to end up in "CHANGE_TO_COMPOSE_DATA_PATH/<filename>" to separate the data for example multiple Joomla instances (Joomla01, Joomla02, ...)

    ./ is a relative path of compose. That folder will be written to the shared folder that you have defined in Services>Compose>Settings in the Compose Files section


    If you want the persistent data to end up in the CHANGE_TO_COMPOSE_DATA_PATH folder, don't use relative paths, use that variable instead

    - CHANGE_TO_COMPOSE_DATA_PATH/Joomla01/config:/config

    Or the full route:

    - /srv/dev-disk-by-uuid-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Joomla01/config:/config

  • If you want the persistent data to end up in the CHANGE_TO_COMPOSE_DATA_PATH folder, don't use relative paths, use that variable instead

    - CHANGE_TO_COMPOSE_DATA_PATH/Joomla01/config:/config

    Or the full route:

    - /srv/dev-disk-by-uuid-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Joomla01/config:/config

    This solution does not allow me to reuse the compose file as every data path which includes the filename will need to be hardcoded. I'm trying to avoid that. Compose filename as a variable would be used for: part of data path, container name, (part of) database name, other places which "need" to be "generic" but unique. So having 1 variable in the compose file which will be substituted by <filename variable> would be a major benefit.

    • Offizieller Beitrag

    This solution does not allow me to reuse the compose file as every data path which includes the filename will need to be hardcoded. I'm trying to avoid that. Compose filename as a variable would be used for: part of data path, container name, (part of) database name, other places which "need" to be "generic" but unique. So having 1 variable in the compose file which will be substituted by <filename variable> would be a major benefit.

    Then you can use the other solution that I already gave you. Create an environment variable in the global environment variables file and use that variable in compose files. As explained here. https://wiki.omv-extras.org/do…l_environmental_variables

  • Then you can use the other solution that I already gave you. Create an environment variable in the global environment variables file and use that variable in compose files. As explained here. https://wiki.omv-extras.org/do…l_environmental_variables

    Thanks, I am using globals i.e. for DB_HOSTNAME but don't see how <compose filename> could be a global variable since then it would only be 1 value. I can see it as a variable at the file level but that defeats the purpose as then it's not based on <filename> but a manual entry.


    The only way <compose filename> as a variable would work is if the compose -> file -> check / compose -> file -> up commands would set the (as I understand: non existing) variable value before kicking off.


    But, apologies, I'm not an expert in OMV or Docker so probably I misunderstand something. Will need to rethink my issue and options .

    • Offizieller Beitrag

    I am using globals i.e. for DB_HOSTNAME

    How are you using global variables? Can you give an example or other information that clarifies this point?

    don't see how <compose filename> could be a global variable

    What do you mean by <compose filename>? If you are referring to the plugin configuration tab, that value is not an environment variable. It's just a shared folder that you define to store the compose files.

    I can see it as a variable at the file level

    What does file-level variable mean to you?

    I still don't understand what the problem is or where you're getting at. What exactly do you want to achieve? Are we just talking about the plugin or is Portainer also involved in all this?

  • chente Here's an example:



    What I'm trying to accomplish:


    which will not work with COMPOSE_FILENAME in the GLOBAL environt variables and putting it in the joomla01 environment (below the compose file) defeats the purpose of the compose being portable between multiple joomla's. So that is where the (sort of) assigning at check/create time comes in.


    Hope this is a little more clear.

    • Offizieller Beitrag

    If what you want is for the COMPOSE_FILENAME variable to have a value to use in the compose files, you just have to define it in the global environment variables file:

    COMPOSE_FILENAME=[THE_VALUE_YOU_WANT]

    You are assigning a variable to the container name. This is the first time I've seen that, I don't know if it will work but the first thing that comes to mind is that it won't. Probably docker compose doesn't support that, but I don't know.

    • Offizieller Beitrag

    This solution does not allow me to reuse the compose file as every data path which includes the filename will need to be hardcoded.

    Since the plugin doesn't allow you to spin up more than one container (or group of containers) with one compose file, I don't see why this is a problem.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Interesting, tested with

    COMPOSE_FILENAME=joomla01

    in global environment variables.


    version: "3.8"

    services:

    "${COMPOSE_FILENAME}":

    hostname: "${COMPOSE_FILENAME}"

    image: "joomla:5"

    container_name: "${COMPOSE_FILENAME}"

    environment:

    - PUID=${PUID}

    - PGID=${PGID}

    - TZ=${TZ}

    - "JOOMLA_DB_HOST=${DB_HOST}"

    - "JOOMLA_DB_NAME=${COMPOSE_FILENAME}"

    At first glance by checking: all substitutions work properly except services Additional property ${COMPOSE_FILENAME} is not allowed on the services tag.


    But I guess the answer is clear: What I would like is not currently possible. It would require pre-processing the compose file before handing it to over to docker.


    Thanks for your help and giving me insights.

    • Offizieller Beitrag

    But I guess the answer is clear: What I would like is not currently possible. It would require pre-processing the compose file before handing it to over to docker.

    That is what the plugin does for the CHANGE_TO_COMPOSE_DATA_PATH string. I don't have a problem adding more but I just want to know more about how it would be used.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • That is what the plugin does for the CHANGE_TO_COMPOSE_DATA_PATH string. I don't have a problem adding more but I just want to know more about how it would be used.

    As mentioned: I would like to use "available items" such as the COMPOSE_FILENAME to use as a "derived" variable (not Global, not Local) to use in compose files. In my case - and I assume many other users work the same way - the COMPOSE_FILENAME shows up again in the compose file. I hate strings which could/should be variables ;)


    For me: I'm relatively new to docker so for now this is the only item I've identified which would make my (and possibly others) life easier / compose files more flexible to use. And maybe there are other ways of accomplishing multiple unique containers based on the same compose file, haven't found that yet but cenrtainly my knowledge is lacking there....


    If you add a variable I would be very happy about it, if not - no hard feelings, for now I was checking the options.


    Thanks!

    • Offizieller Beitrag

    7.1.3 is in the repo. The CHANGE_TO_COMPOSE_NAME string will be substituted with the Name field in the compose file and environment variable file (not the global variable file since it doesn't make sense there).

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Works beautiful, also solves my volume assignment to a "proper" directory:

    volumes:

    - CHANGE_TO_COMPOSE_DATA_PATH/CHANGE_TO_COMPOSE_NAME:/var/www/html

    - ./php_user.ini:/usr/local/etc/php/conf.d/user.ini


    One happy customer :thumbup: :thumbup:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!