Migrer votre site web sans interruption

Voici un article de réflexion (sans réelles applications techniques) sur la méthode à adopter lorsque vous migrez un site en production d’un serveur à un autre, avec changement d’hébergeur (changement de serveur, migration du nom de domaine).

Problématique

Les raisons d’une migration sont multiples, mais la problématique rencontrée est souvent la même : comment migrer le site sereinement avec un temps d’inaccessibilité minime ?

Le but ici est de contrôler chaque étape de la migration afin de ne pas subir la seule étape sur laquelle nous n’avons aucun contrôle : la migration du nom de domaine.

Lorsqu’un domaine change d’IP, les serveurs DNS racines sont mis à jour par l’hébergeur assez rapidement (quelques heures). Le processus de propagation qui en découle est cependant incontrôlable.

Les périphériques réseaux particuliers (box ADSL) et professionnels (modem ADSL, proxy) possèdent un cache DNS. En plus du cache DNS local sur votre PC, ces périphériques possèdent des fréquences de mises à jour différentes, et parfois longues.

Or, un utilisateur qui utilise d’autres serveurs DNS (par exemple ceux de Google : 8.8.8.8 / 8.8.4.4) bénéficiera assez rapidement de la mise à jour.

Pour faire simple, lorsque vous mettez à jour votre nom de domaine, certains utilisateurs bénéficieront de la modification en quelques heures tandis que d’autres devront attendre quelques jours.

La solution pour une accessibilité totale pendant la propagation de la nouvelle entrée DNS est que les deux serveurs soient accessibles sous le même domaine et pointent sur le même site !

Il ne faut pas se contenter de copier le site sur le nouveau serveur (ce qui engendrait deux sites différents). Il faudra depuis l’ancien serveur utiliser les pages et les bases de données du nouveau serveur. Nous bénéficierons alors de la même version du site sur les deux serveurs. Les données ne seront pas stockées à deux endroits différents !

Procédure

Commencez par vous procurer le nouveau serveur. Configurez vos services web habituels (Apache, PHP, Mysql, FTP, SMTP…), n’oubliez pas de créer le domaine et d’éventuels sous domaines dans la configuration d’Apache.

De manière générale, utilisez les mêmes informations de connexion.

Lorsque les services sont configurés, déplacez les bases de données vers le nouveau serveur.

Il est nécessaire de :

• Modifier les scripts encore présents sur l’ancien serveur pour qu’ils utilisent les bases de données du nouveau serveur.
• Autoriser sur le nouveau serveur l’accès distant (refusé par défaut sous MySQL, Debian)

MySQL propose un système de réplication maître / esclave. Même si le principe est intéressant, cela ne nous concerne pas puisque le serveur maître (l’ancien) est amené à disparaître.

A ce stade vous pouvez copier les pages sur le nouveau serveur.

Modifiez votre fichier hosts en local pour pointer temporairement sur le nouveau serveur avec votre nom de domaine. Vous pourrez tester l’accès direct au nouveau serveur afin de régler d’éventuels problèmes de configuration.

Afin de n’utiliser que les pages situées sur le nouveau serveur, redirigez le répertoire du site de l’ancien serveur vers celui du nouveau. Cette manipulation est possible sous Debian grace à SSHFS. Supposons que vos sites soient stockés dans le dossier /var/www, tapez les commandes suivantes (en root) sur l’ancien serveur après avoir déplacé les pages sur le nouveau :

apt-get install sshfs
sshfs -o allow_other,uid=33,gid=33 user@IPnouveauServeur:/var/www /var/www

Cette manipulation est facultative si les répertoires de vos sites ne sont pas modifiés (pas d’upload de fichier, pas de logs dans les fichiers…).

Le paramètre « -o allow_other,uid=33,gid=33 » permet à l’utilisateur www-data (celui d’Apache2, uid=33 et gid=33) d’accéder au dossier monté.

Lorsque que tout fonctionne et que les deux serveurs sont accessibles. Vous pouvez modifier la Zone DNS du côté de votre hébergeur.

Si vous utilisez Postfix depuis vos pages, n’oubliez pas de modifier les modalités d’accès au serveur. Pensez aussi à mettre à jour d’éventuels scripts de sauvegardes.

Après quelques jours et lorsque l’ancien serveur ne reçoit plus de connexions, vous pouvez l’arrêter.

Conclusion

Déplacer un site web lorsqu’il est dans une phase de production est toujours difficile et risqué. Cette procédure est le fruit d’un travail personnel « sur le terrain » qui a déjà fonctionné.