Watchtower Docker - Automatiser les mises à jour, oui mais comment ?

Automatiser les mises à jour d’images Docker fait gagner du temps, mais seulement si l’outil reste prévisible. Watchtower surveille les conteneurs, détecte les nouvelles images et relance ce qui doit l’être avec les mêmes paramètres de départ, ce qui en fait une brique utile dans une chaîne DevOps simple ou sur un serveur unique.

Je vais aller droit au but: comment ça fonctionne, comment l’installer proprement, quels conteneurs laisser sous contrôle, et surtout quelles limites garder en tête pour éviter une automatisation trop large. L’objectif n’est pas seulement d’avoir des mises à jour automatiques, mais d’avoir des mises à jour que tu peux réellement faire confiance à lancer.

Pourquoi Watchtower est utile dans une stack DevOps

Je vois Watchtower comme un accélérateur de maintenance, pas comme un remplaçant de pipeline. Son intérêt est très concret: il réduit les opérations manuelles répétitives quand tes services sont empaquetés en images immuables et qu’une nouvelle version peut être redéployée sans intervention humaine.

C’est particulièrement pertinent pour des services stateless, des API internes, des workers, des reverse proxies, ou des environnements de test qui doivent suivre les images les plus récentes sans qu’on passe son temps à relancer des conteneurs à la main. À l’inverse, je le déconseille comme réflexe par défaut pour des bases de données, des files de messages ou des services avec migration délicate, car là le redémarrage automatique doit être cadré par des hooks, des sauvegardes et parfois une fenêtre de maintenance.

• Bon cas d’usage: microservices sans état persistant.
• Bon cas d’usage: stack personnelle ou serveur unique où la simplicité compte plus que le cérémonial de déploiement.
• Bon cas d’usage: préproduction, staging ou environnements de validation.
• Mauvais cas d’usage: brique stateful sans plan de reprise.

En pratique, je l’utilise surtout quand l’enjeu est de rester à jour sans transformer chaque mise en production en tâche d’astreinte. C’est cette logique d’automatisation cadrée qui explique le fonctionnement réel de l’outil.

Comment il surveille les images et relance les conteneurs

Watchtower s’exécute lui-même comme un conteneur, mais il doit accéder au démon Docker pour observer les autres. Concrètement, cela passe presque toujours par le montage de `/var/run/docker.sock`, ce qui lui donne une vue directe sur les conteneurs du daemon cible.

Par défaut, il surveille tous les conteneurs en cours d’exécution. Tu peux toutefois choisir une fréquence de vérification, ou déclencher un passage unique pour valider ta configuration avant de l’automatiser pour de bon. Le point important, c’est qu’il faut choisir entre intervalle régulier et planification cron, pas les deux en même temps.

Au moment du redémarrage, Watchtower envoie un signal d’arrêt au conteneur, attend ensuite le délai prévu, puis force l’arrêt si nécessaire. Le délai par défaut est de 10 secondes, ce qui suffit pour beaucoup de services mais peut être trop court pour une API qui doit vider une file, fermer proprement une connexion ou écrire un dernier état sur disque. C’est aussi là que les labels de signal d’arrêt deviennent utiles si ton application préfère autre chose que le comportement standard.

Une fois ce mécanisme compris, la vraie question devient: comment le déployer sans ouvrir la porte à des mises à jour trop larges?

Installer Watchtower proprement

Avec une commande docker run

Pour une première mise en place, je préfère une commande courte, lisible et explicite. L’idée est de garder Watchtower lui-même en vie après un reboot de l’hôte, de lui donner l’accès au socket Docker et de fixer le fuseau horaire si tes créneaux de maintenance suivent l’heure française.

docker run -d \
  --name watchtower \
  --restart unless-stopped \
  -e TZ=Europe/Paris \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Si tu veux tester avant de passer en continu, remplace le mode daemon par un passage ponctuel. C’est utile pour vérifier que Watchtower voit bien les conteneurs, que le registre est accessible et que la stratégie d’arrêt fonctionne comme prévu.

docker run --rm \
  -e TZ=Europe/Paris \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --run-once

Lire aussi : Installer Apache sur Debian - Le guide complet et propre

Avec Docker Compose

En Compose, je mets Watchtower dans un service à part. C’est plus propre pour l’exploitation, surtout si tu veux lui ajouter des options de notification, de nettoyage ou de filtrage plus tard.

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      TZ: Europe/Paris
      WATCHTOWER_CLEANUP: "true"
      WATCHTOWER_LABEL_ENABLE: "true"
    command: --schedule "0 0 4 * * *"

