Does diun check for a new version of an image or only the digest of a published tag?

[kaerbr]

I think I need some help understanding the capabilities of diun. 🙈

I know Watchtower, which notifies me and updates any containers running in my docker environment. So my use-case for my kubernetes cluster is to be notified if a new version of a image I'm running was published (nginx:1.23 -> nginx:1.24).
I was thinking diun is more or less the same thing for kubernetes.

So I deployed diun like described here: https://crazymax.dev/diun/providers/kubernetes/
But for the image of nginx I did not use the latest tag but image: nginx:1.23, which is outdatet by now (1.25 is the latest version as of now) :

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: nginx
spec:
  selector:
    matchLabels:
      run: nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: nginx
      annotations:
        diun.enable: "true"
    spec:
      containers:
        - name: nginx
          image: nginx:1.23
          ports:
            - containerPort: 80

So I expected diun to notify me / recognize that a new version (1.25) is available. But this did not happen:

Sat, 25 Nov 2023 14:34:48 CET INF Starting Diun version=v4.26.0
│ Sat, 25 Nov 2023 14:34:48 CET INF Configuration loaded from 5 environment variable(s)
│ Sat, 25 Nov 2023 14:34:48 CET WRN No notifier available
│ Sat, 25 Nov 2023 14:34:48 CET INF Database migration v2...
│ Sat, 25 Nov 2023 14:34:48 CET INF Cron triggered
│ Sat, 25 Nov 2023 14:34:49 CET INF Found 2 image(s) to analyze provider=kubernetes
│ Sat, 25 Nov 2023 14:34:52 CET INF New image found image=docker.io/crazymax/diun:latest provider=kubernetes
│ Sat, 25 Nov 2023 14:34:52 CET INF New image found image=docker.io/library/nginx:1.23 provider=kubernetes
│ Sat, 25 Nov 2023 14:34:52 CET INF Jobs completed added=2 failed=0 skipped=0 unchanged=0 updated=0
│ Sat, 25 Nov 2023 14:34:52 CET INF Cron initialized with schedule */1 * * * *
│ Sat, 25 Nov 2023 14:34:52 CET INF Next run in 26 seconds 183 milliseconds (2023-11-25 14:35:18.875524504 +0100 CET)
│ Sat, 25 Nov 2023 14:35:18 CET INF Cron triggered
│ Sat, 25 Nov 2023 14:35:18 CET INF Found 2 image(s) to analyze provider=kubernetes
│ Sat, 25 Nov 2023 14:35:20 CET INF Jobs completed added=0 failed=0 skipped=0 unchanged=2 updated=0
│ Sat, 25 Nov 2023 14:35:20 CET INF Next run in 53 seconds 258 milliseconds (2023-11-25 14:36:12.134112748 +0100 CET)

Is there a setting that I'm overseeing or is this use-case out of the scope of diun?

[janusn]

I have a similar issue.

I have been using watchtower on 3 machines. Due to the fact that many developers suggest diun over watchtower, I decided to give it a try.

I keep both diun and watchtower running simultaneously. Watchtower reports updates reliably but diun keeps missing some updates.

As watchtower can run in monitor only mode as diun does, I just don't understand the reasons developers dislike watchtower. (Yes, I have encountered bugs when watchtower recreate containers but I don't have any issue when running watchtower in monitor only mode.)

Particularly, with the following docker compose.yaml

---
services:
  metube:
    image: "ghcr.io/alexta69/metube"
    container_name: metube
    environment:
      UID: 3004
      GID: 5004
      UMASK: 002
      CUSTOM_DIRS: true
      XDG_CONFIG_HOME: "/config"
      STATE_DIR: "/config/state"
      TEMP_DIR: "/tmp"
      YTDL_OPTIONS_FILE: "/config/ytdl_options.js"
    deploy:
      resources:
        limits:
          memory: 4G
    volumes:
      - "./config:/config:rw"
      - "./cookies:/cookies:rw"
      - "/mnt/infinityloop:/downloads:rw"
      - "./config/yt-dlp/yt-dlp.conf:/etc/yt-dlp.conf:ro"
      - type: tmpfs # Optional: 4GB of memory, reduces SSD/SD Card wear
        target: /tmp
        tmpfs:
          size: 4294967296

    ports:
      - "8081:8081"
    restart: unless-stopped

It missed tag 2024-12-04 while I have 2024-11-19 installed.

[janusn]

The diun reported the metube image update this morning. Let me observe it for a longer period.