Mises à jour des images Docker

Dernière mise à jour : septembre 2026

Stratégie de gestion des versions d'images Docker sur le serveur cahute (192.168.1.9) : tags épinglés + notification des mises à jour via Diun + application manuelle. Objectif : maîtriser ce qui tourne, éviter les mises à jour surprises (notamment Nextcloud et les montées de version majeure).

Trois règles :

1. Tags épinglés : chaque service utilise une version précise (ex. v2.4.0), jamais un tag flottant (latest, stable). On sait exactement ce qui tourne et on peut reproduire.
2. Diun notifie : le conteneur Diun vérifie chaque jour les registres et envoie un email quand un nouveau tag apparaît dans le dépôt d'une image surveillée. Il n'applique rien lui-même.
3. Application manuelle : à réception d'une notif, on modifie le tag dans le docker-compose.yml, on relance, on vérifie.

Pourquoi pas d'auto-update (Watchtower) ? Une mise à jour automatique casse sans prévenir. Nextcloud exige les montées majeures une par une ; un latest qui saute deux versions met le service en rade. Le contrôle manuel est délibéré.

Contrepartie : une version épinglée fige aussi ses failles jusqu'à la prochaine mise à jour manuelle. D'où l'importance de traiter les notifs Diun sans trop tarder.

Par défaut, Diun ne surveille que le tag exact du conteneur qui tourne. Or le digest d'un tag épinglé (v10.6.6) ne change jamais : Diun répond unchanged tous les jours et n'envoie jamais rien, même quand une v10.7 sort.

C'est ce qui s'est produit d'août à septembre 2026 : aucune notif en six semaines, alors que quatre images avaient des versions plus récentes (dont deux majeures).

Correctif : le bloc defaults: watchRepo: true dans diun.yml (voir plus bas). Diun liste alors les tags du dépôt et notifie à l'apparition d'un nouveau.

Symptôme à reconnaître dans les logs :

Jobs completed added=0 failed=0 skipped=0 unchanged=6 updated=0

tous les jours sans exception, avec des images épinglées → watchRepo manquant.

État validé le 19 septembre 2026. Ces valeurs sont dans les docker-compose.yml respectifs.

• Compose : /mnt/stockage/docker/compose/diun/docker-compose.yml
• Config : /mnt/stockage/docker/compose/diun/diun.yml
• Données : /mnt/stockage/docker/data/diun (base de suivi des images)
• Réseau Docker : diun_net

services:
  diun:
    image: crazymax/diun:4.33.0
    container_name: diun
    command: serve
    restart: unless-stopped
    volumes:
      - /mnt/stockage/docker/data/diun:/data
      - /mnt/stockage/docker/compose/diun/diun.yml:/etc/diun/diun.yml:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - TZ=Europe/Paris
      - LOG_LEVEL=info
networks:
  default:
    name: diun_net

watch:
  workers: 10
  schedule: "0 8 * * *"          # vérification quotidienne à 8h00
  firstCheckNotif: false

defaults:
  watchRepo: true                # surveille les nouveaux tags du dépôt, pas seulement le tag courant
  maxTags: 10                    # les 10 tags les plus récents (limite les requêtes au registre)
  sortTags: semver
  includeTags:
    - ^v?\d+\.\d+\.\d+$          # versions stables uniquement (écarte latest, beta, -rc…)

providers:
  docker:
    watchByDefault: true         # surveille tous les conteneurs en cours d'exécution

notif:
  mail:
    host: 172.20.0.1             # relais SMTP local de cahute
    port: 25
    ssl: false
    insecureSkipVerify: false
    from: "beafrancois@beafrancois.fr"
    to: "beafrancois@beafrancois.fr"

Note SMTP : Diun passe par le relais mail local (172.20.0.1:25), sans identifiants. Plus aucun secret dans diun.yml.

Note watchByDefault : Diun surveille automatiquement tout conteneur qui tourne, sans label à ajouter. Il lit les tags réellement en cours d'exécution, pas les fichiers compose.

Note includeTags : la regex par défaut ne retient que les tags X.Y.Z ou vX.Y.Z. Une image dont les tags ont un suffixe (-alpine) ou un autre format doit recevoir un label spécifique, sinon elle n'est pas suivie.

