Déployer sur Caddy
Caddy est le serveur web de référence de Chinaski : TLS automatique, et deux éléments de câblage par instance : un site block qui sert la sortie statique, et le snippet de redirection généré par le builder inclus par site. Cette page parcourt une configuration Caddy de production ; le Caddyfile d'exemple livré est la copie source de laquelle partir.
Prérequis
- Une instance du CMS en cours d'exécution (l'unité
chinaski@<N>), le daemon lié au loopback. - Un répertoire de sortie construit par langue (
/var/www/chinaski<N>/output/<lang>, ououtput/pour les sites monolingues). - Le
deploy/chinaski.Caddyfile.examplelivré, à copier.
Copier et adapter l'exemple
Caddy n'a pas de templating d'instances, donc chaque déploiement reçoit sa propre copie modifiée. Dans l'exemple, définissez par instance :
- Les noms d'hôte du site (domaine d'admin plus tous les vhosts de langue).
- Le port upstream : l'adresse loopback correspondant à
LISTEN_URLdans le fichier env de cette instance (instance 1 → 3001, instance 2 → 3002). - Les document roots : les répertoires de sortie par langue.
Caddy obtient et renouvelle automatiquement les certificats TLS dès que le DNS pointe vers l'hôte et que les ports 80/443 sont joignables : pas d'étape certbot. Vérifiez avec curl -I https://<host> après le premier démarrage.
Les forwards inclus dans l'exemple
Un site Caddy pour l'essentiel statique transfère quand même ces routes au daemon du CMS sur le loopback :
/forms/*: rendu public des formulaires et traitement des POST. Sans cela, les soumissions des formulaires intégrés renvoient 404./documents/*: téléchargements de documents (le chemin de suivi et de comptage qu'un serveur de fichiers statique ne peut pas faire).- Les chemins honeypot des scanners (
/.env,/.git/config,wp-login.phpet compagnie), routés vers le CMS pour que les sondes soient journalisées et limitées au lieu de recevoir un simple 404 de serveur.
L'exemple inclut aussi une route de téléchargement d'installateur servie directement depuis le répertoire de déploiement, pratique pour le motif d'URL d'installateur curl documenté.
Les directives de proxy définissent explicitement X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Host, ce que la checklist de production du README demande elle-même, et comme l'exemple proxifie depuis le loopback (de confiance par défaut), aucun CHINASKI_TRUSTED_PROXIES supplémentaire n'est nécessaire ; seul un saut de réseau de conteneurs l'exigerait.
En-têtes de cache
Le block livré correspond à la politique de cache standard (HTML en cache court revalidé à chaque build ; sw.js en no-cache ; polices immuables pendant un an ; autres ressources à la journée), et répète le jeu d'en-têtes de sécurité de l'application en ceinture et bretelles pour les réponses servies avant que l'application ne puisse le faire.
Inclure les redirections générées
Après chaque build, le builder écrit _redirects.caddy à la racine de la sortie : vos redirections de slug plus (quand une Site URL est configurée) l'application du domaine canonique dans le même _redirects que le fichier. Incluez le snippet en syntaxe Caddy dans chaque site block comme l'indique le commentaire d'en-tête du fichier lui-même ; comme la ligne de domaine canonique de Caddy utilise le marqueur de forçage 301!, ce fichier est destiné spécifiquement à Caddy (les autres hôtes devraient revoir cette syntaxe comme décrit sur la page des formats de redirection).
La confiance du loopback local signifie zéro configuration supplémentaire
L'exemple proxifie depuis 127.0.0.1, que le CMS considère déjà comme fiable, ainsi la journalisation des IP clients et la limitation par IP fonctionnent sans réglages supplémentaires. Si votre topologie proxifie depuis une adresse non loopback (un bridge de conteneur, par exemple), ajoutez ce réseau à CHINASKI_TRUSTED_PROXIES pour que la vraie IP visiteur soit celle journalisée et limitée.