Feature Idea: Updating Docker Compose Stack

[signo1337]

Hello and thanks for this project! Been silently using it for a while :)

If I may, I'd like to suggest a further improvement: the option to update a stack, consisting of several docker containers. For example, Immich. Maybe this could be done by adding tags, or by manually moving all compose.yaml files to the docker-controller-bot directory (and then automatically checked by the controller container).

Cheers.

[dgongut]

Hello!
I would love to do something like this but unfortunately it is far from the scope of this project.

It could be considered for the future, but at present it is complicated tbh.

[fernandeusto]

Hi,

I just wanted to share an idea on how Docker Compose stack support could be implemented safely and automatically, in case this feature is revisited in the future.

Nowadays, many services rely on databases or Redis, which makes the bot non-functional if it only manages individual containers. Restarting or updating a single container can break the service because dependencies are not respected.

Possible implementation
• The bot could scan a specific directory on the server, for example /srv/stacks/.
• Each subfolder would represent a stack and contain its docker-compose.yml.
• With this setup, commands like /list_stacks could automatically show all available stacks, and /update or /restart could update/restart the entire stack in order using docker compose pull && docker compose up -d.

This way, compatibility with individual container management would be maintained, while also handling services with dependencies correctly.

Just wanted to leave this idea here in case the feature is revisited in the future.

[Cuetojuan]

Wow, very good idea. It would be great to have this.

[rupertgti]

Hi @dgongut In my case, reinforcing the proposed idea and in my specific case, with a stack of docker compose and pihole, and if the update is not done with docker-compose (docker compose -f docker-compose-pihole. yaml up -d --force-recreate), as happened to me yesterday, a Pihole image update causes it to start and stop continuously, and until it stops and I start it with Compose, it does not start correctly. It would be ideal to have the option of being able to start stacks, and this could be done with a few lines of additional code and some variables. Would you accept a PR for this? I'm sure AI could help us :D

[dgongut]

Hi @dgongut In my case, reinforcing the proposed idea and in my specific case, with a stack of docker compose and pihole, and if the update is not done with docker-compose (docker compose -f docker-compose-pihole. yaml up -d --force-recreate), as happened to me yesterday, a Pihole image update causes it to start and stop continuously, and until it stops and I start it with Compose, it does not start correctly. It would be ideal to have the option of being able to start stacks, and this could be done with a few lines of additional code and some variables. Would you accept a PR for this? I'm sure AI could help us :D

Hello! It would certainly be a huge improvement. I would love to do it now that I have the time, but at the moment I don't know how to approach it.

I imagine a folder called, for example, docker-compose, where I would store a folder for each ‘project’ and, inside those folders, a docker compose and some other configuration files or bot stuff.

But then I wonder, if someone wanted to modify it once it was created, would I send it to them via text and the user would send it back?

I would love to add some kind of versioning to this as well because it is quickly ‘fallible’.

If you want to make a PR, I would be happy to take a look at it without a doubt.

I want to make this improvement, but I still need to determine the approach... I am also suffering from the same thing and there are containers that I know I cannot update from the bot, unfortunately, because of this at this moment...

That of course will increase the version to 4 due to breaking changes with volumes 💯

[rupertgti]

@dgongut I have tried to make my small contribution. I tested it with a bot that I generated and ran it from my local machine. With the help of AI, as I mentioned, and the tests were satisfactory, here is the PR. It forced me to install docker-cli and docker-cli-compose because, as I describe in the PR, the Docker Python SDK did not allow me to manage the composes as I wanted.

The image increases by around 100 MB, but I think the advantage is significant. I know it's a disruptive change, and I welcome any suggestions. After all, I'm a noob in this world.

https://github.com/dgongut/docker-controller-bot/pull/75

[signo1337]

@dgongut I have tried to make my small contribution. I tested it with a bot that I generated and ran it from my local machine. With the help of AI, as I mentioned, and the tests were satisfactory, here is the PR. It forced me to install docker-cli and docker-cli-compose because, as I describe in the PR, the Docker Python SDK did not allow me to manage the composes as I wanted.

The image increases by around 100 MB, but I think the advantage is significant. I know it's a disruptive change, and I welcome any suggestions. After all, I'm a noob in this world.

https://github.com/dgongut/docker-controller-bot/pull/75

Hey there - while this looks promising, and I did not have the opportunity to test it yet: would it be possible maybe to use the name of the compose files not as hardcoded text, but as variable? This would allow to use (like in my case) another naming scheme, like just compose.yml.

Second thing, it is great that the changes provide a method to list and update stacks. Huge step forward. As far as I can tell, the logic does not check a stack for updates, but the single containers. Would, of course, be very nice to have per stack update notifications. Maybe would be straightforward to add, with the little helper called AI :)

Just my thoughts on this.

Thanks :)

[dgongut]

@dgongut I have tried to make my small contribution. I tested it with a bot that I generated and ran it from my local machine. With the help of AI, as I mentioned, and the tests were satisfactory, here is the PR. It forced me to install docker-cli and docker-cli-compose because, as I describe in the PR, the Docker Python SDK did not allow me to manage the composes as I wanted.

The image increases by around 100 MB, but I think the advantage is significant. I know it's a disruptive change, and I welcome any suggestions. After all, I'm a noob in this world.

https://github.com/dgongut/docker-controller-bot/pull/75

Wow thanks! It's a very good starting point. I will modify it a bit, but it is definitely a big step forward.

@dgongut I have tried to make my small contribution. I tested it with a bot that I generated and ran it from my local machine. With the help of AI, as I mentioned, and the tests were satisfactory, here is the PR. It forced me to install docker-cli and docker-cli-compose because, as I describe in the PR, the Docker Python SDK did not allow me to manage the composes as I wanted.
The image increases by around 100 MB, but I think the advantage is significant. I know it's a disruptive change, and I welcome any suggestions. After all, I'm a noob in this world.
https://github.com/dgongut/docker-controller-bot/pull/75

Hey there - while this looks promising, and I did not have the opportunity to test it yet: would it be possible maybe to use the name of the compose files not as hardcoded text, but as variable? This would allow to use (like in my case) another naming scheme, like just compose.yml.

I have no problem with that 👍

Thanks!

[rupertgti]

I will try follow the @signo1337 recommendations, let me check and push the changes ;)

[rupertgti]

Suggested changes added. I've been testing it for two hours, but I'm sure I've missed something. It would be ideal if someone with a different environment could test it.

[signo1337]

Suggested changes added. I've been testing it for two hours, but I'm sure I've missed something. It would be ideal if someone with a different environment could test it.

You are fast! Had no chance to test it yet. It is written that the logic adds labels - it does so by changing the compose file itself i assume? If yes, needs to mount the files rw (not ro, as I wanted to do - better be safe than sorry :D).

Great work, will test right away as soon as it is pushed to docker repo by @dgongut