Migrer de nginx, Apache ou Traefik vers Caddy

Server Manager a un parti pris pour Caddy : chaque recette et chaque assistant écrit des blocs Caddyfile, pas des blocs nginx server { }, des blocs Apache <VirtualHost> ni des labels Docker Traefik. Si ton serveur utilise actuellement l’un de ces moteurs, les recettes qui doivent modifier la configuration du proxy passent par un chemin 💬 via le chat : elles fonctionnent toujours, mais tu dois valider une action supplémentaire à chaque fois. La recette Migrer vers Caddy te fait passer de cet état à un serveur Caddy entièrement géré en environ 10 minutes, avec une étape de répétition qui permet à Faro de vérifier que chaque site est correctement traduit avant le moindre vrai basculement.

La recette prend en charge trois moteurs sources : nginx, Apache (apache2 sur Debian/Ubuntu comme httpd sur RHEL/Fedora) et Traefik (fournisseur de labels Docker). Le déroulé de la migration est le même pour les trois : seuls les détails côté source changent.

1. Ouvre Infos serveur → Serveur web

Dans la barre du haut, clique sur le nom de ton serveur pour ouvrir le panneau Infos serveur, puis clique sur l’onglet **Serveur web**.

L’onglet affiche :

• Moteur — ce qui tourne actuellement sur les ports 80 / 443 (nginx / Apache / Traefik / Caddy / rien).
• Vhosts détectés — le nombre de sites servis par le moteur (Traefik affiche plutôt des « routers »).
• Certificats TLS — qui gère tes certificats HTTPS (généralement certbot pour nginx/Apache, l’ACME intégré de Traefik pour Traefik).
• Gérabilité — une vérification de traduisibilité : un ✓ vert signifie que chaque site utilise des directives que la recette sait convertir ; un ✗ rouge indique quelle directive bloque (mod_lua, proxy_cache_path, chaînes RewriteRule complexes, middlewares Traefik, etc.). Si tu obtiens un ✗ rouge, la recette refuse de se lancer tant que tu n’as pas retiré la directive non prise en charge : c’est volontaire, la recette ne supprime jamais silencieusement un comportement.

2. Clique sur Migrer vers Caddy

Clique sur le bouton Migrer ce serveur vers Caddy →. Server Manager ouvre le panneau de chat, puis Faro prend le relais.

La recette se déroule en 5 phases. La phase 0 est en lecture seule (simple passe de vérification). Les phases 1 à 4 s’interrompent chacune pour demander ton approbation avant d’exécuter une commande destructive. Tu peux annuler à tout moment : jusqu’au basculement atomique de la phase 4, ton moteur existant reste propriétaire des ports en production et tes sites continuent de servir le trafic sans changement.

3. Approuve chaque phase

Faro explique ce qui va se passer avant chaque approbation. Les lots sont courts et ciblés.

• Phase 0 — Préparation. Lecture seule : inventorie tes vhosts existants, vérifie les directives non prises en charge et trouve l’adresse e-mail administrateur Let’s Encrypt. Se termine par un plan en langage clair + un bouton Reply: go. Clique dessus (ou tape go) pour commencer.
• Phase 1 — Installer Caddy. Ajoute le dépôt officiel Caddy, installe le paquet, puis arrête immédiatement le service. Ton moteur existant garde toujours les ports.
• Phase 2 — Traduire. Écrit un Caddyfile candidat dans /tmp et le valide. Rien ne change encore en production.
• Phase 3 — Répéter. Lance Caddy sur des ports alternatifs :8080 / :8443 pour le tester sans toucher au vrai trafic. Faro exécute ensuite lui-même des tests curl en loopback (HTTPS, redirection HTTP→HTTPS, route de challenge ACME) et te montre les preuves de réponse pour chaque domaine. Ton moteur existant continue de servir les vrais ports :80 / :443.

