Unable to run update for stacks managed by Portainer
Hi @LooLzzz, I wanted to give a try to this project since it looks really nice but the update doesn't work, can you please let me know what I'm doing wrong? My containers are all built using Portainer Stacks so I've provided this folder in the config and the docking-station was able to parse it to detect all containers and stacks but when I run update it ends with error - I tried three different containers.
Error:
stat /data/compose/111/docker-compose.yml: no such file or directory
Screenshot:
compose:
services:
docking-station:
image: loolzzz/docking-station
container_name: docking-station
restart: unless-stopped
ports:
- 3003:3000
volumes:
- /home/pavol/DockerVolumes/docking-station/config:/config
- /home/pavol/DockerVolumes/docking-station/data:/data
- /home/pavol/DockerVolumes/docking-station/logs:/logs
- /var/run/docker.sock:/var/run/docker.sock
- /etc/localtime:/etc/localtime:ro
# you should add mount points for each containers' docker-compose file you intend on update using this tool
# i usually put everything in a single neat folder under
# ⚠️ left stacks path == right stacks path (MUST)
- /home/pavol/DockerVolumes/portainer/compose:/home/pavol/DockerVolumes/portainer/compose
environment:
- WEB_PORT=3000
# - SERVER_PORT=3001
Manual run of the stat command with correct path:
$ stat /home/pavol/DockerVolumes/portainer/compose/111/docker-compose.yml
File: /home/pavol/DockerVolumes/portainer/compose/111/docker-compose.yml
Size: 850 Blocks: 8 IO Block: 4096 regular file
Device: 8,18 Inode: 8919737 Links: 1
Access: (0600/-rw-------) Uid: ( 1000/ pavol) Gid: ( 1000/ pavol)
Access: 2024-06-25 23:12:31.603785694 +0200
Modify: 2024-06-25 23:12:30.383765394 +0200
Change: 2024-06-25 23:12:30.383765394 +0200
Birth: 2023-03-18 22:56:15.828257230 +0100
Side notes:
- At first I was not able to get the WEB UI working because I changed the
WEB_PORTenv. variable toWEB_PORT=3003but it wasn't taken in the consideration and in the logs I still saw[WEB] - Local: http://b371e4ec3665:3000so I left it on 3000 and I usedports: 3003:3000which worked and I was able to see the GUI. Why are theWEB_PORTandSERVER_PORTin the example and can you add some comments how to use them if they are actually needed (which seems like not)? - Above error is not captured in any of the logs in the logs folder, it's visible only in the details of the GUI.
- The update wasn't marked as Failed but as Finished. It would be nice to let user know it didn't succeed and ideally expand the logs of the section where the error occured - for me expand the
docker compose up --pull alwayssection since the error occured there.
Thank you very much!
Hi,
I’m encountering the same issue, and I’ve noticed that it seems to be related to the file path. Specifically, the application expects the YAML file to be located at /data/compose/111/docker-compose.yml. However, with Portainer’s introduction of a feature called "Stack Versioning," a new YAML file is created each time the stack is redeployed. As a result, a new folder is created, and the compose file is then located at /data/compose/vx/111/docker-compose.yml, where vx represents the version number.
Thank you both for the detailed issue, I'll look into it.
- At first I was not able to get the WEB UI working because I changed the WEB_PORT env. variable to WEB_PORT=3003 but it wasn't taken in the consideration and in the logs I still saw [WEB] - Local: http://b371e4ec3665:3000 so I left it on 3000 and I used ports: 3003:3000 which worked and I was able to see the GUI. Why are the WEB_PORT and SERVER_PORT in the example and can you add some comments how to use them if they are actually needed (which seems like not)?
It's my bad,
This is a leftover from the very beginning of the project - before I even thought of publishing it to GitHub.
I'll remove it from the docker-compose.yml example.
--
- Above error is not captured in any of the logs in the logs folder, it's visible only in the details of the GUI.
- The update wasn't marked as Failed but as Finished. It would be nice to let user know it didn't succeed and ideally expand the logs of the section where the error occured - for me expand the docker compose up --pull always section since the error occured there.
It should throw an exception if one is encountered in the task thread 🤔
I'll look into it as well.
I had a similar issue with connecting Docking Station to Portainer, not sure if I should start a new issue but thought I'd add my troubleshooting steps here :)
I got my compose path like this:
docker inspect audiobookshelf | jq -r '.[0].Config.Labels["com.docker.compose.project.config_files"]'
Output:
/data/compose/17/v2/docker-compose.yml
So, I have my portainer_data mounted like this:
volumes:
- portainer_data:/data
With the mount like that, my Docking Station instance is able to correctly pull the image. However, when updating the image, an error occurs:
[+] Running 0/0
⠋ Container audiobookshelf Creating 0.0s
Error response from daemon: Conflict. The container name "/audiobookshelf" is already in use by container "3fa369519d7ae5259c97eb8788682450eb6e99349e5c0f3eeeb9825aa8f48964". You have to remove (or rename) that container to be able to reuse that name.
Weirdly, it then says that the container is successfully updated, even though it wasn't. Same issue as pavolholes?
I tried to recreate the command Docking Station might be executing with:
sudo docker compose -f /var/lib/docker/volumes/portainer_data/_data/compose/17/v2/docker-compose.yml up
However, I got the same container name conflict. I was able to fix it by also specifying the project name (which is also the stack name from Portainer). I retrieved the project name with:
docker inspect audiobookshelf | jq -r '.[0].Config.Labels["com.docker.compose.project"]'
Then, the command looked like this:
sudo docker compose -p audiobookshelf -f /var/lib/docker/volumes/portainer_data/_data/compose/17/v2/docker-compose.yml up
The output:
[+] Running 1/1
✔ Container audiobookshelf Recreated 0.7s
Attaching to audiobookshelf
So, maybe the project name also needs to be passed (since the dir doesn't contain the right name)? I didn't have any issues with the compose file not being found, though.
just +1 for me as well it was showstopper.
+1, Although my issue is that portainer leaves the config_files as blank
Container
"com.docker.compose.project.config_files": "",
"com.docker.compose.project.working_dir": "/data/compose/13/43038470f845ded7ba68b74e71613e04748d872d",
Stack
"configFiles": [
"."
],
And even if I try to call the api with "infer_envfile": false, it tries to update on the root of the project
[
{
"stage": "Starting"
},
{
"stage": "docker compose up --pull always",
"message": "read /app/docking-station-app: is a directory"
},
{
"stage": "docker image prune",
"message": "Total reclaimed space: 0B"
},
{
"stage": "Finished"
}
]
Facing the same issue, is there any solution / workaround?