Vous souhaitez changer d'hébergeur ? Nos conseils pour migrer votre serveur Linux efficacement !

Mathieu Codéin
Mathieu Blanc
17 mai 2021

Vous avez décidé de changer d’hébergeur et/ou d’infogéreur mais la migration du site vous inquiète : par où commencer, comment procéder, comment minimiser le temps d’indisponibilité… Voici quelques conseils et astuces pour bien vous préparer à cette opération (dans le cadre d’une migration de serveurs Linux).

Migration serveur : préparation de la nouvelle infrastructure

Votre nouvel infogéreur va devoir créer les serveurs nécessaires pour accueillir votre application. 

Il est tentant à cette étape d’en profiter pour faire de grandes modifications. Si votre site doit être indisponible quelques minutes, alors autant saisir cette occasion, par exemple, pour : 

  • mettre à jour votre application vers la nouvelle version d’un CMS ou d’un framework
  • passer à la dernière version du système d’exploitation, voire changer de système tout court

Nous considérons ici qu’une migration est une opération qui peut se révéler déjà assez complexe pour ne pas tout y mélanger. En règle générale, nous conseillons de recréer au plus proche l’environnement actuel chez votre nouvel hébergeur : même version de la distribution Linux, même version et configuration des composants systèmes et application identique.

Cela permet de limiter au maximum les régressions et de les détecter très rapidement en cas de problème. Lors d’une migration, on teste activement le site sur sa nouvelle infrastructure. Il arrive que l’on se penche sur des fonctionnalités peu utilisées de l’application et que l’on trouve des bugs. La première question qui se pose est la présence ou non de ces bugs sur les anciens serveurs.

Deux cas se présentent :

  1. le bug est présent sur l’ancienne et nouvelle infrastructure, auquel cas il s’agit d’un problème qui n’a plus rien à voir avec la migration et qui doit être réglé indépendamment
  2. le bug n’est présent que sur les nouveaux serveurs

Dans ce second cas, il sera beaucoup plus simple de trouver le souci si l’on est en présence d’une version très proche de l’infrastructure actuelle. Cela devient beaucoup plus compliqué si toutes les librairies utilisées par l’application ont été mises à jour.

Évidemment, rien n’est figé et en fonction des besoins, il est quelquefois possible, voire nécessaire de déroger à cette règle. Si l’ancienne infrastructure montre de grosses faiblesses, notamment au niveau sécurité, et qu’il faut agir vite à ce niveau, profiter de la migration pour la mise à niveau peut être envisageable. Il faudra dans ce cas porter une attention toute particulière aux tests et s’attendre à ce qu’ils durent potentiellement plus longtemps que prévu.

 

Changer d'hébergeur, que demander à son ancien infogéreur ?

Pour faciliter la création des serveurs dans les conditions énoncées plus haut, il faut demander a minima les informations suivantes à l’ancien infogéreur :

  • la distribution Linux utilisée ainsi que sa version
  • la liste des paquets installés ainsi que leur version
  • la présence ou non de logiciels extérieurs à la distribution (via des repository externes par exemple)
  • la configuration des composants critiques nécessaires à l’application (Virtual Host, php.ini…)

L’idéal est d’avoir un accès au(x) serveur(s) actuel(s) via un compte SSH. Ce compte doit permettre de récupérer l’intégralité des sources du site ainsi que pouvoir récupérer des sauvegardes des bases de données (ou les faire directement).

 

Création et test de la nouvelle infrastructure

Une fois les nouveaux serveurs en place, votre nouvel infogéreur configure un accès au futur site avec un nom de domaine temporaire pour vous permettre de tester les fonctionnalités. Ce nom de domaine peut lui appartenir ou vous pouvez lui en fournir un que vous aurez créé pour l’occasion.

Prenez garde à filtrer l’accès à ce site de test afin d’éviter que d’autres personnes ou bot ne puissent le consulter. Ce filtrage peut se faire par adresse IP ou par login/mot de passe directement géré par le serveur web (ou proxy, loadbalancer…).