lldap tourne sur la variante -alpine. Label ajouté dans /mnt/stockage/docker/compose/lldap/docker-compose.yml, au même niveau que image: :

services:
  lldap:
    image: lldap/lldap:v0.6.3-alpine
    labels:
      - "diun.include_tags=^v\\d+\\.\\d+\\.\\d+-alpine$"

Un label n'est pris en compte qu'après recréation du conteneur (docker compose up -d).

À réception d'un email Diun signalant une nouvelle version :

1. Identifier le service et la nouvelle version dans le mail.
2. Consulter le changelog upstream, surtout pour une version majeure : étapes de migration, breaking changes.
3. Sauvegarder les données si le changelog annonce une migration :

   docker stop <conteneur>
   cp -a /mnt/stockage/docker/data/<nom> /root/ir/<nom>-data.bak

4. Éditer le tag dans le docker-compose.yml de la stack concernée :

   nano /mnt/stockage/docker/compose/<stack>/docker-compose.yml

   Remplacer l'ancienne version par la nouvelle sur la ligne image:.

5. Appliquer (un service à la fois) :

   cd /mnt/stockage/docker/compose/<stack>
   docker compose up -d <service>

   Docker télécharge la nouvelle image et recrée uniquement le conteneur modifié.

6. Vérifier que le service tourne et répond :

   docker ps --format '{{.Names}}\t{{.Image}}\t{{.Status}}'
   docker logs --tail 30 <conteneur>

7. Mettre à jour la table « Versions épinglées » de cette page.
8. Nettoyer l'ancienne image : docker rmi <image>:<ancien tag>. Conserver la sauvegarde de données quelques jours.
9. En cas de problème, revenir en arrière : remettre l'ancien tag dans le compose et relancer docker compose up -d. Si une migration de base a eu lieu, restaurer d'abord la sauvegarde de données.

Ordre conseillé quand plusieurs mises à jour sont en attente : du moins risqué au plus risqué (mineures d'abord, majeures avec migration en dernier).

# Forcer une vérification Diun immédiate (sans attendre 8h)
docker restart diun && sleep 15 && docker logs diun --since 1m
 
# Voir le résultat de la dernière analyse
docker logs diun --tail 30
 
# Lister les versions réellement en cours d'exécution
docker ps --format '{{.Names}}\t{{.Image}}'
 
# Lister les images présentes (repérer les anciennes à supprimer)
docker images --format '{{.Repository}}:{{.Tag}}  {{.Size}}'
 
# Connaître la version d'une image qui tourne (si label présent)
docker inspect --format '{{index .Config.Labels "org.opencontainers.image.version"}}' <conteneur>

• Nextcloud est bare-metal, pas dans Docker — il n'est pas surveillé par Diun. Ses mises à jour se gèrent séparément (occ upgrade), une version majeure à la fois.
• Imaginary n'est pas surveillé : épinglé par digest et tags non semver. Tant qu'aucune règle Diun dédiée n'existe, vérifier manuellement de temps en temps.
• Uptime-Kuma v1 → v2 (septembre 2026) : migration irréversible de la base (agrégation des heartbeats). Procédure : arrêt, sauvegarde de data/uptime-kuma, changement de tag, puis ne jamais interrompre la migration, même si les logs semblent figés (vérifier l'activité via la date de kuma.db-wal et docker stats). Base de 246 Mo au moment de la migration. Image standard, pas -rootless.
• Après l'activation de watchRepo, le premier passage de Diun découvre tous les tags d'un coup (added=44) : effet ponctuel, normal.
• Au démarrage de Diun, si le DNS n'est pas encore disponible (reboot du serveur ou du routeur), le premier passage échoue (failed=6, server misbehaving). Sans gravité : le passage suivant de 8h fonctionne.
• Recréer uptime-kuma le redémarre : les monitors push (gitea-ioc-watch, cpu-load-watch) clignotent brièvement puis repassent au vert au prochain heartbeat cron (~5 min).
• docker rmi ne supprime réellement une image que si plus aucun tag ne pointe dessus : penser aux vieux tags latest / stable qui retiennent d'anciennes images.
• Sauvegardes avant modification : conservées dans /root/ir/.