Si tes images viennent d’un registre privé, Watchtower sait aussi utiliser les identifiants Docker existants ou un fichier de configuration dédié. En pratique, je privilégie le partage du fichier `config.json` généré par `docker login` quand je veux éviter de disperser les secrets dans plusieurs variables d’environnement. Une fois le service en place, il reste surtout à décider quels conteneurs il a réellement le droit de toucher.

Limiter les mises à jour aux bons conteneurs

Le comportement par défaut est simple, parfois trop simple: Watchtower observe tous les conteneurs du daemon. Dans une stack sérieuse, je préfère passer en logique d’opt-in avec des labels, parce que cela évite de mettre à jour par accident un service d’état, un moteur de cache ou un composant qui demande une séquence de redéploiement précise.

Le moyen le plus propre consiste à étiqueter seulement les conteneurs autorisés. Si tu as des contraintes d’héritage ou de legacy, tu peux aussi exclure par nom, ou isoler des groupes via le scope. Cette granularité change vraiment la qualité opérationnelle du système.

Le mode monitor-only mérite une précision: Watchtower continue à comparer les images et à produire des notifications, mais il ne redéploie pas le conteneur. C’est une bonne marche intermédiaire pour valider une configuration ou surveiller une préprod avant de passer au mode actif.

Si tu fais tourner plusieurs instances sur le même hôte, le point de vigilance est simple: ne mélange pas les périmètres sans réfléchir, sinon une instance sans scope peut interférer avec les autres. Les bons filtres évitent déjà beaucoup d’erreurs, mais en production ce sont surtout les options de sûreté qui font la différence.

Les réglages qui comptent vraiment en production

Quand on passe d’un test local à un environnement réel, trois familles d’options prennent de la valeur: le nettoyage, les hooks de cycle de vie et l’observabilité. C’est là que Watchtower devient plus qu’un simple relanceur de conteneurs, parce qu’il peut s’insérer dans un flux d’exploitation cohérent.

Les hooks sont utiles, mais ils demandent un conteneur capable d’exécuter sh. Je les vois surtout comme un filet de sécurité pour des services qui doivent vider un cache, exporter des données ou préparer une migration avant le redémarrage. Pour les notifications, je préfère un canal qui arrive là où l’équipe regarde déjà, plutôt qu’un flux que personne n’ouvre.

Sur le plan des registres privés, Watchtower peut récupérer les identifiants via le fichier Docker classique ou via des variables dédiées. Et si ton équipe est en France, pense à harmoniser TZ=Europe/Paris avec tes fenêtres de maintenance, sinon un redéploiement “à 4 h” finit parfois à une heure qui n’a rien de local. Ces garde-fous évitent les surprises, et il reste à voir les erreurs qui reviennent le plus souvent.

Les pièges que je vois le plus souvent

Le premier piège, c’est de croire qu’un outil d’automatisation remplace une stratégie de versionnement. Si tu publies des images avec un tag trop vague et sans discipline de promotion, Watchtower ne corrigera pas le problème de fond. Je recommande de garder des tags explicites pour les versions et de réserver les tags mouvants à des usages que tu maîtrises vraiment.

• Ne traite pas les bases de données comme des services stateless.
• Ne laisse pas le délai d’arrêt à 10 secondes si ton application a besoin d’un shutdown propre plus long.
• Ne donne pas accès au socket Docker à un conteneur sans accepter que cela implique un niveau de privilège élevé.
• Ne confonds pas mise à jour d’image et pipeline de livraison complet: build, test, migration et rollback restent à concevoir.
• Ne laisse pas la mise à jour automatique toucher tout le parc si seule une partie doit être automatisée.

Le second piège, plus discret, consiste à oublier que Watchtower agit au niveau du daemon Docker. Autrement dit, le confort d’utilisation vient avec une surface d’accès importante, ce qui mérite un hôte bien maîtrisé, des conteneurs bien séparés et des règles claires sur ce qui peut être redémarré automatiquement. Avec ces limites en tête, on peut garder Watchtower comme un outil d’automatisation raisonnable plutôt qu’un déclencheur d’incidents.

Le compromis que je retiens pour une stack Docker simple

Si je devais résumer ma position en une méthode pragmatique, je partirais sur un Watchtower en mode opt-in, un passage planifié pendant une fenêtre calme, des notifications actives et un nettoyage des images anciennes. C’est le meilleur équilibre entre automatisation et contrôle pour une petite stack de production, surtout si elle héberge des API, des workers ou des services internes qui supportent bien un redémarrage contrôlé.

Je garderais aussi deux réflexes simples: tester avec --run-once avant d’ouvrir le robinet, et augmenter le délai d’arrêt dès qu’un service a besoin de libérer des ressources proprement. C’est souvent ce duo, plus que la configuration la plus sophistiquée, qui fait la différence entre un redéploiement fluide et un incident bête.