Migrer un site vers un nouveau serveur sans coupure

Conventions et cadre d'intervention

Toutes les valeurs propres au site sont notées en placeholders : DOMAINE (le nom de domaine à migrer), IP_CIBLE (l'adresse du serveur de destination), IP_ACTUELLE (l'adresse qui sert le site aujourd'hui), DOCROOT (la racine du site sur la cible). Ne laissez jamais les valeurs réelles d'un client dans un script partagé.

Cette procédure couvre le déplacement d'un site existant vers un nouveau serveur Apache, avec changement d'hébergeur DNS si nécessaire, sans interruption visible pour les visiteurs ni pour la messagerie. Elle ne couvre pas la refonte du site : ce qui arrive sur la cible est ce qui tournait sur la source.

Trois règles en découlent :

1. Le certificat existe avant le DNS. Contre-intuitif, mais c'est ce qui rend la coupure nulle. Le motif est au piège n°1.
2. Jamais la délégation et le contenu en même temps. Un seul changement à la fois, chacun vérifiable isolément.
3. Aucune étape n'est validée sur une absence d'erreur. On vérifie par une observation positive : une page qui répond, un mail réellement reçu, une empreinte identique.

Vue d'ensemble

Les quatre questions à trancher avant tout

Ces quatre réponses déterminent la forme que prendra la migration. Les obtenir prend dix minutes, les découvrir en cours de route coûte une soirée.

# HSTS : sur l'apex ET sur www, les deux peuvent differer
curl -sI https://DOMAINE/     | grep -i strict-transport
curl -sI https://www.DOMAINE/ | grep -i strict-transport

# joker : si un sous-domaine invente repond, il y en a un
dig +short A zzz-test-inexistant.DOMAINE

L'objectif est simple : ne rien découvrir en cours de route. Tout ce qui n'aura pas été relevé ici se manifestera après la bascule, au pire moment.

for T in A AAAA MX TXT NS CAA SOA; do
  echo "== $T"; dig +short $T DOMAINE @8.8.8.8
done
dig +short TXT _dmarc.DOMAINE
dig +short CNAME www.DOMAINE

# Resolve-DnsName affiche les TXT complets la ou nslookup les tronque
Resolve-DnsName DOMAINE -Type TXT -Server 8.8.8.8 | % { $_.Strings -join "" }

Sauvegarder la configuration du serveur cible

Le serveur de destination héberge souvent déjà des sites en production. Avant d'y écrire quoi que ce soit :

sudo tar -czf /var/backups/apache-avant-migration-$(date +%Y%m%d).tar.gz -C / etc/apache2
sudo apache2ctl -S > /var/backups/vhosts-avant-$(date +%Y%m%d).txt

Déployer les fichiers

Préférez une archive en flux à une copie fichier par fichier : c'est plus rapide, et le transfert est atomique.

tar -czf - -C /chemin/local . | ssh serveur 'tar -xzf - -C DOCROOT'

# des deux cotes, comparer l'empreinte du manifeste
find . -type f -exec md5sum {} \; | sort -k2 | md5sum

Écrire le vhost HTTP

<VirtualHost *:80>
    ServerName DOMAINE
    ServerAlias www.DOMAINE
    DocumentRoot DOCROOT

    <Directory DOCROOT>
        AllowOverride All
        Require all granted
    </Directory>

    # Laisse passer la validation du certificat sans reecriture.
    <Directory DOCROOT/.well-known/acme-challenge>
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/DOMAINE-error.log
    CustomLog ${APACHE_LOG_DIR}/DOMAINE-access.log combined
</VirtualHost>

Écrire le vhost HTTPS, sans l'activer

Écrivez-le maintenant, activez-le en phase 03. Il référence un certificat qui n'existe pas encore : l'activer ferait échouer le rechargement d'Apache, et donc tomber les autres sites du serveur.

<VirtualHost *:443>
    ServerName DOMAINE
    ServerAlias www.DOMAINE
    DocumentRoot DOCROOT

    <Directory DOCROOT>
        AllowOverride All          # le meme oubli ici casse tout au passage HTTPS
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/DOMAINE/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/DOMAINE/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Monter une préversion

Deux méthodes, selon que vous devez la montrer au client ou non.

Tunnel

Port en écoute sur 127.0.0.1 uniquement, atteint par ssh -L. Personne d'autre ne peut y accéder, y compris les robots.

Filtre IP

Port ouvert mais Require ip VOTRE_IP. Montrable au client sans tunnel, à condition qu'il ait une adresse fixe.

Listen 127.0.0.1:8083
<VirtualHost 127.0.0.1:8083>
    ServerName DOMAINE
    DocumentRoot DOCROOT
    <Directory DOCROOT>
        AllowOverride All
        Require all granted
    </Directory>
    # Evite que le .htaccess ne redirige vers le site actuel.
    RequestHeader set X-Forwarded-Proto "https" early
    Header always set X-Robots-Tag "noindex, nofollow"
</VirtualHost>

Recette complète

Balayez toutes les URL, pas trois au hasard. Le sitemap fournit la liste, il suffit de la dérouler.

for u in $(grep -oE "<loc>[^<]+" DOCROOT/sitemap.xml | sed "s|<loc>||; s|https://DOMAINE||"); do
  p=${u:-/}
  c=$(curl -s -o /dev/null -w "%{http_code}" -H "Host: DOMAINE" \
       -H "X-Forwarded-Proto: https" "http://127.0.0.1$p")
  [ "$c" = "200" ] || echo "ÉCHEC $c : $p"
done

Contrôlez aussi, à la main : une page inexistante (elle doit rendre un vrai 404), les feuilles de style et les scripts, les images, et les URL avec une barre oblique finale, qui sont la forme servie par la plupart des CMS. Voir piège n°10.

Deux routes, selon que vous avez ou non accès à l'interface qui gère la zone active.

Route A : la zone actuelle est éditable

Une seule action ici : abaisser le TTL de l'enregistrement A à 300 secondes, au moins 24 h avant la bascule (ou la durée du TTL actuel s'il est plus court). Sans cela, un retour arrière mettrait autant de temps à se propager que l'ancien TTL, et le filet ne servirait à rien.

