Home > Développement Web > Changer d’hébergement : la migration de sites web

Changer d’hébergement : la migration de sites web

October 3rd, 2008
ReTwittez ce post Goto comments Leave a comment

Vous avez un petit serveur sur lequel vous hébergez vos sites. Ces derniers ont grandi, grandi, et il est temps de prendre un serveur plus puissant, et donc de déplacer vos scripts et vos bases de données. C’est vrai, aucune compétence poussée des shells Unix n’est obligatoire ; vous pouvez très bien tout faire avec un client FTP et phpMyAdmin (par exemple). Mais cela suppose de tout copier de la machine A (le “petit” serveur) vers votre poste de travail, puis, de là, de tout envoyer, depuis votre poste, vers la machine B. En faisant tout depuis une ligne de commande, on supprime un intermédiaire. Laissons les machines s’arranger entre elles…

(Note: je travaille habituellement sous Linux Debian. Pour d’autres systèmes/distributions, il faudra sûrement adapter les options des utilitaires utilisés. La marche à suivre restera valable)

(Note en réaction au commentaire de Laurentj :
Ce billet s’adresse à des développeurs web hébergés sur des serveurs en ayant un accès SSH, et ayant conscience des problématiques de gestion d’un serveur.
L’administration système, à fortiori sur une machine connectée 24/7, est un métier à part entière, qui requiert évidemment des compétences poussées ; ne pas savoir ce que l’on fait peut être lourd de conséquences.
Les commandes présentées ici sont très simples et ce post est plus destiné à servir de “pense-bête” que de véritable tutoriel.)
Il va falloir copier les scripts et les bases de données. En supposant que vous utilisez MySQL, voici la procédure à suivre.

Pour copier les scripts, on va compresser le DocumentRoot de chaque site dans une archive tarball (.tar.gz ou .tgz). On prendra le soin d’inclure à l’archive le dump de la base de données utilisée par le site. On n’aura ainsi qu’un seul fichier à envoyer et “installer” sur le serveur B. Ainsi, on est sûrs de ne rien oublier, et la compression diminue évidemment le temps qui sera nécessaire pour le transfert.

Vu qu’on ne travaille JAMAIS sur un site qui est -pour quelques minutes encore- en production (merci de noter ça en rouge dans vos petits cahiers), on commence par créer une copie de ce dossier dans ~/backup. Le ~ signifie “répertoire /home de l’utilisateur courant”. Pour ce faire :

  1. cp -R [document_root]/ ~/backup

Où -R signifie récursif: copier aussi les sous-répertoires.

Passons ensuite dans le répertoire de backup :

  1. cd ~/backup

On réalise un dump (sauvegarde) de la base de données (attention, je parle bien ici d’une seule base, et pas du contenu complet du serveur…)

  1. mysqldump -h localhost -u [utilisateur] -p [nom_de_la_base] > [nom_du_fichier].sql

où :

  • [utilisateur] est le nom d’un user SQL qui a les privilèges en lecture sur la base
  • [nom_de_la_base] est la base qu’on souhaite copier
  • [nom_du_fichier] est le nom du fichier dans lequel sera stocké le dump (choisir un fichier qui n’existe pas…)

Il vous sera demandé (grâce à l’option -p) d’entrer le mot de passe associé à ce compte-utilisateur.

Et c’est parti pour la création du tarball :

  1. tar cvzf ../[nom_de_l_archive].tgz .

[nom_de_l_archive] étant le nom du fichier que vous voulez créer.
.. signifie “un répertoire plus haut dans l’arborescence”, donc dans le /home de l’user courant.

On peut vérifier que l’archive est bien formée et comprend bien les fichiers escomptés. Ca ne mange pas de pain et peut éviter de grosses crises d’hystérie quand on s’est raté quelque part. Listons donc le contenu de l’archive (pensez à remonter d’un cran dans l’arbo):

  1. tar -tvf [archive]

On peut ensuite copier par SCP l’archive sur le nouveau serveur (machine B):

  1. scp [nom_du_fichier].tgz [user]@[hostname]:~
  • [nom_du_fichier] étant le nom du dump généré juste au-dessus
  • [user] étant un utilisateur existant sur la machine B
  • [hostname] étant un nom de domaine qui pointe vers B, ou son adresse IP

Le ~ (tilde) veut toujours dire “dans le répertoire /home” de l’utilisateur (mais sur le nouveau serveur, cette fois). Vous pouvez indiquer n’importe quel path pour lequel l’user spécifié à le droit d’écrire (pensez à bien inclure le premier slash)

On aurait pu faire le dump directement depuis le nouveau serveur, à condition qu’on puisse se connecter au serveur MySQL de l’ancien depuis le réseau (bind-adress *) mais le dump prendrait plus de temps. Donc autant le réaliser directement depuis la machine A et l’envoyer avec le reste du site.

On passe ensuite en SSH sur la machine B. La connexion à la machine A ne servira plus ; on la coupe (une larme d’émotion est permise pour les nostalgiques).
On décompresse notre archive magique :

  1. mkdir site
  2. tar vxcf archive.tgz site/
  3. cd site

On se connecte au serveur MySQL et on crée la base de données qui va recevoir le dump :

  1. mysql -u root -p

