Migrer son site wordpress

Hello les amis !!

Aujourd’hui un petit article qui va vous expliquer comment migrer un site wordpress. Il existe déjà pas mal d’article sur le sujet, je vais donc essayer de vous expliquer en détail comment faire en prenant comme cas concret la récente migration du site KZ Enjoy sur lequel vous êtes actuellement.
En effet, j’hébergais le site sur un serveur kimsufi (lowcost OVH), premier de la gamme et ça devenait vraiment charrette niveau perf, d’autant plus que j’héberge également un autre site pour un ami, bref j’ai donc commandé un serveur de gamme supérieur (tout en conservant l’actuel pour le moment) sur lequel j’ai migré le site.

J’avais donc un serveur A avec le site KZ Enjoy qui tournait et un nouveau serveur B qui était mon serveur cible.

Migration_WP_serveurs

Non seulement le site allait migrer mais je souhaitais également troquer le bon vieux serveur Apache pour un serveur Nginx qui est plus dans l’air du temps.

Le but étant bien sur de faire la migration de manière transparente, je vais vous expliquer les étapes que j’ai réalisé afin d’arriver à mes fins !

Quelques prérequis avant de commencer : Nous supposerons que l’installe de base sur le serveur est OK (accès SSH, iptables…etc)

1er étape : Les sauvegardes.

Inutile de le préciser mais s’il y a bien un truc important dans une migration c’est bien les sauvegardes !!
Un site WordPress se compose de 2 partie essentielles :

  • Le site : C’est le dossier racine de votre site où sont stockés les pages web, les images…
  • La base de donnée : C’est là qu’est stocké le contenu de votre site (articles, préférences…).

Je préfère le préciser, sait-on jamais, mais les commandes qui suivent sont à faire sur l’ancien serveur hein, pas le nouveau 😉

Sauvegarde du site :

Chez moi le dossier du site était contenu dans « /var/www/wordpress/ », c’est donc lui qu’il faut que je sauvegarde. Pour éviter de devoir télécharger des milliers de petits fichiers, j’en ai juste fait une archive avant.

Puis via WinSCP j’ai récupéré mon archive (bah oui je suis sous Windows..).

Sauvegarde de la base de donnée :

Alors là le but du jeu c’est de se connecter à mysql et d’extraire la base de donnée qui nous intéresse. Vous aurez besoin des paramètres que vous aviez défini à l’installation la première fois. Si vous ne vous en souvenez pas, pas de panique vous pourrez les retrouver dans le fichier wp-config.php à la racine de votre site, dont voici l’extrait qui nous intéresse (au début du fichier normalement) :

Les noms/descriptions sont assez parlant donc je ne vais pas re-détailler ici. Et si vous vous posiez la question, non « toto » n’est pas mon vrai mot de passe 😉

Maintenant pour extraire la base :

Normalement vous devriez facilement comprendre cette commande mais si desfois ce n’est pas le cas :

-u : Précise l’utilisateur.
-p : Précise le mot de passe (attention ce n’est pas une faute de frappe, le mot de passe est bien attaché au -p).
-r : Définit le fichier de sortie.
wordpress : Définit le nom de la base à extraire.

Idem qu’avant, j’ai récupéré ce fichier via WinSCP.

Me voilà donc avec 2 fichiers :

  • save_kzenjoy.tar : Qui correspond à la sauvegarde de mon site.
  • 2016.05.13-BDD_KZENJOY.sql : Qui correspond à la sauvegarde ma base de donnée.

2ème étape : Installation du serveur cible.

Préparation : 

On va maintenant installer les services web et SQL sur le nouveau serveur. N’oubliez pas de changer de fenêtre dans votre terminal hein, on est sur le nouveau serveur maintenant !

On met à jour si ce n’est pas déjà fait :

Installation de tous les packages dont nous auront besoin :

Lors de l’installation de mysql-server on vous demandera un mot de passe pour le compte root, retenez le !

Vous pouvez d’ores et déjà tester que Nginx fonctionne en vous connectant simplement sur http://<IP_serveur>/. Si vous avez une erreur 403 forbidden, c’est probablement que l’utilisateur « www-data » qui gère par défaut le service nginx n’a pas les bons droits. Faites alors :

Qui a pour conséquence de changer le propriétaire du dossier /var/www et de tous les sous répertoires (-R). Réessayez et ça doit fonctionner.

Importation du site :

Faites comme vous voulez mais importez le fichier de sauvegarde du site,  save_kzenjoy.tar (dans mon cas) sur le serveur (WinSCP par exemple).

Cela extrait mon répertoire « wordpress » dans le dossier /var/www. Je le renomme histoire d’y voir plus clair :

Je me retrouve donc avec 2 dossiers : « kzenjoy » fraîchement importé et « html » qui est celui par défaut. Je dégage tout de suite celui par défaut dont je n’aurais pas besoin :

L’arborescence de mon site est donc /var/www/kzenjoy.

Importation de la base de donnée :

En premier lieu je récupère mon fichier de sauvegarde de la base « 2016.05.13-BDD_KZENJOY.sql » que je stocke sur le serveur, mais avant d’importer la base de donnée on va déjà créer ce dont on a besoin, commençons par nous connecter au serveur MySQL :

Remplacez « toto » par ce que vous avez paramétré à l’installation de MySQL quand je vous avez demandé de retenir le mot de passe…

Si la connexion a réussi votre prompt à du changer, vous êtes maintenant sur le serveur MySQL :

On va créer une base de donnée :

