geeks.fr
Outils

Watchtower est mort, Freshdock prend la suite : la mise à jour Docker qui revient en arrière quand ça casse

Watchtower est archivé depuis décembre 2025 et plante sur Docker Engine 29. Freshdock, écrit en Rust et publié sous Apache 2.0, met à jour vos conteneurs et restaure l'ancien si le nouveau ne devient pas sain. Nous l'avons installé et provoqué la panne pour voir.

Echo 17 septembre 2026 5 min de lecture

Watchtower mettait vos conteneurs à jour tout seuls depuis des années. Il est archivé depuis décembre 2025, et sur un Docker récent il ne se contente pas de refuser : il plante. Freshdock reprend le flambeau avec une idée en plus, la seule qui compte quand une mise à jour part de travers : un retour arrière automatique. Nous avons provoqué la panne pour le vérifier.

D’abord, la mauvaise nouvelle : Watchtower est vraiment fini

Le dépôt containrrr/watchtower est archivé depuis le 17 décembre 2025. Ce n’est pas qu’une question de maintenance : l’outil embarque une version figée de la bibliothèque Docker, et les moteurs récents la refusent. Sur notre machine, en Docker Engine 29.7.2, la réponse est sans appel.

level=error msg="Error response from daemon: client version 1.25 is too old.
Minimum supported API version is 1.40, please upgrade your client"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation]

Il ne sort pas en erreur, il panique. Si vous avez encore un Watchtower dans un coin de votre machine et que vous avez mis Docker à jour, il ne vous protège plus de rien, sans le dire.

Ce que fait Freshdock

Freshdock est un binaire unique écrit en Rust, publié sous Apache 2.0. Il surveille les conteneurs qui se déclarent, tire la nouvelle image quand l’empreinte du tag change, recrée le conteneur, puis attend qu’il devienne sain. S’il ne le devient pas, l’ancien revient.

Une commande suffit :

docker run -d --name freshdock \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/turbootzz/freshdock run

Un conteneur entre dans son périmètre avec l’étiquette freshdock.enable=true, et le rythme se règle par mode : live à chaque nouvelle empreinte, nightly, weekly, monthly, watch pour signaler sans rien toucher, off. De quoi coller au tri qu’on décrivait dans quels conteneurs laisser tourner jour et nuit. Le mode par défaut est watch, ce qui est le bon réflexe : à l’installation, il regarde et se tait.

Bonne surprise vérifiée sur notre banc : un conteneur qui ne porte que l’ancienne étiquette com.centurylinklabs.watchtower.enable=true apparaît quand même dans sa liste. La migration ne demande de retoucher aucun conteneur existant.

Notre banc : casser une mise à jour pour voir le filet

Promettre un retour arrière est facile. Nous avons donc monté un conteneur nginx:1.27-alpine avec un contrôle de santé qui vérifie la présence d’un fichier, attendu qu’il passe healthy, supprimé le fichier pour jouer la régression, puis lancé la recréation. Le nouveau conteneur ne pouvait plus devenir sain.

La sortie de freshdock au moment du retour arrière, et le conteneur d'origine retrouvé sain
© Capture geeks.fr

Le filet tient. Freshdock archive l’ancien conteneur sous un nom horodaté, démarre le nouveau, constate qu’il ne devient pas sain, abandonne et restaure le précédent. Vérification faite après coup : le conteneur restauré porte le même identifiant qu’avant la mise à jour. Ce n’est pas une recréation à l’identique, c’est bien l’original qui repart, avec ses volumes et son état.

Les trois choses que la page d’accueil ne dit pas

La restauration est instantanée, la panne ne l’est pas. Le site promet que l’ancien conteneur revient « en quelques secondes ». C’est vrai de la restauration elle-même, que nous avons mesurée à 0,19 seconde. Mais avant de renoncer, Freshdock attend deux minutes que le nouveau conteneur devienne sain. Notre contrôle de santé, lui, savait au bout de huit secondes. Résultat : deux minutes et une seconde entre la commande et le retour à la normale, donc deux minutes de service en rade. Et ce délai ne se règle pas : la commande run ne propose que --stop-timeout, qui porte sur autre chose.

Un registre local en clair est hors jeu. Freshdock interroge les registres en HTTPS et n’offre aucune option de registre non sécurisé. Notre registre de test sur localhost:5001 est resté marqué « network unavailable » du début à la fin. Pour un homelab qui pousse ses propres images sans certificat, c’est rédhibitoire.

Les chiffres du site ont un peu glissé. La page annonce la version 1.5.0 et un binaire de moins de 10 Mo ; l’image que nous avons tirée est en 1.6.0 et pèse 16,5 Mo. Rien de grave, mais si vous choisissez un outil sur sa légèreté, comptez sur l’image, pas sur la promesse.

Notre avis

Freshdock fait une chose que Watchtower n’a jamais faite, et c’est exactement celle qui manquait : il vérifie que la mise à jour a marché avant de vous laisser avec. Pour un homelab dont les images viennent de registres publics, c’est un remplacement direct, sans reprise de configuration, et le mode watch par défaut évite la catastrophe du premier jour.

Les deux minutes d’attente avant le retour arrière sont le vrai défaut, et elles se voient d’autant plus que le reste est rapide. Un réglage de ce délai, et un mode registre local, et l’outil serait complet.

#Docker #auto-hébergement #homelab #Rust #open source #outil du jour
Ajouter geeks.fr à mes sources préférées Un réglage Google, une fois, pour nous retrouver plus souvent dans vos résultats.
Écrit par Echo Rédac IA de geeks.fr Relu et vérifié par Cyril Verglas Fondateur et directeur de la publication

Continuer la lecture