Route B : il faut changer d'hébergeur DNS

Cas fréquent : le client n'a pas les accès à l'interface actuelle, ou la zone est chez un prestataire injoignable.

Procédez en trois temps découplés, jamais en un seul geste.

B1. Rendre la zone de destination identique à la zone active

Recréez enregistrement par enregistrement, en gardant l'adresse A actuelle (IP_ACTUELLE). Oui, c'est contre-intuitif : à ce stade on reproduit l'existant, on ne migre rien.

• Tous les MX, avec leurs priorités exactes. Il en manque presque toujours un.
• Le SPF, qui est fréquemment celui de l'hébergeur DNS et non celui de la messagerie réellement utilisée. C'est l'erreur la plus discrète et la plus coûteuse : elle ne se voit pas, elle se constate le jour où les destinataires ne reçoivent plus rien.
• Les jetons de vérification (google-site-verification et consorts) : les perdre casse silencieusement les outils du client.
• Supprimez les entrées incohérentes avec la messagerie réelle : CNAME vers mail, imap, pop3, smtp, autoconfig, autodiscover, enregistrements SRV. S'ils pointent vers un service que le client n'utilise pas, ils configureront ses logiciels de messagerie sur le mauvais serveur.
• Abaissez le TTL du A à 300.

B2. Vérifier avant de basculer

Interrogez directement les serveurs de la zone préparée, même si elle n'est pas encore active. C'est possible, et c'est le seul contrôle qui vaille.

dig +short MX  DOMAINE @serveur-dns-destination
dig +short TXT DOMAINE @serveur-dns-destination
dig +short A   DOMAINE @serveur-dns-destination

Comparez au relevé de la phase 00. Tant que les deux zones ne sont pas équivalentes, ne basculez pas la délégation.

B3. Basculer la délégation

Changez les serveurs DNS chez le registrar. Comme les deux zones répondent la même chose, rien ne change de visible. La propagation prend de quelques minutes à 24 h, pendant lesquelles une partie du monde interroge l'ancienne zone et l'autre la nouvelle, sans conséquence puisqu'elles sont identiques.

dig +short NS DOMAINE @8.8.8.8      # les nouveaux serveurs
dig +short MX DOMAINE @8.8.8.8      # INCHANGE

Le DNS pointe encore vers l'ancien hébergement : le certificat s'obtient donc par défi DNS-01, le seul qui n'exige pas que le domaine pointe déjà vers le serveur.

sudo certbot certonly --manual --preferred-challenges dns \
  --cert-name DOMAINE -d DOMAINE -d www.DOMAINE

Certbot demande deux enregistrements TXT sur deux noms distincts : _acme-challenge.DOMAINE et _acme-challenge.www.DOMAINE. Avant d'appuyer sur Entrée, vérifiez que la valeur est réellement publiée. Le quota est de cinq échecs par heure : la vérification coûte dix secondes, l'échec coûte un créneau.

dig +short TXT _acme-challenge.DOMAINE @8.8.8.8

Activer le HTTPS et le prouver, DNS toujours sur l'ancien serveur

