Le problème : des images Docker qui vieillissent en silence
Sur un VPS en production, les conteneurs Docker tournent souvent pendant des semaines ou des mois sans être mis à jour. Ce n'est pas de la négligence : il n'y a simplement aucun signal. L'image nginx:latest que vous avez tirée en janvier est toujours là en septembre, avec les vulnérabilités qui ont été corrigées entre-temps.
Le coût de ne rien faire est documenté : les CVE non patchées dans les images de base sont l'un des vecteurs d'entrée les plus courants sur des infrastructures Docker auto-hébergées. La mise à jour manuelle — se connecter au VPS, faire docker pull, recréer le conteneur — est la pratique par défaut. Elle est aussi la moins fiable : on reporte, on oublie, on ne fait que les services « importants ».
Deux outils ont émergé pour structurer ce processus : Watchtower, qui automatise la mise à jour elle-même, et Diun (Docker Image Update Notifier), qui envoie une alerte quand une nouvelle image est disponible et laisse l'action à votre pipeline. Ils ne font pas la même chose, et confondre les deux philosophies peut coûter une panne de production.
Watchtower : mise à jour automatique, mais archivé depuis fin 2025
Watchtower surveille vos conteneurs en cours d'exécution, interroge les registries à intervalles réguliers, et dès qu'une nouvelle image est disponible, il tire le nouveau tag, arrête le conteneur existant et le recrée avec les mêmes options — volumes, variables d'environnement, réseau. Tout cela sans intervention humaine.
Ce qu'il fait concrètement :
- Polling configurable par durée (toutes les N secondes) ou par expression cron
- Prise en charge des registries privés avec authentification
- Mode WATCHTOWER_NOTIFICATIONS pour recevoir des alertes sans effectuer de mise à jour
- Filtrage par label Docker pour inclure ou exclure certains conteneurs
Le risque en production est réel. Si une image :latest introduit un changement d'API incompatible ou un comportement cassant, Watchtower recréera votre conteneur avec cette image — sans test, sans fenêtre de maintenance, potentiellement à 3h du matin. Le conteneur redémarre avec la mauvaise version, et la découverte se fait via une alerte de monitoring ou un appel de support.
Point de situation important : le dépôt GitHub de Watchtower a été archivé par ses mainteneurs fin 2025. Il est désormais en lecture seule. La dernière version publiée est la v1.7.1. Le projet reste fonctionnel et les images Docker existantes continuent de tourner, mais il ne recevra plus de correctifs de sécurité, de nouvelles fonctionnalités ni de support pour les versions futures de Docker. Pour un outil dont le rôle est de mettre à jour vos images, l'ironie n'est pas négligeable.
Pour les environnements de développement ou les homelabs où la commodité prime sur la stabilité, Watchtower reste un choix légitime. Pour la production, son archival renforce le constat qui existait déjà : la mise à jour automatique sans pipeline de validation est un risque opérationnel.
Watchtower en mode notify-only
Si vous utilisez déjà Watchtower et souhaitez désactiver les mises à jour automatiques tout en conservant les notifications, passez la variable WATCHTOWER_MONITOR_ONLY=true. Le conteneur surveille les images et envoie des alertes, mais n'agit pas. C'est une configuration de transition utile si vous migrez vers Diun.
Diun : alertes seulement, vous gardez la main
Diun (Docker Image Update Notifier) prend le problème par l'autre bout : il surveille vos images sur les registries et vous envoie une notification quand une nouvelle version est disponible. Il n'agit pas. Vos conteneurs continuent de tourner inchangés — la décision de mettre à jour reste dans votre pipeline.
Licencié sous MIT, Diun est activement développé : la version la version actuelle a été publiée récemment. Le projet couvre un large spectre de sources (Docker, Containerd, Kubernetes, Swarm, Nomad, Dockerfile, fichier de configuration) et de canaux de notification.
Canaux de notification supportés :
- Email, Slack, Telegram, ntfy, Gotify
- Microsoft Teams, Discord, webhooks génériques
- Healthchecks.io pour surveiller le watcher lui-même
Ce que Diun ne fait pas :
- Il ne tire jamais d'image
- Il ne redémarre jamais un conteneur
- Il ne modifie aucun fichier de configuration
Cette philosophie est précisément ce qui le rend adapté à la production. Quand Diun vous signale qu'une nouvelle image est disponible, vous pouvez déclencher votre pipeline de déploiement habituel — avec ses tests, sa sauvegarde préalable et sa fenêtre de maintenance. Vous restez dans une posture maîtrisée.
Diun est également compatible avec les stacks gérées par des outils comme Portainer, Coolify ou Dokploy : il observe les images sans interférer avec leur orchestration.
Quand choisir l'un ou l'autre
Faites défiler le tableau
| Contexte | Watchtower | Diun |
|---|---|---|
| Environnement de dev / staging | Acceptable (commodité) | Surdimensionné |
| Prod avec images taguées (pas :latest) | À éviter — recrée sur le même tag | Recommandé |
| Prod avec dépendances d'API tierces | Risqué sans test préalable | Recommandé |
| Homelab / services personnels | Pratique | Correct si alertes actives |
| Stack gérée par Coolify, Dokploy, Portainer | Conflit possible avec l'orchestrateur | Recommandé |
| Projet sans pipeline de déploiement | Acceptable avec monitor-only | Recommandé avec ntfy/Slack |
Installer Diun sur un VPS : exemple pratique
L'installation de Diun se fait en quelques minutes avec Docker Compose. L'exemple suivant surveille tous les conteneurs du socket Docker local et envoie une notification via ntfy.
Déployer Diun sur votre VPS
Créer le fichier docker-compose.yml
Créez un répertoire dédié et le fichier Compose :
mkdir -p /opt/diun && cd /opt/diunContenu du fichier
docker-compose.yml:services: diun: image: crazymax/diun:latest restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data:/data environment: - TZ=Europe/Paris - LOG_LEVEL=info - DIUN_WATCH_WORKERS=20 - DIUN_WATCH_SCHEDULE=0 */6 * * * - DIUN_PROVIDERS_DOCKER=true - DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true - DIUN_NOTIF_NTFY_ENDPOINT=https://ntfy.example.com - DIUN_NOTIF_NTFY_TOPIC=diun-updatesRemplacez
ntfy.example.compar l'URL de votre instance ntfy (auto-hébergée sur le même VPS ou externe).Activer la surveillance par label (optionnel)
Par défaut, Diun surveille tous les conteneurs. Pour un contrôle plus fin, passez en mode label :
- DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=falsePuis ajoutez le label sur les conteneurs à surveiller :
labels: - "diun.enable=true"Cette approche est utile pour exclure les conteneurs systèmes (proxies, bases de données) des notifications, et ne surveiller que les apps applicatives.
Démarrer et vérifier
docker compose up -d docker compose logs -f diunDiun effectue une première passe de découverte au démarrage. Les logs confirment les images détectées et le prochain cycle de surveillance. Une notification de test peut être déclenchée avec :
docker compose exec diun diun notif testDéclencher la mise à jour depuis votre pipeline
Quand Diun envoie une notification, la mise à jour ne doit pas se faire à la main. Le bon réflexe est de déclencher votre pipeline habituel — un webhook Gitea, une action GitHub, ou un job Woodpecker qui tire la nouvelle image, exécute vos tests et recrée le conteneur.
Si vous n'avez pas encore de pipeline, le minimum viable est un script appelé depuis le webhook ntfy :
#!/bin/bash # update-container.sh <nom_du_conteneur> CONTAINER=$1 docker compose -f /opt/${CONTAINER}/docker-compose.yml pull docker compose -f /opt/${CONTAINER}/docker-compose.yml up -dL'essentiel est que la mise à jour soit déclenchée intentionnellement, pas silencieuse.
Aller plus loin : pinner les versions et garder le contrôle
La mise à jour automatique sans tag fixe est le vrai risque — qu'on utilise Watchtower ou un pipeline déclenché par Diun. Le tag :latest est un alias qui peut pointer vers n'importe quelle version publiée par le mainteneur. Une mise à jour de :latest peut introduire un changement cassant sans que rien dans votre configuration ne change.
La pratique recommandée par la communauté Docker :
Pinnez les versions dans vos fichiers docker-compose.yml en production :
# À éviter en prod
image: nginx:latest
# Préférer un tag de version
image: nginx:1.27Réservez :latest aux environnements de développement et de staging, où une régression est détectable avant de toucher la production.
Avec des images versionnées, Diun détecte les nouvelles releases (les nouveaux tags) et vous notifie — vous choisissez la version vers laquelle migrer, vous mettez à jour votre docker-compose.yml, et vous déployez en maîtrise. C'est ce que la checklist de production Docker Compose appelle « déclarer explicitement vos dépendances ».
Si vous gérez plusieurs conteneurs sur un même VPS, un outil de monitoring des logs comme Dozzle complète utilement Diun : Diun surveille les images en amont, Dozzle observe les logs des conteneurs après mise à jour.
Diun surveille aussi les images arrêtées
Par défaut, Diun ignore les conteneurs arrêtés (stopped). Activez DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true pour surveiller aussi les images de conteneurs en pause ou arrêtés — utile si vous gérez des services batch ou des conteneurs de maintenance que vous redémarrez périodiquement.
Ce que retenir de ce comparatif
- Watchtower agit sans vous demander votre avis — utile en dev, risqué en prod, et archivé depuis fin 2025.
- Diun informe sans agir — compatible avec tout pipeline de déploiement existant et activement maintenu (la version actuelle).
- Pour la production, Diun couplé à votre pipeline est le choix le plus robuste.
- Pinner les versions dans docker-compose.yml reste la base — ni Watchtower ni Diun ne remplacent une gestion explicite des tags.
- Si vous avez Watchtower en place, le mode
WATCHTOWER_MONITOR_ONLY=trueest une transition immédiate vers un comportement plus sûr.
