Mettre à jour ses conteneurs automatiquement avec Watchtower

Garder ses conteneurs Docker à jour réduit l’exposition aux vulnérabilités et permet de bénéficier rapidement des correctifs publiés par les éditeurs. Sur une infrastructure comprenant plusieurs services, vérifier manuellement chaque image devient toutefois chronophage et source d’oubli.

Watchtower automatise cette surveillance. Il détecte les nouvelles images, peut avertir l’administrateur ou remplacer automatiquement les conteneurs concernés. Cette simplicité exige néanmoins une stratégie prudente, particulièrement en production.

Avertissement : l’auto-update en production est risqué

La mise à jour automatique est un couteau à double tranchant. Elle accélère le déploiement des correctifs de sécurité, mais peut aussi installer une version incompatible sans validation humaine.

Le risque augmente avec les tags mouvants comme latest. Un éditeur peut publier sous ce tag une version comportant un changement cassant, une nouvelle configuration obligatoire ou une migration de données. Watchtower appliquera alors la mise à jour selon sa configuration, même si l’application ne peut plus démarrer correctement.

Il ne faut jamais mettre à jour automatiquement une base de données de production comme PostgreSQL, MariaDB ou MongoDB. Un changement de version majeure peut nécessiter une procédure de migration précise. Remplacer simplement le conteneur peut rendre les données illisibles ou provoquer une interruption difficile à récupérer.

Pour une production critique, privilégiez l’une de ces approches :

• Utiliser Watchtower en mode notification seule.
• Autoriser explicitement uniquement quelques conteneurs non critiques.
• Conserver les bases de données et services sensibles hors de son périmètre.
• Maintenir des sauvegardes testées avant toute mise à jour.

L’automatisation complète convient surtout aux homelabs, environnements de développement et services non critiques utilisant des tags stables.

Comment fonctionne Watchtower ?

Watchtower s’exécute lui-même dans un conteneur Docker. À intervalles réguliers, il interroge les registres associés aux images utilisées sur l’hôte.

Lorsqu’une nouvelle image est disponible, il peut :

1. Télécharger la nouvelle image.
2. Arrêter proprement le conteneur existant.
3. Recréer le conteneur avec la même configuration.
4. Redémarrer le service.
5. Supprimer éventuellement l’ancienne image.

Les variables d’environnement, volumes, réseaux, ports et options du conteneur sont conservés lors de sa recréation. Les données persistantes doivent néanmoins résider dans des volumes ou des montages dédiés. Toute donnée écrite uniquement dans le système de fichiers interne du conteneur risque d’être perdue.

Trois modes d’usage recommandés

Notification seule pour la production

C’est le mode recommandé sur une infrastructure critique. Watchtower vérifie la disponibilité des nouvelles images et transmet une notification, mais ne remplace aucun conteneur.

L’administrateur peut alors consulter les notes de version, vérifier les changements cassants, réaliser une sauvegarde et tester la mise à jour avant de la déployer manuellement.

Mise à jour ciblée par labels

Watchtower peut limiter son action aux conteneurs portant un label explicite. Cette approche convient aux services faciles à restaurer, comme un proxy secondaire, un outil interne sans état ou une application non critique.

L’activation devient volontaire : aucun conteneur n’est mis à jour tant que le label requis n’a pas été ajouté.

Mise à jour automatique globale

Ce mode surveille et actualise tous les conteneurs accessibles. Il est pratique dans un homelab ou un environnement jetable, mais déconseillé en production. Une seule image défectueuse peut interrompre un service sans intervention préalable.

Même dans un homelab, excluez les bases de données et conservez des sauvegardes.

Déployer Watchtower avec Docker Compose

Créez un fichier compose.yml dédié :

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      WATCHTOWER_SCHEDULE: "0 0 4 * * *"
      WATCHTOWER_CLEANUP: "true"

Démarrez ensuite le service :

docker compose up -d

WATCHTOWER_SCHEDULE utilise une expression cron à six champs, dont le premier représente les secondes. L’exemple lance une vérification chaque jour à 4 heures.

WATCHTOWER_CLEANUP=true supprime les anciennes images après une mise à jour réussie. Cela évite de saturer progressivement le stockage NVMe, mais retire aussi une possibilité de retour arrière immédiat. Une sauvegarde et une procédure de restauration restent indispensables.

Pour consulter l’activité de Watchtower :

docker compose logs -f watchtower

Cibler les conteneurs avec des labels

