Vos conteneurs Docker sont-ils vraiment à jour ?

Pour l’anecdote, j’ai passé une bonne partie de la soirée avec mes collègues à déployer les nouvelles versions de PHP préparées par la team infra. Nous avons terminé vers 23h (et pas de pizza à partager quand on est en télétravail !).

PHP n’est pas un cas isolé. Ces derniers temps, nous avons vu passer un bon nombre d’alertes concernant Node.js, NGINX, GitLab, Go et d’autres projets. La liste est longue et les failles découvertes sont nombreuses ces derniers temps.

Tout cela m’a amené à une question très simple : comment je m’assure que les services de mon serveur personnel sont à jour ?

Des dizaines de conteneurs et peu de visibilité

J’héberge moi-même un certain nombre de services, principalement en utilisant Docker Compose. Je dois admettre que la maintenance des images est un aspect que j’ai un peu mis de côté.

Jusqu’à présent, je mettais mes conteneurs à jour de temps en temps en me rendant dans le répertoire de chaque projet pour exécuter docker compose pull && docker compose up -d.

Cela fonctionne mais c’est franchement pénible lorsqu’on gère des dizaines de conteneurs. Surtout, cela demande de penser à effectuer ces opérations régulièrement.

Il existe un autre problème : on ne sait pas toujours ce qui se cache réellement sous le capot des applications que l’on héberge.

Pour la plupart de mes applications, j’ai regardé dans quel langage de programmation elles ont été développées mais je suis rarement allé plus loin. Je ne connais pas forcément les versions exactes des langages ou encore les librairies et dépendances utilisées par chaque image.

En tant que développeur, j’ai quelques réflexes sur ces sujets et je me tiens informé. Mais je réalise que j’ai probablement pas mal d’angles morts. Et j’imagine que la situation est encore moins évidente pour quelqu’un qui héberge ses propres services sans être développeur. Par ailleurs, une application peut être à jour tout en contenant une dépendance vulnérable.

J’ai donc creusé un peu les solutions permettant de surveiller tout cela, sans avoir à vérifier manuellement chaque projet.

Solutions pour suivre les mises à jour Docker

Comme souvent, il existe pas mal d’outils, chacun adoptant une approche différente.

Outil	Fonctionnalité
Watchtower	Surveille les images et peut mettre à jour les conteneurs automatiquement.
Arcane	Interface de gestion Docker avec détection de mises à jour, le déploiement (manuel ou automatique) et le scan des vulnérabilités.
Diun	Détecte les nouvelles images et envoie des notifications, sans modifier les conteneurs.
What’s Up Docker	Surveille les versions, notifications et actions de mise à jour configurables.
Portainer	Gestion des conteneurs et redéploiement des stacks avec GitOps.
Renovate	Propose des mises à jour de version directement dans les fichiers compose d’un dépôt Git.

Ce qui est intéressant, c’est que vous pouvez choisir le niveau d’automatisation qui vous convient le mieux.

Vous pouvez simplement recevoir une notification, mettre à jour vos conteneurs via une interface, ou laisser un outil gérer entièrement les redéploiements.

Et pour les applications dont les configurations sont suivies dans Git, Renovate permet de passer en revue les changements avant de les appliquer.

Les mises à jour ne racontent pas tout

Savoir qu’une nouvelle image est disponible c’est super, mais cela ne permet pas forcément de déterminer si la version que vous utilisez actuellement comporte des vulnérabilités. C’est là qu’intervient un outil comme Trivy. Il analyse les composants présents dans vos images pour y détecter des CVE connues.

Il faut interpréter ces résultats avec prudence : une vulnérabilité détectée n’est pas forcément exploitable dans votre configuration. À l’inverse, une image sans CVE connue n’est pas pour autant garantie sans faille.

Ça apporte néanmoins un niveau de visibilité qu’il serait compliqué d’obtenir en se contentant de consulter les versions disponibles sur Docker Hub.

Perso, je reste fidèle à Arcane

J’utilise Arcane sur mon homelab depuis un bon moment déjà. Je l’avais d’ailleurs déjà présenté sur le blog. Depuis, il a bien évolué.

Je l’utilisais principalement pour gérer mes conteneurs et mes projets Compose via une interface quand je n’avais pas un terminal sous la main.

Il permet de visualiser les nouvelles images disponibles, déclencher les mises à jour manuellement ou automatiquement et scanner les potentielles vulnérabilités via Trivy.

Bref, il couvre déjà une bonne partie de mes besoins et je ne vois donc pas, pour l’instant, l’intérêt d’ajouter un autre outil qui remplirait la même fonction.

Diun est une alternative intéressante, notamment si vous souhaitez simplement être informé des mises à jour tout en conservant un contrôle manuel total sur le processus de gestion.

Depuis la version 4.32.0, il expose des métriques Prometheus, de quoi faciliter son intégration avec Grafana et la mise en place d’alertes basées sur les métriques disponibles.

Ça me parle particulièrement, car j’aime beaucoup ce qui touche au monitoring, la data et les dashboards. Je n’en ai pas encore parlé sur le blog, mais il faudra vraiment que je vous présente mon setup Prometheus/Grafana et mon système d’alerting !

Faut-il vraiment tout automatiser ?

Je ne suis pas partisan du tout automatique.

Je n’ai aucun problème à automatiser les mises à jour des services les moins critiques. En revanche, je préfère garder la main sur les applications plus sensibles comme Vaultwarden ou les bases de données.

Une mise à jour peut casser une configuration, introduire une régression ou nécessiter une migration.

Petite pensée à ceux qui utilisaient Immich avant sa première version stable : les breaking changes étaient assez réguliers. Il était prudent de lire les releases note avant de lancer un docker compose pull avec trop d’enthousiasme !

Depuis, Immich a publié sa première version stable, mais l’exemple reste pertinent : une mise à jour ne se résume pas toujours au simple remplacement d’une image Docker.

Se réveiller et découvrir qu’un service essentiel ne démarre plus parce qu’il s’est mis à jour automatiquement pendant la nuit n’est pas une expérience agréable.

J’ai une approche hybride : automatisation pour certains services, et notification suivie d’une intervention manuelle pour les autres.

C’est du bon sens, mais lorsqu’une faille critique affecte un service exposé à Internet, mieux vaut ne pas attendre trois semaines avant d’agir.

Et, quelle que soit la méthode choisie, il est indispensable de disposer de sauvegardes fiables (et d’avoir déjà testé la restauration).

Dernier point, qu’il est facile d’oublier lorsque l’on gère un grand nombre de conteneurs : l’OS hôte lui-même nécessite également une maintenance. Sur Debian ou Ubuntu, unattended-upgrades permet de gérer l’installation automatique des correctifs de sécurité depuis les dépôts configurés.

Et maintenant ?

Pour l’instant, je vais donc continuer avec Arcane et profiter davantage de ses fonctionnalités de surveillance. Mon objectif n’est pas de tout automatiser, mais surtout d’éviter que des mises à jour importantes passent sous le radar.

Et vous, vous utilisez quoi pour gérer les mises à jour de vos conteneurs ? N’hésitez pas en commentaire si vous connaissez un outil ou une astuce pour gérer les updates de container !