Pendant cette période de tests, il peut être utile de disposer d’un script qui synchronise régulièrement les données de production avec votre site futur. Les données à synchroniser dépendent fortement du type d’application, mais en règle générale, nous trouverons :

  • les répertoires “d’upload” ou de “storage” (avec les medias)
  • la base de données

Les fichiers sources peuvent être synchronisés régulièrement, mais faites attention à ne pas écraser des modifications réalisées sur la future infrastructure (des fichiers de configuration avec des adresses IP différentes, par exemple).

Il est également conseillé de mener un test en conditions réelles, c’est-à-dire avec le vrai nom de domaine de votre site.

Problème : vous ne pouvez pas modifier vos DNS, car l’ensemble des internautes arriverait sur la future version. Il est possible de passer outre la résolution DNS en modifiant un fichier local à votre ordinateur : le fichier hosts. Ce fichier permet d’associer une adresse IP à un nom de domaine et ainsi de prendre le pas sur la résolution DNS classique.Il vous faut consulter la documentation de votre système d’exploitation pour réaliser cette modification.

 

Préparation des DNS

Votre site web est peut-être accessible via plusieurs noms de domaine. Prenez bien soin de lister tous ces noms, et de vérifier leur TTL. Le TTL (Time To Live) est une valeur exprimée en secondes qui indique aux serveurs DNS le temps de mise en cache du nom de domaine en question.

Prenons le domaine exemple.fr. Si le TTL est de 86400s sur ce domaine, une modification sur l’adresse IP pointée par exemple.fr ne pourrait être vu que 24H plus tard par certains serveurs DNS. Cela signifie qu’en cas de migration, vos internautes pourraient consulter l’ancien serveur pendant tout ce temps.

Pour accélérer la migration et permettre à tous les utilisateurs d’accéder rapidement au nouveau site, il est important de baisser les TTL quelques jours avant la migration, par exemple à 1 minute. Une fois la migration réalisée, vous pourrez remettre les TTL initiaux.

 

Points de vigilance pour une migration réussie

Il y a quelques points supplémentaires à prendre en compte avant la migration

Envoi de mail

Si votre application envoie des e-mails, il faudra certainement penser à configurer vos enregistrements SPF et à gérer vos clés DKIM 

Certificats SSL/TLS

Si votre site est accessible en HTTPS, il faut penser à avoir un certificat valide et prêt à l’emploi sur la nouvelle infrastructure. Pensez également à tester ce certificat en situation réelle (voir point sur le fichier hosts plus haut). Vous ne désirez certainement pas que votre site affiche un message d’erreur de sécurité lors de la migration.

Le Jour J

Les opérations à réaliser le jour de la migration dépendent beaucoup du type de site web que vous possédez.

On peut toutefois dégager une procédure assez générale à dérouler :

  • mise en maintenance de l’ancienne infrastructure
  • dernière synchronisation des données
  • suppression du filtrage sur la nouvelle infrastructure
  • migration des DNS

Les jours qui suivent la migration

Il est souvent utile de garder l’ancienne infrastructure en état de fonctionnement quelques jours encore après la migration. Cela vous permettra de tester et comparer les fonctionnalités une dernière fois en fonction des retours de vos utilisateurs.

Pour en savoir plus sur nos services hosting, vous pouvez consulter nos offres d'hébergement et d'infogérance ou nous contacter directement pour en discuter !

Définissez facilement vos besoins d'hébergement et d'infogérance en téléchargement notre modèle de cahier des charges Télécharger le modèle
Besoin de conseils concernant votre hébergement web ? Contactez-nous !

A lire aussi

Évaluez votre infogéreur, que faut il attendre d'une prestation d'infogérance ...
Entre le cloud privé, le cloud public et le cloud hybride, comment y voir plus ...
Voir tous les articles