La stratégie la plus sûre consiste à activer le mode opt-in :

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      WATCHTOWER_LABEL_ENABLE: "true"
      WATCHTOWER_SCHEDULE: "0 0 4 * * *"
      WATCHTOWER_CLEANUP: "true"

  application:
    image: exemple/application:1
    labels:
      com.centurylinklabs.watchtower.enable: "true"

Avec WATCHTOWER_LABEL_ENABLE=true, seuls les conteneurs portant le label enable: "true" sont mis à jour. Cette politique réduit fortement le risque d’inclure accidentellement un service critique.

Sans mode opt-in, un conteneur peut être exclu explicitement :

services:
  database:
    image: postgres:16
    labels:
      com.centurylinklabs.watchtower.enable: "false"

Cette exclusion est impérative pour les bases de données. Il est également prudent de l’appliquer aux applications qui exécutent automatiquement des migrations, aux systèmes de paiement et aux services dont l’indisponibilité aurait un impact métier important.

Configurer le mode monitor-only et les notifications

Le mode monitor-only recherche les nouvelles images sans les appliquer :

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      WATCHTOWER_MONITOR_ONLY: "true"
      WATCHTOWER_SCHEDULE: "0 0 8 * * *"
      WATCHTOWER_NOTIFICATIONS: "shoutrrr"
      WATCHTOWER_NOTIFICATION_URL: "${WATCHTOWER_NOTIFICATION_URL}"

Placez l’URL de notification dans un fichier .env non versionné :

WATCHTOWER_NOTIFICATION_URL=discord://token@channel

Le format exact dépend du canal choisi. Watchtower peut transmettre ses alertes vers différents services, notamment Discord, Slack ou un serveur SMTP pour l’envoi d’e-mails.

Traitez les URL, jetons et identifiants de notification comme des secrets. Ne les inscrivez pas directement dans le fichier Compose et ne les publiez pas dans un dépôt Git.

Sécuriser l’accès au socket Docker

Le montage de /var/run/docker.sock donne à Watchtower un contrôle très important sur le moteur Docker. Un processus compromis dans ce conteneur pourrait potentiellement créer, arrêter ou modifier d’autres conteneurs et accéder à l’hôte avec des privilèges élevés.

Le suffixe :ro sur le montage ne constitue pas une protection suffisante : il limite l’écriture sur le fichier du socket, mais pas nécessairement les opérations autorisées par l’API Docker.

Utilisez uniquement l’image officielle attendue, limitez les personnes capables de modifier la configuration et surveillez les journaux. Évitez aussi d’exposer l’API Docker sur le réseau. Sur une infrastructure TalCloud hébergée en France, ces précautions complètent les mesures d’hébergement, de conformité RGPD et de protection Anti-DDoS Netrix, sans remplacer la sécurisation du système et des conteneurs.

Bonnes pratiques avant d’automatiser

Avant d’autoriser une mise à jour automatique :

• Sauvegardez les volumes persistants et testez leur restauration.
• Préférez un tag stable ou une version maîtrisée à latest.
• Excluez toutes les bases de données.
• Excluez les services critiques et les applications à migrations sensibles.
• Testez les nouvelles images dans un environnement de préproduction.
• Ajoutez des healthchecks pour détecter un service démarré mais inutilisable.
• Centralisez les journaux et configurez des alertes.
• Prévoyez une procédure de retour arrière.
• Programmez les vérifications pendant une période de faible activité.

Un tag strictement figé, comme application:2.4.1, ne recevra normalement pas une nouvelle version fonctionnelle sous un autre numéro. Pour automatiser raisonnablement, certains projets proposent des tags de branche stable comme 2.4 ou stable. Il faut vérifier la politique de publication propre à chaque image. Pensez aussi à sauvegarder vos volumes avec une méthode comme celle décrite dans notre guide sur les sauvegardes chiffrées avec restic.

Quand ne pas utiliser l’auto-update ?

N’activez pas la mise à jour automatique pour une production critique nécessitant une validation, une fenêtre de maintenance ou une traçabilité stricte. Évitez-la également pour les bases de données, les orchestrations complexes et les applications dont chaque version impose une migration.

Dans ces situations, Watchtower reste utile en mode notification seule. Il transforme la vérification manuelle des registres en alerte exploitable, tout en laissant à l’équipe le contrôle du déploiement. C’est généralement le meilleur compromis entre réactivité, sécurité et stabilité sur un serveur Docker de production.