April 9, 20251 yr Author 7 minutes ago, iXNyNe said: I did indeed miss that. Is there a reason that the override and env files could not be kept together with the compose file? They were meant to be, thats why everything was originally stored projects directory. The problem was people kept wanting to use more complex compose stacks than the plugin was designed to handle. Things like git controlling their compose file, adding in additional files or a build directory, pulling a pre-existing stack from github, and hand editing files in the directory. The indirect option was added to allow things like that while keeping people from messing with the project folder and the files which the plugin creates and expects to manage itself.
April 9, 20251 yr I also now see (I'm testing stuff) that the ability to specify an envpath adds an additional env file rather than replacing the one stored with the compose file in the stack folder. I assume the file in the envpath is variables seen inside the container rather than variables used in the compose file. Clever. It does make the loop I posted above more complex to write though. I see how version controlling the stack folder could make it difficult for the plugin to manage the override file. It looks like all of the logic to generate the override file is in the frontend javascript, so if the compose file is modified without then using the frontend to start the stack the override file would not be updated. Maybe the logic to generate the override code could be moved to a backend script so that it could be triggered by various things such as userscripts? If that were done and the override were saved in the stack folder with the compose file it would open up a lot of control via userscripts. Here is an example rewrite of the loop: source "/boot/config/plugins/compose.manager/compose.manager.cfg" export PROJECTS_FOLDER if [[ -d "${PROJECTS_FOLDER}" ]]; then for project in "${PROJECTS_FOLDER}"/*; do if [[ -d "${project}" ]]; then project_name=$(sed -E 's/\W/_/g' <<<"$(basename "${project}")") if [[ -f "${project}/name" ]]; then project_name=$(sed -E 's/\W/_/g' "${project}/name") fi project_directory=${project} if [[ -f "${project}/indirect" ]]; then project_directory=$(cat "${project}/indirect") fi project_envargs=() if [[ -f "${project}/envpath" ]]; then project_envargs+=("-e" "$(cat "${project}/envpath")") fi if [[ -f "${project}/autostart" ]]; then autostart=$(cat "${project}/autostart") if [[ "${autostart}" == "true" ]]; then # Take an action if the container is set to autostart echo "Autostarting ${project_name}..." docker compose --project-directory "${project_directory}" --project-name "${project_name}" "${project_envargs[@]}" up --pull always --wait echo "Successfully autostarted ${project_name}" fi fi # Take an action every time the script is run # echo "Starting ${project_name}..." # docker compose --project-directory "${project_directory}" --project-name "${project_name}" "${project_envargs[@]}" up --pull always --wait # echo "Successfully started ${project_name}" fi done fi It's significantly more code now (accounting for the new things I've just learned) but a big issue would be with a project using an indirect folder the override would not be included at all (because it's not stored in the stack folder). Also as mentioned above, the only way currently to update the override is via the GUI, so if the compose file is updated and adds a new container there would not be labels in the override for it. Edited April 9, 20251 yr by iXNyNe
April 9, 20251 yr Author 6 minutes ago, iXNyNe said: If that were done and the override were saved in the stack folder with the compose file it would open up a lot of control via userscripts. For doing userscripting of compose projects i suggest looking into what information can be found in the container labels that docker compose adds to each container. If i remember correctly the paths to the compose files used in the project are stored in a container label. I think the labels contain enough information to reconstruct the command used to start the stack, I have never understood why compose makes you reference all the files for every command when the information needed is attached to every container in the stack. Also consider that you can add your own custom labels to containers (for dockerman containers as well) which can aid in identifying containers that need to be referenced in scripts.
April 9, 20251 yr 49 minutes ago, primeval_god said: For doing userscripting of compose projects i suggest looking into what information can be found in the container labels that docker compose adds to each container. If i remember correctly the paths to the compose files used in the project are stored in a container label. I think the labels contain enough information to reconstruct the command used to start the stack, I have never understood why compose makes you reference all the files for every command when the information needed is attached to every container in the stack. Also consider that you can add your own custom labels to containers (for dockerman containers as well) which can aid in identifying containers that need to be referenced in scripts. The override file I'm seeing looks like this: services: bw-export: labels: net.unraid.docker.managed: 'composeman' net.unraid.docker.icon: 'https://github.com/0neTX/UnRAID_Template/blob/main/bw-export/icon.png?raw=true' net.unraid.docker.webui: '' net.unraid.docker.shell: '' This is basically just enough to make the container(s) appear in unraid's web UI to be managed like any other container that was added through CA. If this is NOT included (ex: in the larger loop example I posted above, in a scenario where the stack folder is not default) everything will still work fine minus the web UI management via unraid's native docker manager. Again, if the plugin were modified to store the override in the stack folder it would resolve that small issue. Also as mentioned, if the override were in the stack folder it could complicate version control, but the easy fix is to .gitignore the override, or do something more sophisticated to keep the override managed within the version control. I know I'm probably sounding like a broken record, but having the override file in the stack folder eliminates the need to specify all of the files in the compose command. I'm all for it. If people want to use version control (I do, and I absolutely recommend others at least explore it) the easiest option is to .gitignore the override file.
April 9, 20251 yr Author 2 minutes ago, iXNyNe said: The override file I'm seeing looks like this: What I was referring to has nothing to do with the override file or my plugin at all, I was talking about labels added to containers by docker compose. Run docker inspect on a container that was started by compose and look at the labels section.
April 9, 20251 yr 8 minutes ago, primeval_god said: What I was referring to has nothing to do with the override file or my plugin at all, I was talking about labels added to containers by docker compose. Run docker inspect on a container that was started by compose and look at the labels section. OH, I see now, yes it adds these: "com.docker.compose.config-hash": "44380e4393ba2ca58583526942ef8b33b28153062dab1f0c37c2abb727a3bb20", "com.docker.compose.container-number": "1", "com.docker.compose.depends_on": "", "com.docker.compose.image": "sha256:9c124a7cca9a1ebc1c9a6640caf17e2a0acf51082bdd44c01ebd3d922bb5c2b6", "com.docker.compose.oneoff": "False", "com.docker.compose.project": "bw_export", "com.docker.compose.project.config_files": "/boot/config/plugins/compose.manager/projects/bw-export/docker-compose.yml,/boot/config/plugins/compose.manager/projects/bw-export/docker-compose.override.yml", "com.docker.compose.project.working_dir": "/boot/config/plugins/compose.manager/projects/bw-export", "com.docker.compose.service": "bw-export", "com.docker.compose.version": "2.29.2", (potentially more depending on if there's an env file) All of that is automatic and allows compose to understand how to manage the stack after creation. It's not needed to be included in the override file created by the plugin and should pretty much be ignored.
April 9, 20251 yr Author 15 minutes ago, iXNyNe said: OH, I see now, yes it adds these: "com.docker.compose.config-hash": "44380e4393ba2ca58583526942ef8b33b28153062dab1f0c37c2abb727a3bb20", "com.docker.compose.container-number": "1", "com.docker.compose.depends_on": "", "com.docker.compose.image": "sha256:9c124a7cca9a1ebc1c9a6640caf17e2a0acf51082bdd44c01ebd3d922bb5c2b6", "com.docker.compose.oneoff": "False", "com.docker.compose.project": "bw_export", "com.docker.compose.project.config_files": "/boot/config/plugins/compose.manager/projects/bw-export/docker-compose.yml,/boot/config/plugins/compose.manager/projects/bw-export/docker-compose.override.yml", "com.docker.compose.project.working_dir": "/boot/config/plugins/compose.manager/projects/bw-export", "com.docker.compose.service": "bw-export", "com.docker.compose.version": "2.29.2", (potentially more depending on if there's an env file) All of that is automatic and allows compose to understand how to manage the stack after creation. It's not needed to be included in the override file created by the plugin and should pretty much be ignored. Those labels are useful for scripting as well. Some of dockers cli commands include a filter option which can filter containers by label or the contents of a label. For containers started by compose you could use the contents of the labels to reconstruct the flags needed for a docker compose command (look at the --format option of docker inspect for how to easily pull values from specific labels). The fact that the docker compose command line doesnt natively do this for a lot of its commands (other than the commands that create a stack in the first place) has frustrated me for a while. Edited April 9, 20251 yr by primeval_god
April 12, 20251 yr I found a bug, when after starting the stack, individual Docker containers can be viewed for logs, but the botton "logs" always shows reconnecting How should I resolve this issue？ Edited April 12, 20251 yr by 摆月的渡猫
April 19, 20251 yr I'm trying to find out why my (single only) compose stack is not starting after a reboot. I have the autostart toggled on, and in syslog I can see Apr 19 03:25:49 <host> root: Starting compose stack: proxmox But I always have to start it by hand. I also noticed that the plugin reinstalled on the last reboot (possibly on every?) even though there was not update in months... but since it still tried to start the stack I suspect the issue somewhere else...
April 19, 20251 yr Author 8 hours ago, wambo said: I'm trying to find out why my (single only) compose stack is not starting after a reboot. I have the autostart toggled on, and in syslog I can see Apr 19 03:25:49 <host> root: Starting compose stack: proxmox But I always have to start it by hand. I also noticed that the plugin reinstalled on the last reboot (possibly on every?) even though there was not update in months... but since it still tried to start the stack I suspect the issue somewhere else... Yes plugin "reinstall" on every boot that's just how the unpaid plugin system works. You could try to activate additional logging from the compose plugins settings page. That might help you learn more, but based on that log snippet it looks like the plugin is trying to start the stack, so perhaps the stack itself is failing? Does the stack have any external dependencies, specifically on docker networks created outside of its compose file. If so look into the option to recreate the stack on star in the settings page.
April 21, 20251 yr On 4/19/2025 at 1:39 PM, wambo said: I'm trying to find out why my (single only) compose stack is not starting after a reboot. I have the autostart toggled on, and in syslog I can see Apr 19 03:25:49 <host> root: Starting compose stack: proxmox But I always have to start it by hand. What network is that stack on?
April 23, 20251 yr ok feel dumb right now - how do you delete a stack? edit: figured it out and maybe its a bug. I had two stacks with same name but with different cases. E.g.: strmgn and Strmgn - I had Strmgn running as compose up; but couldn't delete lower case strmgn. After deleting Strmgn - both had the delete icon. Edited April 23, 20251 yr by austin bug maybe?
April 26, 20251 yr On 4/10/2025 at 4:32 AM, iXNyNe said: Also as mentioned, if the override were in the stack folder it could complicate version control, but the easy fix is to .gitignore the override, or do something more sophisticated to keep the override managed within the version control. I version control both the stack files and override files. There is nothing in the override file that is dynamic, it can always be applied from a vcs copy. I am using the `plugins/compose-manager/project` folder and roll out my vcs content via ansible. works fine so far
April 27, 20251 yr On 4/23/2025 at 6:16 PM, austin said: ok feel dumb right now - how do you delete a stack? edit: figured it out and maybe its a bug. I had two stacks with same name but with different cases. E.g.: strmgn and Strmgn - I had Strmgn running as compose up; but couldn't delete lower case strmgn. After deleting Strmgn - both had the delete icon. you should also have the stack stopped it looks like your were trying to delete a running stack... note the green or red icon to the right of the stack... Click compose down and wait for the terminal screen to finish... Then hit the gear and the delete option should pop up... note this doesn't delete the data in the folders.... Edited April 27, 20251 yr by bmartino1 Data - typo
April 29, 20251 yr Hello! i have installed the docker compose plugin and tried to use it but as soon as i click update stack. keep getting this long message starting with unknown shorthand flag: 'f' in -f Is there a way to fix this?
April 29, 20251 yr Author 1 hour ago, Gorden said: Hello! i have installed the docker compose plugin and tried to use it but as soon as i click update stack. keep getting this long message starting with unknown shorthand flag: 'f' in -f Is there a way to fix this? On the compose manager settings page there should be an option to enable debug logging. If you enable that option then you should see the compose commands that are being run output to the log. That might provide more information for tracking down the issue.
April 29, 20251 yr root: ttyd -R -o -i '/var/tmp/compose_manager_action.sock' '/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh' '-cupdate' '-pgrafana_monitoring' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' '--debug' > /dev/null & root: '/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh' '-cupdate' '-pgrafana_monitoring' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' '--debug' root: /plugins/compose.manager/php/show_ttyd.php root: docker compose -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' -p grafana_monitoring images -q root: docker compose -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' -p grafana_monitoring pull root: docker compose -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' -p grafana_monitoring up -d --build I am so sorry if this is not the logs you are mentioning Edited April 29, 20251 yr by Gorden
April 29, 20251 yr 53 minutes ago, Kilrah said: Probably something wrong in your stack. I've tried it with portainer it works perfectly fine. But I really want docker compose to work I love the UI
April 29, 20251 yr Author 56 minutes ago, Gorden said: root: ttyd -R -o -i '/var/tmp/compose_manager_action.sock' '/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh' '-cupdate' '-pgrafana_monitoring' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' '--debug' > /dev/null & root: '/usr/local/emhttp/plugins/compose.manager/scripts/compose.sh' '-cupdate' '-pgrafana_monitoring' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' '-f/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' '--debug' root: /plugins/compose.manager/php/show_ttyd.php root: docker compose -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' -p grafana_monitoring images -q root: docker compose -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' -p grafana_monitoring pull root: docker compose -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.yml' -f '/boot/config/plugins/compose.manager/projects/grafana_monitoring/docker-compose.override.yml' -p grafana_monitoring up -d --build I am so sorry if this is not the logs you are mentioning Those commands look correct. What version of unRAID are you running?
April 29, 20251 yr 15 minutes ago, primeval_god said: Those commands look correct. What version of unRAID are you running? 7.1.0-rc3
April 29, 20251 yr Author 14 minutes ago, Gorden said: 7.1.0-rc3 What does the command "docker compose version" return?
April 29, 20251 yr I cant find it anywhere in the terminal log but when I check the project folder I see a file called version and when I check what's inside it says 1
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.