• Phase 4 — Basculement atomique. Sauvegarde ta configuration existante (/etc/nginx.helm-backup.<timestamp>/ ou /etc/apache2.helm-backup.<timestamp>/ ou /tmp/traefik.helm-backup.compose.*.yml), arrête l’ancien moteur, lance Caddy sur les vrais ports :80 / :443, vérifie chaque domaine avec une dernière passe curl, puis fait passer ton certbot.timer existant du mode de renouvellement par plugin moteur (certbot --nginx, certbot --apache) au mode webroot que Caddy peut servir. Le certbot.timer reste responsable du renouvellement ; un deploy-hook recharge Caddy à chaque renouvellement, donc tu n’as jamais besoin d’y toucher.

Si une vérification échoue à n’importe quel moment de la phase 4, la recette revient automatiquement en arrière : elle arrête Caddy, redémarre l’ancien moteur et laisse ta configuration existante intacte. Tu retrouves l’état d’avant migration en moins de 10 secondes.

4. Confirme + passage de relais

Une fois la phase 4 réussie, Faro te demande d’ouvrir une dernière fois Infos serveur → Serveur web pour confirmer.

L’onglet se rafraîchit automatiquement à l’ouverture (pas besoin de déconnecter/reconnecter). Tu devrais voir :

• Moteur : Caddy (service hôte)
• Certificats TLS — pour les migrations nginx/Apache : certbot (Let's Encrypt, renewed by certbot.timer; served by Caddy via deploy-hook reload). Pour les migrations Traefik : Caddy ACME (automatic Let's Encrypt) — les anciens certificats acme.json de Traefik ne sont pas réutilisés ; Caddy en obtient de nouveaux pendant le basculement.
• État : ✓ Server Manager gère ce serveur de bout en bout. Chaque recette et chaque assistant fonctionne directement ; rien ne passe par le repli réservé au chat.

Le paquet de ton ancien moteur reste installé (mais désactivé) pendant environ 30 jours comme option de retour arrière manuel. La sauvegarde de configuration reste aussi sur le disque. Quand tu es sûr que la migration est stable (environ 1 semaine), tu peux lancer apt remove nginx / apt remove apache2 pour libérer quelques Mo, ou arrêter l’ancien conteneur Traefik avec docker rm traefik.

Notes par moteur

La logique répétition-puis-basculement est la même pour tous les moteurs. Les différences sont mécaniques :

nginx. Détection du moteur source via sudo nginx -T. Sauvegarde dans /etc/nginx.helm-backup.<ts>/. Passage de relais du renouvellement : authenticator = nginx → authenticator = webroot dans /etc/letsencrypt/renewal/<domain>.conf. Le plugin certbot --nginx cesse d’être utilisé ; certbot.timer continue de tourner.

Apache. Même structure, avec les chemins remplacés par ceux de apache2 (Debian) ou httpd (RHEL). Inventaire des vhosts via apache2ctl -S + lecture de sites-enabled/ (ou conf.d/ sur RHEL). Sauvegarde dans /etc/apache2.helm-backup.<ts>/. Passage de relais du renouvellement : authenticator = apache → webroot. Les configurations mod_php sont signalées comme non gérables jusqu’à ce que tu les retires : Caddy n’exécute pas PHP dans son propre processus comme le fait Apache + mod_php.

Traefik. Le moteur source est un conteneur Docker, arrêté avec docker stop traefik (pas systemctl stop). Les vhosts proviennent des labels traefik.http.routers.* sur les conteneurs en cours d’exécution, pas de fichiers de configuration. La réutilisation des certificats est ignorée : Caddy obtient de nouveaux certificats Let’s Encrypt via l’auto-HTTPS pendant le basculement, ce qui coûte une nouvelle émission par domaine (fenêtre de certificat d’environ 30 à 60 secondes). Les routers avec des middlewares personnalisés ou des matchers autres que Host() sont signalés comme non gérables. Les backends doivent avoir des ports publiés sur l’hôte (par exemple 127.0.0.1:8080:80 dans le fichier compose) : Caddy, en tant que service hôte, ne peut pas joindre les conteneurs accessibles uniquement sur le réseau Docker.

Et si la recette refuse de se lancer ?

Si la vérification de gérabilité affiche un ✗ rouge, Faro nomme précisément la directive et le vhost concernés. Corrections typiques :

