Telegram-канал r_selfhosted - r/SelfHosted: Unsorted

r/SelfHosted

18 Dec 2023 05:09

Watchtower notifications via Shoutrrr (How-To)

I wanted to automate the updating of Docker containers on a schedule but couldn't find any "novice" how-to guides that covered everything. After some hours of trial & error I managed it but not before cursing several threads citing issues I'd ran in to but never updating with how that solved them. It inspired me to make a quick post to hopefully help the next person who goes searching.

\---**Watchtower** is the first piece, used to automate the updating of the Docker containers. It's fairly versatile re: the variables you can use to control its behavior. Here is a (*sanitized*) copy of my *docker-compose.yaml* file.

services:
watchtower:
image: containrrr/watchtower:latest
container_name: watchtower
environment:
- PUID=1000
- PGID=1000
- TZ=America/New_York
- WATCHTOWER_CLEANUP=true
- WATCHTOWER_INCLUDE_STOPPED=true
- WATCHTOWER_REVIVE_STOPPED=false
- WATCHTOWER_SCHEDULE=0 30 8 * * 1
- WATCHTOWER_NOTIFICATIONS=shoutrrr
- WATCHTOWER_NOTIFICATION_URL=discord://TOKEN@WEBHOOKID
command:
- bazarr
- nzbget
- overseerr
- plex
- prowlarr
- radarr
- sonarr
- unpackerr
volumes:
- /var/run/docker.sock:/var/run/docker.sock
network_mode: host
restart: unless-stopped

In the config above, I've asked Watchtower to:

1. **(WATCHTOWER\_CLEANUP)** Removes old images after updating a container to use a newer one.
2. **(WATCHTOWER\_INCLUDE\_STOPPED)** Updates stopped containers as well.
3. **(WATCHTOWER\_REVIVE\_STOPPED)** Will *NOT* start any stopped containers that have their image updated. If set to true it *would* start them regardless of their state.
4. **(WATCHTOWER\_SCHEDULE)** This follows Cron Job Formatting (*adding a 6th digit at the beginning to represent seconds*). I've configured mine to run every Monday at 8:30AM. Here is [**AN EXCELLENT SITE**](https://linuxiac.com/cron-job-format/) that explains Cron Job Format.
5. **(WATCHTOWER\_NOTIFICATIONS)** This config sends notifications of updated containers through a Discord channel (*via ANOTHER container called* ***Shoutrrr***). This was the trickiest part as every tutorial I found used Email. More on this piece below.
6. **(command)** By default Watchtower monitors *all* containers however I only wanted to target specific ones. It is very flexible in how it can be configured (*such as manual inclusions and exclusions via 'label' environment variables*). The approach above is what works best for my use case.

One additional argument was especially useful until I was confident the rest of my config. was correct **(WATCHTOWER\_MONITOR\_ONLY)**. With this argument set to **"true"** I was able to test my notifications before ever letting it run an actual image update.

I found [**THIS EXCELLENT TUTORIAL**](https://linuxiac.com/watchtower-automatically-update-docker-container-images/) that explains many useful arguments for customizing the behavior to your specific needs. [**HERE**](https://containrrr.dev/watchtower/arguments/) is also a complete list of *every* argument you can use.

\----

**Shoutrrr** (*another container*) was the second piece, used as a notification service for other apps to call. This was slightly trickier than anticipated. It's important to note **Shoutrrr** is *NOT* expected to run full time. **Watchtower** calls upon it (*like a CLI command*) whenever needed. My *docker-compose.yaml* file for **Shoutrrr** couldn't have been any simpler. The container simply needs to exist.

services:
shoutrrr:
image: containrrr/shoutrrr:latest
container_name: shoutrrr
environment:
- PUID:1000
- PGID:1000
- TZ=America/New_York
network_mode: host

**Shoutrrr** is extremely versatile in that it can be configured to proxy notifications through [**DOZENS OF SERVICES**](https://containrrr.dev/shoutrrr/v0.8/). In wanted to