Home Watchtower watching for container updates
Post
Cancel

Watchtower watching for container updates

With watchtower you can update the running version of your containerized app simply by pushing a new image to the Docker Hub or your own image registry. Watchtower will pull down your new image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially.

Depemdemcies

For everything to work out you will need to make sure that you have the following requirements:

If this is the case, we can carry on creating the pi-hole service.

It is recomended to clone the GitHub repo home-lab for the most up to date configuration of this service.

Setting up portainer container

Create a docker-compose.yml and copy the data below into it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: '3.9'

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes: 
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/localtime:/etc/localtime:ro
    command:
      --schedule "0 5 * * * *"
      --rolling-restart
      --cleanup
      # --debug         # Use for debugging

Commen arguments

Here are some other usefull arguments that can be used to manage the Watchtower instance. For more arguments visit the Watchtower website.

Scheduling

Cron expression in 6 fields (rather than the traditional 5) which defines when and how often to check for new images. Either --interval or the schedule expression can be defined, but not both. An example: --schedule "0 0 4 * * *".

1
2
3
4
5
            Argument: --schedule, -s
Environment Variable: WATCHTOWER_SCHEDULE
                Type: String
             Default: -

Rolling restart

Restart one image at time instead of stopping and starting all at once. Useful in conjunction with lifecycle hooks to implement zero-downtime deploy.

1
2
3
4
5
            Argument: --rolling-restart
Environment Variable: WATCHTOWER_ROLLING_RESTART
                Type: Boolean
             Default: false

Revive stopped

Start any stopped containers that have had their image updated. This argument is only usable with the --include-stopped argument.

1
2
3
4
            Argument: --revive-stopped
Environment Variable: WATCHTOWER_REVIVE_STOPPED
                Type: Boolean
             Default: false

Cleanup

Removes old images after updating. When this flag is specified, watchtower will remove the old image after restarting a container with a new image. Use this option to prevent the accumulation of orphaned images on your system as containers are updated.

1
2
3
4
5
            Argument: --cleanup
Environment Variable: WATCHTOWER_CLEANUP
                Type: Boolean
             Default: false

Filter by enable label

Update containers that have a com.centurylinklabs.watchtower.enable label set to true.

1
2
3
4
            Argument: --label-enable
Environment Variable: WATCHTOWER_LABEL_ENABLE
                Type: Boolean
             Default: false

Wait until timeout

Timeout before the container is forcefully stopped. When set, this option will change the default (10s) wait time to the given value. An example: --stop-timeout 30s will set the timeout to 30 seconds.

1
2
3
4
            Argument: --stop-timeout
Environment Variable: WATCHTOWER_TIMEOUT
                Type: Duration
             Default: 10s

Filter by disable label

Do not update containers that have com.centurylinklabs.watchtower.enable label set to false and no --label-enable argument is passed. Note that only one or the other (targeting by enable label) can be used at the same time to target containers.

Wait until timeout

Timeout before the container is forcefully stopped. When set, this option will change the default (10s) wait time to the given value. An example: --stop-timeout 30s will set the timeout to 30 seconds.

1
2
3
4
5
            Argument: --stop-timeout
Environment Variable: WATCHTOWER_TIMEOUT
                Type: Duration
             Default: 10s

Managing the compose stack

The following commands should be run in the same directory as the docker compose file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Start the compose stack
# ---
sudo docker compose up -d

# Stop the compose stack
# ---
sudo docker compose down

# Rebuild / restart the compose stack
# ---
sudo docker compose up -d --force-recreate

# View the compose stack logs
# ---
sudo docker compose logs portainer


⚙️ If you see something that needs to be fixed, this documentation is open source! Feel free to open an issue here.

⭐ If you enjoied the post I would appreciate a star on GitHub

This post is licensed under CC BY 4.0 by the author.