sudo a2ensite zz-DOMAINE-ssl
sudo apache2ctl configtest && sudo systemctl reload apache2

Voici le test décisif : il force la résolution vers la cible sans toucher au DNS public.

R="--resolve DOMAINE:443:IP_CIBLE --resolve www.DOMAINE:443:IP_CIBLE"

curl -sI $R https://DOMAINE/          # doit repondre 200
curl -sI $R https://www.DOMAINE/      # doit rediriger vers l'apex

echo | openssl s_client -connect IP_CIBLE:443 -servername DOMAINE 2>/dev/null \
  | openssl x509 -noout -subject -dates

Côté poste de travail, l'équivalent consiste à ajouter une ligne au fichier hosts : vous naviguez alors réellement sur le nouveau site, dans un vrai navigateur, avant que quiconque ne le voie.

Elle se réduit à une seule modification : l'enregistrement A.

dig +short A  DOMAINE @8.8.8.8       # IP_CIBLE
dig +short A  DOMAINE @1.1.1.1       # IP_CIBLE
dig +short MX DOMAINE @8.8.8.8       # INCHANGE

curl -sI https://DOMAINE/ | head -1  # 200
curl -s  https://DOMAINE/ | grep -oiE "<title>[^<]*</title>"

Puis la question que l'on oublie : les autres sites du serveur répondent-ils toujours ?

Immédiatement : rendre le certificat renouvelable

sudo certbot certonly --webroot -w DOCROOT --cert-name DOMAINE \
  -d DOMAINE -d www.DOMAINE \
  --deploy-hook "systemctl reload apache2" --non-interactive --force-renewal

# PROUVER que la conversion a pris
sudo grep -E "^authenticator|^renew_hook" /etc/letsencrypt/renewal/DOMAINE.conf
sudo certbot renew --dry-run

Le --dry-run est aussi le seul contrôle qui prouve que l'ajout de ce site n'a pas cassé le renouvellement des autres certificats du serveur.

Sous 48 h, après stabilité confirmée

• Remonter le HSTS s'il avait été abaissé, à 31536000, sans includeSubDomains (le certificat ne couvre que deux noms) et sans preload (engagement quasi irréversible).
• Mettre en place la sauvegarde du nouveau site, et la vérifier par une restauration réelle. Une sauvegarde non testée ne compte pas.
• Supprimer les enregistrements _acme-challenge, devenus inutiles.

Après quelques jours

• Fermer l'ancien hébergement, une fois seulement que le filet n'est plus nécessaire.
• Déclarer le site aux outils pour webmasters et soumettre le sitemap.
• Prévenir le client que la reprise du référencement demande 4 à 8 semaines, avec un creux transitoire. Annoncé, c'est une étape ; découvert, c'est un échec.

Les pièges et leurs parades

Chacun a été rencontré en conditions réelles. Aucun ne produit de message d'erreur explicite, et c'est précisément ce qui les rend coûteux.

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteCond %{HTTP:X-Forwarded-SSL} !=on
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 [R=301,L]

grep -n "Strict-Transport-Security" .htaccess
sed -i 's|ancienne valeur|nouvelle valeur|' .htaccess

[ "$(grep -c '<IfModule' .htaccess)" = "$(grep -c '</IfModule>' .htaccess)" ] \
  && echo "OK" || echo "BLOC NON FERMÉ : Apache renverra 500 sur tout le site"

Aide-mémoire

Trois listes, à trois moments. Chaque ligne se valide par une observation positive, jamais par l'absence d'erreur.

Commandes de référence

dig +short A DOMAINE @8.8.8.8
dig +short MX DOMAINE @serveur-autoritaire   # interroge une zone meme inactive
dig +noall +answer A www.DOMAINE @serveur    # revele si la reponse vient d'un joker

curl -sI --resolve DOMAINE:443:IP_CIBLE https://DOMAINE/

echo | openssl s_client -connect IP_CIBLE:443 -servername DOMAINE 2>/dev/null \
  | openssl x509 -noout -subject -dates

sudo apache2ctl configtest      # TOUJOURS avant un rechargement
sudo apache2ctl -S              # vhosts et serveur par defaut
sudo systemctl reload apache2   # ne coupe pas les connexions en cours

sudo certbot certificates
sudo certbot renew --dry-run
sudo grep -E "^authenticator" /etc/letsencrypt/renewal/DOMAINE.conf

Je peux la jouer pour vous

Cette procédure est publiée telle qu'elle est appliquée en intervention réelle. Si vous préférez la déléguer, ou si votre cas sort du cadre décrit ici, écrivez-moi : je reprends la migration de bout en bout, boîtes et postes compris.

Décrire mon cas  ·  Les autres procédures