create database [nom_de_la_base]
On monte la base de données dans le serveur MySQL.

  1. mysql -u root -p [nom_de_la_base] < [dump].sql

Où [dump] est le nom du dump qu’on a transféré et décompressé.

La base est prête ! (Pensez, si besoin, à recréer les utilisateurs MySQL qui auront les accès nécessaires sur cette base)
On crée alors le DocumentRoot du site, et on s’y rend pour y déplacer les fichiers décompressés :

  1. mkdir /var/www/[site]/
  2. cd /var/www/[site]/
  3. mv -R ~/backup/ .

C’est fait. Vous pouvez vérifier que tout fonctionne en modifiant votre fichier hosts sous Windows : Editez le avec Notepad et ajoutez la ligne “[nouvelle_ip] [www.domain.tld]“. Si vous utilisez Internet Explorer, fermez et rouvrez votre navigateur (pour que les modifications soient prises en compte) et allez voir votre site. Tout marche ? Il ne vous reste plus qu’à changer vos DNS… Migration de site accomplie ! :)

Bien sur, en faisant comme cela, vous “perdrez” les données entre le moment où vous faites le dump et celui où les DNS basculent effectivement. Vous pouvez, une fois les DNS basculés, faire une extraction des données de la base “à la mano” (un différentiel qu’on appelle souvent un Delta…) mais c’est une autre histoire…

Ce post vous a été utile ? Re-Twittez le ! ReTwittez ce post

Développement Web , , , ,

  1. Laurentj
    | #1
    Reply | Quote

    J’ai l’impression qu’il y a une contradiction sur ce billet, qui fait que l’on ne sait pas trop à quel type de personne tu t’adresses.

    En effet, tu commences par dire que “Vous avez un petit serveur sur lequel vous hébergez vos sites”. Ça veut donc dire qu’à priori, tu t’adresses à des personnes expérimentés, qui savent administrer un (petit) serveur. Mais dans la suite de ton billet, tu expliques des commandes absolument triviales pour quelqu’un qui a déjà administré un serveur linux.

    À moins que tu parles de tout ces neuneus qui louent des serveurs dédiés sans savoir s’en servir, et participant ainsi indirectement à l’expansion de tout ces bots et spams, et donc à la pollution d’internet ?

    >C’est vrai, aucune compétence poussée des shells Unix n’est obligatoire ;

    Si, posséder un serveur (et donc administrer un serveur), demande un minimum de compétences shell, systemes et cie.

    Bref, je pense que tu devrais reformuler ta phrase au début (si tu ne veux pas froisser quelqu’un ou encourager les neuneus à prendre une machine dédiée), expliciter plus clairement la cible de ce billet (“les développeurs web qui sont hébergés sur des serveurs en ayant un accés ssh”) parce que là ton discours est vraiment ambigue.

    Sinon, à propos du tutoriel proprement dit (qui est relativement clair), faire un delta n’est pas simple du tout. Car lors de la bascule DNS, tu va forcément avoir des gens qui vont accéder plus rapidement que d’autres au nouveau serveur. Cela veut dire que potentiellement, sur un blog par exemple, des gens vont pouvoir poster des commentaires sur le serveur A, et d’autres sur le serveur B. Va donc après ça faire la synchro une fois que l’ancien serveur sera définitivement inaccessible… Pour un petit blog, ça ira, mais si tu as un forums avec beaucoup de visite, c’est ingérable. (même problème si le site en question permet l’upload de fichiers : il faudrait faire aussi un delta sur les fichiers uploadés)

    Donc l’unique solution pour que tout se passe bien sans avoir ces problèmes de synchro (à moins de s’en fiche de perdre des données au passage)

    - on ferme le site (page de fermeture, avec toutes les redirections temporaires qui vont bien vers cette page, pour les problématiques de référencement, ou surtout de confort pour l’utilisateur), ou alors on désactive toutes fonctionnalités qui mettrait à jour la base ou des fichiers (fermeture des commentaires sur un blog, désactivation des posts dans un forum, désactivation des droits d’ajout/modification d’articles dans un CMS, un wiki etc…
    - Seulement à ce moment là alors, on fait la migration de la base et du site.
    - sur le nouveau serveur, une fois que c’est installé, on réactive tout ce qu’on a désactivé sur l’ancien serveur (mais on laisse l’ancien serveur en l’état)
    - On peut alors basculer les DNS.

    Pour les détails, voir un de mes billets sur le sujet : http://ljouanneau.com/blog/post/2007/10/12/714-demenagement-d-un-site

  2. Didier
    | #2
    Reply | Quote

    @LaurentJ: en effet, certaines phrases étaient un peu maladroites. Je ne voulais pas dire que tout était trivial et qu’on pouvait se lancer sans rien comprendre. L’idée était plutôt qu’on n’a pas absolument besoin de connaître toutes les options et méandres d’awk pour gérer efficacement un serveur. Et disons qu’au niveau professionnel, j’ai souvent vu une équipe technique être totalement à la masse au niveau administration, parce que celle-ci était déléguée à un prestataire.
    J’avoue aussi qu’il m’arrive de ne plus me rappeler de certaines petites options utiles (tar : t pour Test…allez comprendre, ça ne veut pas rentrer), donc le post est aussi là pour moi ;)

  1. No trackbacks yet.