watchtower icon indicating copy to clipboard operation
watchtower copied to clipboard

Feature Request: Option to monitor containers in the same `docker-compose.yml` project (without having to label them)

Open pirate opened this issue 3 years ago • 8 comments

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

  1. 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
	}
}
  1. autodetect current compose projectName on startup by checking the running watchtower container's own container.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)
  2. update filters.BuildFilter(names, enableLabel, scope, projectName) to take a projectName argument to pass to FilterByProject https://github.com/containrrr/watchtower/blob/master/pkg/filters/filters.go#L71

pirate avatar Apr 12 '21 20:04 pirate

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! 🙏

github-actions[bot] avatar Apr 12 '21 20:04 github-actions[bot]

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.

stale[bot] avatar Jun 16 '21 22:06 stale[bot]

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?

simskij avatar Jun 23 '21 22:06 simskij

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...

piksel avatar Jun 24 '21 10:06 piksel

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?

piksel avatar Aug 08 '21 17:08 piksel

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.

pirate avatar Aug 08 '21 18:08 pirate

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.

stale[bot] avatar Apr 16 '22 12:04 stale[bot]

Boop

pirate avatar Apr 16 '22 21:04 pirate

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

  1. 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
	}
}
  1. autodetect current compose projectName on startup by checking the running watchtower container's own container.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)
  2. update filters.BuildFilter(names, enableLabel, scope, projectName) to take a projectName argument to pass to FilterByProject 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 avatar Mar 03 '23 03:03 wolfcdd

@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.

piksel avatar Mar 03 '23 08:03 piksel

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

piksel avatar Mar 03 '23 08:03 piksel

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

pirate avatar May 24 '23 10:05 pirate

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.

zhqu1148980644 avatar Jun 22 '23 02:06 zhqu1148980644