can you provide a quick explanation when you have a minute please?
chente was going to write up a guide but they are pretty simple.
Often, people user a variable from the env file or global env file to replace. you user ${uid} in those cases. That limits you to one user and isn't dynamic nor readable without looking at the env file. So, I added variables that look up the current value when writing the file.
If you want to use a shared folder named music for a path in your compose file, you would put ${{ sf:"music" }} where you wanted that path.
if you want to put a user named aaron's uid in your compose file, you would put ${{ uid:"aaron" }} where you would normally put the user's id (or a variable from the env file)
if you want to put the users group's gid in your compose file, you would put ${{ gid:"users" }} where you would normally put the group's id (or a variable from the env file)
if you want to put the timezone of the system in the compose file, you would put ${{ tz }} in place of something like "America/Chicago".
The string looks complicated because the search and replace code has to be very sure that the string is not something the user wants in the code and not replaced.
I'm sure chente will explain this better than I am.
The "Docker in OMV" document for OMV8 is in progress; I'm already modifying it to reflect these changes. The global variables section is being removed from the workflow due to these substitutions; I'll include it as a separate section at the end for advanced configurations. This is what I have so far. https://wiki.omv-extras.org/do…ustomize_the_compose_file
I have to say, this change was a great idea from Aaron. It greatly simplifies the process of creating a Compose file and its subsequent maintenance.
I just moved the Docker Document in OMV from "Documents in progress" to its final location --> https://wiki.omv-extras.org/doku.php?id=omv8:docker_in_omv
The document now reflects the new workflow, taking into account the substitutions the plugin can now make. I've finally removed the explanations about global environmental variables entirely. Since it is no longer necessary, I prefer not to be forced to maintain that text.
I've rewritten quite a few parts; I would appreciate help in identifying and correcting any errors.
would appreciate help in identifying and correcting any errors.
I went over it pretty fast but it looks good. You describe the substitution variables well.
the CHANGE_TO_COMPOSE_DATA_PATH is more or less redundant. I would consider making this point in the guide.
It can still serve a purpose. If you use it in all of your compose files, you can move every instance with one shared folder change on the Settings tab. There is almost no work to keep it in the plugin. So, it will just stay an option.
Good observation 
Regarding permissions, this is why the guide insists that each mapped volume should always point to a subfolder, never to the root of a shared folder. This is the only real precaution needed to avoid permission issues, and it is explicitly stated in the documentation.
If a container does not define a configuration subfolder by default, it is simply a matter of adding one to the host path, as you mentioned.
As for flexibility in volume mapping, I completely agree. The plugin’s substitution variables greatly simplify configuration and make it easier to adapt compose files to different systems without structural changes.
In the guide, I chose to present a single, clear, and proven method to avoid mixing approaches and confusing new users, but that additional level of flexibility is there for anyone who wants to take advantage of it.
Thanks for the feedback and for sharing your experience.
Don’t have an account yet? Register yourself now and be a part of our community!
