Aller au contenu

Load Balancing Mis à jour le 2026-06-02

Modules et plugins Caddy, comment fonctionne l''écosystème

Une carte pratique du paysage des plugins Caddy — fournisseurs DNS, backends de stockage, modules d''authentification, gestionnaires — et comment un MSP choisit lesquels installer pour une charge donnée.

Caddy est livré comme un seul binaire Go avec un ensemble de modules statiques compilés au moment du build. La distribution standard couvre la plupart des charges — service de fichiers, proxy inverse, ACME avec HTTP-01 et TLS-ALPN-01, stockage de fichiers — mais l’écosystème est beaucoup plus large. Fournisseurs DNS pour le défi ACME DNS-01, backends de stockage alternatifs, modules d’authentification, gestionnaires personnalisés, exportateurs de télémétrie : tous sont des plugins, tous sont compilés via xcaddy. Cet article est la carte qu’on utilise quand on choisit quels modules un déploiement client a réellement besoin.

Comment vérifier

Ce qui se trouve dans le binaire que vous faites tourner :

caddy list-modules
caddy list-modules | grep -i dns
caddy list-modules | grep -i storage
caddy list-modules --versions
caddy version

list-modules énumère chaque module compilé. La sortie est votre contrat — si le module n’est pas dans cette liste, il ne peut pas être référencé depuis un Caddyfile ou une config JSON. Le drapeau --versions ajoute les versions des modules Go à côté de chaque entrée ; utile pour la revue de sécurité.

Ce qui se passe

Caddy est bâti sur un système de modules. Chaque gestionnaire (reverse_proxy, file_server, encode), chaque sélecteur (host, path), chaque émetteur (acme), chaque backend de stockage (file_system, redis, consul), chaque fournisseur DNS pour DNS-01 — tous sont des modules Go qui implémentent une interface de module Caddy. Ils sont enregistrés au démarrage du processus et recherchés par nom quand la config les référence.

Le binaire « standard » est celui du dépôt Cloudsmith ou de l’image Docker caddyserver/caddy. Il inclut les modules du dépôt principal. Tout ce qui est hors du dépôt principal (la plupart des fournisseurs DNS, la plupart des backends de stockage, tous les gestionnaires tiers) doit être ajouté au moment du build via xcaddy. Il n’y a pas de chargement de plugin à l’exécution — les modules sont liés statiquement. Une fois construit, le binaire est autonome.

Ça a deux conséquences pratiques :

  1. Pour ajouter un seul fournisseur DNS pour ACME DNS-01, vous compilez un binaire personnalisé. Il n’y a pas d’apt install caddy-route53.
  2. Le binaire que vous construisez est reproductible — les sommes de contrôle des modules Go sont épinglées, donc la même commande xcaddy produit le même binaire pour toujours. Verrouillez la commande en CI ; verrouillez le hash du binaire dans votre gestion de configuration.

L’écosystème des plugins vit dans trois endroits : l’organisation caddyserver sur GitHub (extensions officielles), l’organisation caddy-dns (fournisseurs DNS contribués par la communauté), et les dépôts tiers (souvent via la liste « Caddy Module Library » sur caddyserver.com). Voir builds personnalisés xcaddy pour la mécanique de build.

Ce que vous pourriez ajouter

Fournisseurs DNS pour ACME DNS-01. Requis quand vous avez besoin de certificats caractère générique ou quand le port 80 est inatteignable. La convention est github.com/caddy-dns/<provider>. Courants :

  • caddy-dns/cloudflare — API Cloudflare
  • caddy-dns/route53 — AWS Route 53
  • caddy-dns/digitalocean — DigitalOcean DNS
  • caddy-dns/googleclouddns — Google Cloud DNS
  • caddy-dns/azure — Azure DNS
  • caddy-dns/desec — deSEC.io (DNS public respectueux de la vie privée)
  • caddy-dns/rfc2136 — mise à jour DNS dynamique générique (marche avec BIND9, PowerDNS, Knot)

Backends de stockage. Requis pour le partage d’état de certificats multi-nœud. Courants :

  • github.com/caddyserver/caddy-storage-redis — Redis (le plus populaire pour la multi-location SaaS)
  • github.com/pteich/caddy-tlsconsul — Consul KV
  • github.com/ss098/certmagic-s3 — S3-compatible (Minio, R2, Wasabi, etc.)
  • github.com/yroc92/postgres-storage — PostgreSQL
  • github.com/baldinof/caddy-supervisor — DynamoDB