• **nginx proxy_cache_path / fastcgi_cache** — ces éléments ne se traduisent pas 1:1 vers Caddy. Retire la zone de cache (ou déplace la mise en cache vers un CDN comme Cloudflare), puis réessaie. La plupart des personnes qui n’utilisent pas Caddy sur de petits serveurs n’ont pas besoin de cache local.
• **Apache RewriteRule ... [L,R=301]** — les lots signalés indiquent des chaînes en plusieurs étapes que le traducteur ne sait pas modéliser. Convertis-les en un Redirect permanent plus simple, ou aplatis la chaîne en amont.
• Middlewares Traefik — les middlewares nécessitent une traduction Caddy par type que la recette ne fait pas automatiquement en v1. Retire les labels de middleware et applique l’équivalent dans Caddy après la migration (authentification basique, limitation de débit, en-têtes : tout est pris en charge, simplement pas traduit automatiquement).
• **Règle Traefik HostRegexp** — les matchers regex ne se traduisent pas 1:1. Remplace-les par une ou plusieurs règles Host() avec des noms d’hôte explicites.

Si tu ne peux pas simplifier ta configuration et que tu ne veux pas migrer, le chemin via le chat continue de fonctionner pour tout ce que Server Manager ferait normalement avec des recettes : déployer un site, installer WordPress, connecter un domaine, configurer une base de données, faire une sauvegarde, restaurer depuis une sauvegarde, etc. Faro lit ton moteur existant et propose les bonnes commandes natives (/etc/nginx/sites-available/ + certbot --nginx pour nginx, l’équivalent Apache, les labels Docker pour Traefik). Exemples concrets de demandes qui fonctionnent dès aujourd’hui sur un serveur non-Caddy :

• « Ajoute un nouveau site WordPress sur blog.mysite.com sur ce serveur nginx » — Faro propose le vhost nginx + le docker compose pour WordPress + certbot. Tu approuves chaque lot.
• « Mon certificat TLS pour api.mysite.com va expirer bientôt — vérifie-le et renouvelle-le si nécessaire » — Faro exécute l’inspection + le renouvellement + le rechargement, le tout dans le chat.
• « Fais une sauvegarde de la charge de travail api.mysite.com » — Faro détermine quoi exporter + comment l’empaqueter + propose le lien de téléchargement.

Tu ne perds aucune fonctionnalité en restant sur ton moteur actuel. Tu échanges simplement les actions d’interface en un clic contre des équivalents guidés par le chat.

Référence

Fichiers écrits sur ton serveur pendant la migration :

• /etc/caddy/Caddyfile — configuration des sites Caddy (nouvelle sur ce serveur)
• /var/www/certbot/.well-known/acme-challenge/ — webroot pour les renouvellements ACME (nginx + Apache ; non utilisé pour les migrations Traefik)
• /etc/letsencrypt/renewal-hooks/deploy/reload-caddy.sh — recharge Caddy à chaque renouvellement certbot (nginx + Apache uniquement)
• /etc/letsencrypt/renewal/<domain>.conf — modifié chirurgicalement pour remplacer authenticator = nginx / authenticator = apache → authenticator = webroot (nginx + Apache uniquement)

Fichiers / état conservés pour un retour arrière :

• nginx : /etc/nginx.helm-backup.<timestamp>/ (copie complète de la configuration)
• Apache : /etc/apache2.helm-backup.<timestamp>/ (Debian) ou /etc/httpd.helm-backup.<timestamp>/ (RHEL)
• Traefik : /tmp/traefik.helm-backup.compose.<timestamp>.yml (le fichier docker-compose), plus le conteneur Traefik arrêté lui-même
• Le paquet de l’ancien moteur reste installé mais désactivé (systemctl disable apache2 / nginx; docker update --restart=no traefik)

Points d’approbation : généralement 4 clics pour nginx et Apache, 5 pour Traefik (le clic supplémentaire intervient quand Faro doit choisir un port de répétition non par défaut si ton backend utilise déjà :8080).