Docker Auto-Updates

1. Quoi ? — Définition et contexte

Le workflow Docker Auto-Updates est un système de mise à jour automatisée des images Docker. Il utilise DIUN (Docker Image Update Notifier) pour détecter les nouvelles versions et N8N pour appliquer des politiques différenciées selon la criticité des services.

DIUN

DIUN (Docker Image Update Notifier) surveille les registres Docker et notifie quand de nouvelles versions d’images sont disponibles. Combiné avec N8N, il permet d’automatiser les mises à jour selon des règles personnalisées.

Composants du système

Composant	Rôle
DIUN	Détection des nouvelles images (surveillance des registres)
N8N Workflow	Routage selon les politiques et exécution des updates
Data Tables	Configuration des politiques par image
Telegram	Interface d’approbation pour les images applicatives

Catégories d’images

Catégorie	Comportement	Exemples
critical	Update immédiat + health check	caddy, crowdsec
base	Queue pour fenêtre 03h-05h	postgres, redis, prometheus
applicatif	Approbation admin requise	n8n, odoo, grafana

---

2. Pourquoi ? — Enjeux et motivations

Problèmes résolus

Problème	Sans ce workflow	Avec ce workflow
Images obsolètes	Vulnérabilités non patchées	Updates automatiques
Downtime utilisateur	Updates en pleine journée	Fenêtre de maintenance nocturne
Updates risqués	Pas de validation préalable	Approbation pour les apps critiques
Rollback manuel	Intervention tardive	Health check + rollback automatique

Pourquoi trois catégories ?

Catégorie	Justification
critical	Sécurité prioritaire, update immédiat (Caddy = point d’entrée)
base	Infra stable, update nocturne pour minimiser l’impact
applicatif	Business-critical, validation humaine requise

Fenêtre de maintenance

Les images “base” sont mises à jour entre 3h et 5h du matin pour minimiser l’impact. Un workflow schedulé traite la queue pending_updates dans cette fenêtre.

---

3. Comment ? — Mise en œuvre technique

Architecture

DIUN détecte nouvelle image
         │
         ▼
┌─────────────────────────────────────────────────────────┐
│              Workflow Docker DIUN                        │
│  ├─ Lookup Data Table "image_policies"                  │
│  └─ Route selon catégorie                               │
└───────────────────────┬─────────────────────────────────┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  critical   │  │    base     │  │ applicatif  │
│             │  │             │  │             │
│ Update      │  │ Queue pour  │  │ Demande     │
│ immédiat    │  │ 03h-05h     │  │ approbation │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       ▼                ▼                ▼
   Backup?          Schedule         Telegram
       │                │           [Approve]
       ▼                ▼           [Reject]
   Update           Update          [Later]
       │                │                │
       ▼                ▼                ▼
 Health check    Health check    Si approved:
       │                │         Update
       ▼                ▼
   Notify           Notify

Data Tables

image_policies — Définit la politique par image

Colonne	Type	Description
image_key	Text	Clé unique: project/service
category	Text	critical / base / applicatif
backup	Boolean	Backup requis avant update
custom_build	Boolean	Image custom (build vs pull)
github_repo	Text	owner/repo pour changelog
compose_dir	Text	Chemin absolu du docker-compose

pending_updates — Queue pour les updates programmés

Colonne	Type	Description
image_key	Text	Clé unique
image	Text	Nom complet de l’image
project	Text	Nom du projet
service	Text	Nom du service
custom_build	Boolean	Build au lieu de pull
created_at	Text	Timestamp ISO

Commandes Docker générées

# Image standard
docker compose -f /path/to/stack/docker-compose.yaml pull
docker compose -f /path/to/stack/docker-compose.yaml up -d

# Image custom (custom_build = true)
docker compose -f /path/to/stack/docker-compose.yaml pull --ignore-buildable
docker compose -f /path/to/stack/docker-compose.yaml build --no-cache
docker compose -f /path/to/stack/docker-compose.yaml up -d

Support images custom

image_key	Service	Build command
n8n-stack/n8n	n8n + workers	build --no-cache
security-stack/caddy	caddy-crowdsec	build --no-cache
ai-stack/claude-ollama	claude-ollama	build --no-cache

Images de base

DIUN surveille aussi les images de base des Dockerfiles (node, caddy:builder…) via le provider “file”. Ces updates ne déclenchent qu’une notification, pas un auto-update.

Flow d’approbation (images applicatives)

Image applicative détectée
         │
         ▼
┌─────────────────────────────────────────────────────────┐
│  Notification Telegram                                   │
│  ┌────────────────────────────────────────────────────┐ │
│  │ 🐳 Nouvelle version disponible                     │ │
│  │                                                     │ │
│  │ Image: n8nio/n8n:latest → 1.73.0                   │ │
│  │ Service: n8n-stack/n8n                             │ │
│  │                                                     │ │
│  │ [✅ Approve] [❌ Reject] [⏰ Later]                │ │
│  └────────────────────────────────────────────────────┘ │
└───────────────────────┬─────────────────────────────────┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
    Approve          Reject          Later
        │               │               │
        ▼               ▼               ▼
    Backup?         Notify         Move to
        │           "Skipped"      pending_updates
        ▼                          (03h-05h)
    Update
        │
        ▼
 Health check
        │
   ┌────┴────┐
   ▼         ▼
  OK        KO
   │         │
   ▼         ▼
Notify   Rollback
success  + Notify

Health check post-update

Après chaque update, un health check vérifie que les conteneurs sont healthy :

docker compose -f /path/to/stack/docker-compose.yaml ps --format json

Si un conteneur est unhealthy après 2 minutes, un rollback est déclenché.

Format des notifications

{
  "type": "update_success|update_failed|update_queued|approval_request",
  "severity": "info|warning|critical",
  "title": "Docker Update: n8n-stack",
  "container": "n8n",
  "image": "n8nio/n8n:1.73.0",
  "project": "n8n-stack",
  "timestamp": "2026-01-20T10:30:00.000Z"
}

Commandes utiles

# Forcer un check DIUN
docker exec diun diun --test

# Logs DIUN
docker logs diun --tail 50

# Voir les politiques configurées
# N8N → Data → Tables → image_policies

# Voir les updates en attente
# N8N → Data → Tables → pending_updates

---

4. Et si ? — Perspectives et limites

Limites actuelles

Limite	Impact	Mitigation
Pas de tests automatiques	Risque de régression non détectée	Health check basique uniquement
Rollback manuel	Intervention requise si rollback échoue	Notification immédiate
Dépendance DIUN	Pas de détection si DIUN down	Monitoring du conteneur

Scénarios d’évolution

Si un update cause une régression :

• Health check détecte le problème
• Rollback automatique vers l’image précédente
• Notification avec détails pour investigation

Si les updates sont trop fréquents :

• Ajuster le polling DIUN (actuellement 6h)
• Créer une catégorie “stable” avec updates mensuels
• Filtrer par semantic versioning (major uniquement)

Si besoin de tests plus poussés :

• Intégrer des smoke tests post-update
• Ajouter un délai d’observation avant notification success
• Créer un environnement staging pour tests préalables

---

Pages liées

Infrastructure

• Architecture VPS — Vue d’ensemble
• Security Stack — Caddy protégé

Workflows

• Telegram Orchestrator — Réception approbations
• Notification Hub — Routage notifications

Référence

• Glossaire — DIUN, Health Check