Modules d’authentification. Au-delà de l’authentification basique (intégrée) :

  • github.com/greenpau/caddy-security — auth multi-portail (OAuth2, OIDC, SAML, JWT)
  • github.com/caddyserver/transform-encoder — transformateurs de log
  • github.com/abiosoft/caddy-exec — exécute des commandes comme un gestionnaire (à utiliser avec parcimonie)

Télémétrie et observabilité.

  • github.com/lucaslorentz/caddy-docker-proxy — config pilotée par labels Docker (les conteneurs rejoignent Caddy automatiquement)
  • github.com/mholt/caddy-l4 — proxy de couche 4 (TCP/UDP) — voir proxy TCP couche 4 Caddy
  • github.com/WeidiDeng/caddy-cloudflare-ip — auto-mise-à-jour des plages IP Cloudflare pour trusted_proxies

Compression.

  • github.com/dunglas/mercure — serveur Server-Sent Events côté serveur
  • github.com/ueffel/caddy-brotli — compression Brotli (zstd est intégré) — voir compression Brotli Caddy

La procédure

  1. Auditer ce que vous avez. Avant d’ajouter quoi que ce soit, listez ce qui est compilé. La plupart des requêtes « j’ai besoin d’un plugin » sont résolues par une fonctionnalité déjà présente :

    caddy list-modules > /tmp/caddy-modules.txt
grep -i route53 /tmp/caddy-modules.txt   # vérification fournisseur DNS
grep -i redis /tmp/caddy-modules.txt     # vérification backend stockage

  2. Construire avec xcaddy. Le motif standard :

    go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest

xcaddy build \
  --with github.com/caddy-dns/cloudflare \
  --with github.com/caddyserver/caddy-storage-redis \
  --with github.com/ueffel/caddy-brotli \
  --output /usr/local/bin/caddy-custom

    Le binaire résultant est un remplacement direct du binaire caddy standard.

  3. Remplacer le binaire. Arrêter, échanger, démarrer :

    sudo systemctl stop caddy
sudo mv /usr/local/bin/caddy-custom /usr/bin/caddy
sudo caddy version
sudo systemctl start caddy

    L’unité systemd n’a besoin d’aucun changement — elle appelle caddy par nom.

  4. Épingler le hash du binaire. Dans votre gestion de configuration ou votre stockage d’artefacts CI, enregistrez le SHA256 du binaire construit. Un changement dans le binaire devrait être un changement de config revu par un humain, pas une mise à jour sans surveillance :

    sha256sum /usr/bin/caddy

  5. Documenter quels modules sont présents. Un fichier simple dans le dépôt de déploiement :

    # /etc/caddy/MODULES.txt
# Construit : 2026-06-02
# Standard plus :
#   - github.com/caddy-dns/cloudflare v1.0.0
#   - github.com/caddyserver/caddy-storage-redis v1.1.2
#   - github.com/ueffel/caddy-brotli v0.4.0

    Quand quelque chose ne marche pas, vous lisez le fichier avant de lire la config.

Notes d’exploitation

  • Un build personnalisé ne se met pas à jour automatiquement via apt upgrade. Soit engagez-vous dans des rebuilds scriptés en CI, soit utilisez le binaire standard et acceptez l’ensemble de modules standard.
  • Les plugins de dépôts non maintenus se construisent toujours mais peuvent casser sur les sauts de version mineure de Caddy. Épinglez le hash de commit de chaque plugin dans votre script de build et révisez avant de bumper Caddy.
  • L’équipe Caddy maintient une page « liste des modules » sur caddyserver.com — utile pour découvrir des plugins, mais la page ne valide pas le statut de maintenance. Vérifiez le dernier commit du dépôt avant d’adopter.
  • Le drapeau --with-replace de xcaddy vous permet de pointer vers un fork local pendant le développement du plugin. Utile pour la revue de sécurité quand vous voulez auditer la source d’un plugin avant de lui faire confiance.
  • Un binaire construit avec xcaddy inclut le runtime Go et la bibliothèque standard ; un binaire personnalisé typique atterrit à 40-60 Mo. Le lien statique signifie aucune incompatibilité de bibliothèque partagée à l’exécution — une fonctionnalité, pas un problème.

Stack Harbor maintient des binaires Caddy personnalisés pour les clients dont les charges ont besoin de l’écosystème — fournisseurs DNS câblés à leurs vrais registraires, backends de stockage partagés entre nœuds, modules d’authentification intégrés à leur fournisseur d’identité — et on traite le pipeline de build comme du code sous revue. Si vous faites tourner une pile Caddy qui a besoin de plus que les modules standard et que vous voulez le build/test/déploiement de ce binaire opéré pour vous, c’est le genre de travail couvert par notre pratique Exploitation infogérée.