Caddy est un serveur Web moderne et populaire conçu pour des performances élevées et la sécurité de la mémoire. Il est écrit en Go, s’exécute sans dépendances, offre une prise en charge intégrée du rendu de site statique avec Markdown et offre un HTTPS automatique.
Caddy se concentre sur la fourniture d’une expérience de gestion de serveur simple qui vous offre des fonctionnalités utiles par défaut. Il peut être plus facile à configurer et à entretenir que des systèmes concurrents tels qu’Apache et NGINX. Dans cet article, nous montrerons comment faire fonctionner votre propre serveur avec une configuration minimale en utilisant Docker avec l’image officielle de Caddy.
Sélection d’une balise d’image
L’image Caddy se décline en plusieurs saveurs différentes. La dernière version de Caddy est partagée par tous, c’est-à-dire v2.4 au moment de la rédaction. Vous pouvez utiliser 2.4.x (en remplacement x avec une version de correctif spécifique), 2.4ou 2 à épingler au composant majeur, mineur ou correctif.
Caddy fonctionne avec les hôtes Linux et Windows Docker. Alpine Linux, Windows Server Core 1809 et la version Windows Server Core 2016 LTSC sont les options de système d’exploitation actuelles. Faire référence à une balise Caddy nue telle que caddy:2 sélectionnera l’image appropriée pour votre plateforme ; vous pouvez utiliser des variations comme 2.4-alpine ou 2.4.6-windowsservercore-1809 au lieu d’être plus explicite.
Démarrage d’un serveur de base
Caddy est livré dans une configuration prête à l’emploi. L’image Docker servira votre contenu Web à partir du /usr/share/caddy annuaire. Vous pouvez ajouter vos fichiers au conteneur en montant un répertoire hôte sur ce chemin.
Caddy a également des répertoires de configuration et de données séparés sur lesquels vous devez monter des volumes Docker. le /config répertoire est facultatif mais recommandé ; il stocke vos fichiers de configuration, mais comme ceux-ci sont convertis en requêtes API, ils n’ont pas strictement besoin d’être conservés. le /data L’emplacement est vital car il contient les certificats TLS générés par Caddy, les clés privées et la configuration finale du serveur qui a été traitée par l’API.
docker run -d -p 80:80
-v ./my-website:/usr/share/caddy/
-v caddy-config:/config
-v caddy_data:/data
caddy:2
En tant que serveur HTTP, Caddy écoute par défaut sur le port 80. Ceci est lié au port 80 sur votre hôte via le -p drapeau dans l’exemple ci-dessus.
Vous pouvez maintenant visiter http://localhost dans votre navigateur pour accéder à votre site. Vous devriez voir le index.html à partir de votre répertoire de contenu monté. Vous obtiendrez la page d’accueil par défaut de Caddy si vous n’avez rien lié à /usr/share/caddy.
Configuration de HTTPS
L’une des principales caractéristiques de Caddy est sa prise en charge automatique de TLS, nous serions donc négligents de ne pas l’utiliser. Vous devez lier le port 443 en plus du port 80 pour que Caddy puisse recevoir le trafic HTTPS. Le seul autre changement consiste à fournir le nom de domaine sur lequel votre site sera servi. Tout le reste est géré par Caddy.
docker run -d -p 80:80 -p 443:443
-v ./my-website:/usr/share/caddy/
-v caddy-config:/config
-v caddy_data:/data
caddy:2 caddy file-server --domain example.com
La commande après le nom de l’image est passée par docker run au point d’entrée de l’image Docker. Dans ce cas, cela signifie caddy file-server ... est exécuté en tant que processus de premier plan du conteneur. le --domain flag est utilisé pour définir le domaine pour lequel Caddy acquerra un certificat HTTPS. Vous devez vérifier que vous disposez d’un enregistrement DNS de type A faisant référence à l’adresse IP de votre hôte Docker avant de démarrer le conteneur.
Ajout de votre propre Caddyfile
Caddy utilise normalement un fichier de configuration appelé Caddyfile pour définir les itinéraires et modifier les paramètres du serveur. L’image Docker charge le Caddyfile à /etc/caddy/Caddyfile. Montez votre propre fichier sur ce chemin pour remplacer les paramètres par défaut qui servent /usr/share/caddy:
docker run -d -p 80:80 -p 443:443
-v ./Caddyfile:/etc/caddy/Caddyfile
-v caddy_data:/data
caddy:2
Voici un simple Caddyfile pour un site appelé example.com avec HTTPS activé :
email [email protected]
example.com
respond "It works!"
Cette configuration minimale définit l’adresse e-mail globale sur [email protected]. Cet e-mail sera utilisé lors des demandes de certificat Let’s Encrypt. le example.com block fournit des règles de routage pour la gestion par Caddy des requêtes vers votre domaine. Dans ce cas, le serveur répondra toujours par un message statique.
Plus d’informations sur le Caddyfile sont disponibles dans la documentation de Caddy. Docker ne change rien ici : tant que votre fichier est disponible sur /etc/caddy/CaddyfileCaddy va le charger et l’utiliser.
Création d’images Docker pour vos sites
Jusqu’à présent, nous avons examiné l’utilisation ad hoc de Caddy en démarrant des conteneurs directement à partir de l’image de base de Caddy. En pratique, il est plus probable que vous souhaitiez créer des images dédiées pour vos sites afin de ne pas avoir à monter votre contenu à chaque fois que vous démarrez un conteneur.
L’image de base de Caddy est prête à être étendue avec vos propres instructions pour l’ajout de contenu et la configuration. Voici un exemple de Dockerfile qui inclut un Caddyfile et copie le contenu de votre site dans un répertoire personnalisé :
FROM caddy:2.4 WORKDIR /my-site COPY Caddyfile /etc/caddy/Caddyfile COPY *.html ./ COPY *.css css/ COPY *.js js/
Vous pouvez maintenant créer et exécuter votre image pour démarrer un serveur Caddy préconfiguré pour votre site :
docker build -t my-site:latest . docker run -p 80:80 -p 443:443 -v caddy_data:/data my-site:latest
Avec de nombreux sites, vous souhaiterez inclure des modules Caddy supplémentaires pour des fonctionnalités supplémentaires. La meilleure façon de les gérer dans votre Dockerfile est via le service dédié de Caddy builder image. Cela inclut les outils nécessaires pour créer une instance Caddy personnalisée avec des modules spécifiés installés.
Les versions multi-étapes de Docker sont idéales pour ce flux de travail. Voici un exemple qui ajoute Caddy’s replace-response module afin que vous puissiez réécrire des parties de données de réponse à l’aide de règles dans un Caddyfile :
FROM caddy:2.4-builder AS caddy-build RUN xcaddy build --with github.com/caddyserver/replace-response FROM caddy:2.4 COPY --from=caddy-build /usr/bin/caddy /usr/bin/caddy WORKDIR /my-site COPY Caddyfile /etc/caddy/Caddyfile COPY *.html ./ COPY *.css css/ COPY *.js js/
La première étape de construction produit un binaire Caddy avec le replace-response module cuit. Le xcaddy la commande disponible dans l’image du générateur place sa sortie à /usr/bin/caddy. La deuxième étape utilise l’image de base Caddy standard mais écrase le binaire inclus avec celui construit sur mesure. Votre contenu est ensuite superposé normalement ; le résultat est un serveur Caddy qui intègre des modules supplémentaires tout en conservant une prise en charge complète du reste des fonctionnalités de l’image de base Docker.
Sommaire
Caddy est un serveur Web moderne qui constitue un excellent choix pour servir efficacement des fichiers statiques. Il offre un ensemble de fonctionnalités convaincantes avec une prise en charge de première classe pour HTTPS, un rendu de modèle intégré et une intégration Markdown.
L’utilisation de Docker pour héberger votre serveur Caddy vous permet de déployer rapidement une instance sans télécharger manuellement les fichiers binaires ni installer les fichiers de service. C’est un bon moyen d’essayer Caddy ou de l’exécuter avec des charges de travail existantes dans un environnement de cluster.
Comme Caddy peut agir comme un proxy inverse et un équilibreur de charge, vous pouvez l’utiliser comme point d’entrée pour acheminer le trafic vers vos autres conteneurs Docker. Le module populaire Caddy Docker Proxy étend les capacités intégrées du serveur avec une prise en charge de type Traefik pour la découverte automatique des itinéraires via les étiquettes de conteneur Docker.
Caddy adopte une approche de configuration basée sur l’API, ce qui simplifie la gestion des instances s’exécutant à l’intérieur d’un conteneur. Vous n’avez pas trop à vous soucier de l’injection de fichiers de configuration ou de la gestion des volumes. Tant que le /data répertoire est persistant, vous pouvez faire des requêtes API pour modifier le fonctionnement de Caddy sans avoir à utiliser la CLI Docker. Cela peut en faire un meilleur choix pour la conteneurisation par rapport à des options plus traditionnelles comme Apache et NGINX.