watchtower
watchtower copied to clipboard
Feature Request: Option to monitor containers in the same `docker-compose.yml` project (without having to label them)
Is your feature request related to a problem? Please describe
Right now adding containerrr/watchtower
to a docker-compose file without labelling each container individually is dangerous, as watchtower will restart all containers running on the host machine, even if they are in other docker-commpose projects that are completely unrelated to the current one.
Using --label-enable
and adding labels to all the containers is also cumbersome, as it's an additional 2 lines per container.
Think about a situation where a maintainer wants to offer watchtower on their project optionally. They could include it in the docker-compose.yml project commented out, and then instruct users to simply uncomment it if they want auto-updating. Currently they'd also have to uncomment/add label lines to all the containers below it as well, so it's not as clean as just uncommenting the top block and having minimalist unlabelled containers below.
Having a flag to automatically scope monitoring to containers in the current project would greatly simplify the UX. Users would no longer have to modify all the other containers to add com.centurylinklabs.watchtower.enable=true
labels to them, or be afraid of watchtower affecting other containers on their system.
Describe the solution you'd like
A new environment variable config option or CLI flag called --same-project
, or --project=AUTO
or something like that.
services:
watchtower:
image: containrrr/watchtower
command: --same-project
volumes:
- /var/run/docker.sock:/var/run/docker.sock
someapp: # this gets autoupdated
...
somethingelse: # this gets autoupdated
...
# but no other containers on the host machine get monitored, only the ones in this project
Describe alternatives you've considered
Labelling everything (cumbersome, verbose, error-prone for docker-noobs), or only running one compose project per machine (not a viable solution).
Proposed implementation
- add a
FilterByProject
function to https://github.com/containrrr/watchtower/blob/main/pkg/filters/filters.go
func FilterByProject(project projectName, baseFilter t.Filter) t.Filter {
if len(projectName) == 0 {
return baseFilter
}
return func(c t.FilterableContainer) bool {
return c.getLabelValue("com.docker.compose.project") == projectName
}
}
- autodetect current compose
projectName
on startup by checking the running watchtower container's owncontainer.getLabelValue("com.docker.compose.project")
(in addition, maybe allow the user to pass a project name to monitor manually, but it should default to the same project as the watchtower container if not specified) - update
filters.BuildFilter(names, enableLabel, scope, projectName)
to take aprojectName
argument to pass toFilterByProject
https://github.com/containrrr/watchtower/blob/master/pkg/filters/filters.go#L71
Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I'm torn on this one, as we've previously been quite insistent on the fact that we don't want to depend on other (optional) tools. @piksel, care to weigh in?
I don't think this requires any additional dependencies. It's just checking if a container label is present and if so, taking it into consideration.
The added command line flag would imply support though...
One way to integrate this in a generic way could be to allow the scope label to be customized. That way you could just tell watchtower to use com.docker.compose.project
as the scope label. This would effectively have the same effect as the propose change and also allow for other kinds of scope resolutions.
Would that be a good middle ground @simskij, @pirate?
Absolutely, that sounds great @piksel. We can just mention the the docs somewhere the trick to using the project label for scoping to a project.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Boop
Is your feature request related to a problem? Please describe
Right now adding
containerrr/watchtower
to a docker-compose file without labelling each container individually is dangerous, as watchtower will restart all containers running on the host machine, even if they are in other docker-commpose projects that are completely unrelated to the current one.Using
--label-enable
and adding labels to all the containers is also cumbersome, as it's an additional 2 lines per container.Think about a situation where a maintainer wants to offer watchtower on their project optionally. They could include it in the docker-compose.yml project commented out, and then instruct users to simply uncomment it if they want auto-updating. Currently they'd also have to uncomment/add label lines to all the containers below it as well, so it's not as clean as just uncommenting the top block and having minimalist unlabelled containers below.
Having a flag to automatically scope monitoring to containers in the current project would greatly simplify the UX. Users would no longer have to modify all the other containers to add
com.centurylinklabs.watchtower.enable=true
labels to them, or be afraid of watchtower affecting other containers on their system.Describe the solution you'd like
A new environment variable config option or CLI flag called
--same-project
, or--project=AUTO
or something like that.services: watchtower: image: containrrr/watchtower command: --same-project volumes: - /var/run/docker.sock:/var/run/docker.sock someapp: # this gets autoupdated ... somethingelse: # this gets autoupdated ... # but no other containers on the host machine get monitored, only the ones in this project
Describe alternatives you've considered
Labelling everything (cumbersome, verbose, error-prone for docker-noobs), or only running one compose project per machine (not a viable solution).
Proposed implementation
- add a
FilterByProject
function to https://github.com/containrrr/watchtower/blob/main/pkg/filters/filters.gofunc FilterByProject(project projectName, baseFilter t.Filter) t.Filter { if len(projectName) == 0 { return baseFilter } return func(c t.FilterableContainer) bool { return c.getLabelValue("com.docker.compose.project") == projectName } }
- autodetect current compose
projectName
on startup by checking the running watchtower container's owncontainer.getLabelValue("com.docker.compose.project")
(in addition, maybe allow the user to pass a project name to monitor manually, but it should default to the same project as the watchtower container if not specified)- update
filters.BuildFilter(names, enableLabel, scope, projectName)
to take aprojectName
argument to pass toFilterByProject
https://github.com/containrrr/watchtower/blob/master/pkg/filters/filters.go#L71
i want use file list but can't work :
version: "3"
services:
watchtower:
image: containrrr/watchtower
container_name: watchtower
environment:
- TZ=Asia/Shanghai
volumes:
- /var/run/docker.sock:/var/run/docker.sock
command: cat /volume2/Data/watchtower.list --cleanup --run-once
@wolfcdd, I don't know what you are trying to do, but create a new issue, since it doesn't seem related to this one.
This should actually be possible now using regex container matching.
If your project prefix is myproject
, you could run watchtower with:
services:
watchtower:
image: containrrr/watchtower
command: "^myproject-.*"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
Sweet! Is there a way to do it if you don't know the project name, something like --same-project
?
There use-case is that the project name is not always known in advance. For example, if the repo is a template that people clone and rename before using, or if a single docker-compose.yml is run from multiple different project folders with different names
we need a better way, why we have to manually add tags for all containers within a docker-compose? This feature should be set by default and clearly it should be quoted in the document.