Oui j’en ai profité pour la faire changer de nom. Faites attention au « ; » à la fin de l’instruction sinon ça ne sera pas pris en compte. Au tour d’un nouvel utilisateur wordpress :

Puis de son mot de passe :

Oui j’aime bien le mot de passe toto et alors 🙂 On donne les supers pouvoirs à notre utilisateur sur la base en question :

Et un petit refresh :

Puis on se connecte sur la base nouvellement créée :

Et on importe le fichier de sauvegarde :

Vous devriez voir les lignes de création qui défiles. Vous pouvez faire un « SHOW TABLES; » pour vérifier que les tables ont bien été importées.

La base est prête vous pouvez quitter mysql :

Configuration du site :

Nous allons modifier les infos de connexion à la base dans le fichier /var/www/kzenjoy/wp-config.php comme ceci :

La configuration du site en lui-même est terminée, on change une dernière fois les droits sur l’arborescence du site pour être sûr :

Reste la configuration du serveur Nginx.

Configuration de PHP-FPM :

Il faut juste modifier le paramètre « cgi.fix_pathinfo » dans le fichier /etc/php5/fpm/php.ini :

et ajoutez le paramètre suivant :

Chez moi le bloc concernant ce paramètre se trouve à la ligne 774.

On peut ensuite relancer le service php-fpm :

Configuration du serveur Nginx :

Sur le même principe qu’Apache, Nginx permet d’héberger plusieurs sites avec chacun un fichier de configuration différent.
Le dossier de base de Nginx est « /etc/nginx/ ». Vous y trouverez la configuration globale et entres autres, 2 dossiers :

  • site-available : Ce dossier contient comme son nom l’indique tous les sites disponibles, c’est à dire avec un fichier de configuration par site. Il est coutume de nommer le fichier de configuration par le nom du site en question.
  • site-enabled : Ce dossier contient les fichiers de configuration des sites activés. Les fichiers sont de simples lien symboliques vers ceux dans « site-available ». Par conséquent la configuration ne se fait que dans « site-available ». Si vous souhaitez activer/désactiver un site il vous faudra respectivement créer ou supprimer le lien symbolique vers le fichier de configuration dans site-available.

Vous trouverez de base le site « défaut » dans ces dossiers. C’est ce fichier de configuration qui nous a permis d’afficher la page de bienvenue nginx avant. Bon du coup je crée mon fichier de configuration pour www.kzenjoy.net :

Qui ressemble à ça :

Bon je ne l’avais pas préciser et vous ne l’aviez peut-être pas remarqué mais le site est depuis peu en HTTPS ce qui veut dire que j’ai du importer le certificat et la clé mais je ne vous l’ai pas détaillé car pas très intéressant, partez juste du constat que j’ai importé le certificat et la clé qui va avec dans /etc/nginx/ssl/.

Pour information je ne maîtrise pas trop la partie optimisation PHP, j’ai donc utilisé le template (snippet) par défaut, présent dans le paquet nginx sur « Jessie ». Pour info ou pour ceux qui ont des versions antérieure, voilà le contenu du fichier /etc/nginx/snippets/fastcgi-php.conf :

Maintenant que notre fichier de configuration est bon, on va créer notre lien symbolique dans « site-enabled » afin de l’activer, et pour désactiver le site par défaut qui n’a plus lieu d’être (toute façon on avait supprimé le dossier « html » qui contenait sa page d’index tout à l’heure).

On a fait le tour de toutes les modifs, il ne reste plus qu’à relancer nginx 🙂

 4ème étape : Migration

La dernière étape est de faire en sorte que nos clients se connectent à présent sur le nouveau serveur et non plus l’ancien. Pour cela il suffit de modifier l’entrée DNS du nom de domaine afin de faire pointer https://www.kzenjoy.net vers l’IP du nouveau serveur. Je me connecte donc à OVH et fait la modification. Comme tout changement DNS il y a un temps de propagation jusqu’à ce que tous les serveurs DNS soit au courant.
Je voulais bien évidemment tester cela sans a voir de mauvaises surprise le lendemain, je suis donc parti à la recherche d’un DNS que je pourrais utilisé et qui serait déjà informé, en d’autres terme un DNS qui n’aurait pas eu besoin de faire la requête vers mon site ces dernières heures et donc qui aurait supprimé l’entrée de son cache. Ça tombe bien étant donnée que je n’ai pas (encore) des milliers de visiteurs/heure, il s’avère que j’en ai trouvé un assez facilement, il s’agit de OpenDNS qui met gratuitement des serveurs DNS à disposition (souvent les DNS sont bridés et n’acceptent que les requêtes venant de leur réseau, par exemple les DNS d’orange ne sont utilisables que par les personnes ayant une livebox).

Bref j’ai donc configuré un de leur serveur DNS et me suis connecté sur le site (en croisant les doigts…) et ça fonctionne !!!!

 

J’ai donc attendu les quelques heures nécessaires pour que le nouveau serveur soit propagé partout puis j’ai désactivé le serveur sur l’ancien serveur (sous apache) :

Je n’ai pas tout simplement arrêté le serveur apache car j’ai encore un autre site hébergé dessus !

 

Je tiens à préciser que je ne suis pas administrateur système et qu’il convient de prendre beaucoup plus de précaution quand à la vérification avant migration. Si je me suis permis de faire cela de manière plutôt freestyle c’est tout simplement parce que j’héberge un site dont la population aurait réussi (pour le moment) à se passer quelques heures le temps que je remette tout en ordre 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.