Migrer un blog WordPress d’Apache vers Nginx, c’est simple !

Cet article a été publié il y a 7 ans 9 mois 3 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Presque simple, mais vous avez l’idée. On a déjà préparé la première étape, qui consiste à utiliser PHP-FPM comme moteur d’exécution (et éventuellement HHVM pour les aventureux), et on va voir que le reste n’est pas si compliqué, même s’il y a un petit piège à éviter surtout avec WordPress.

Avant de commencer, je tiens à signaler qu’Apache et Nginx sous tous les deux disponibles sous Windows, et même si j’ai opéré toutes les manipulations sous Debian Wheezy (déterrage de vieux brouillon power), vous devriez pouvoir adapter assez facilement les chemins et les commandes à votre environnement (c’est le cas pour tous les tutos ou presque, vous me direz). Et pour la petite histoire, j’ai d’abord testé WordPress avec une sauvegarde du blog sur ma vm maison.

Aussi, j’effectue toutes les commandes avec le compte root directement (fouettez-moi), ajoutez sudo devant celles-ci en cas de besoin.

Préparation

On commence par couper le serveur Apache, histoire de ne pas entrer en conflit avec le futur Nginx :

Ensuite, plusieurs options s’ouvrent à vous pour installer Nginx. Sur la vm de la maison, j’ai utilisé le script de nicolargo, qui récupère les sources et les compile (et procède à l’installation d’outils annexes comme PHP-FPM, redis…). Dans les dépôts de Debian Wheezy, la version est assez ancienne, 1.2.1, ce qui nous coupe d’améliorations possibles (performances, support de SPDY, et bientôt d’HTTP/2…); la version qui est fournie par la « nouvelle » version stable, Jessie, est la 1.6.2, bien plus sexy. Dernière possibilité, suivre la doc du site officielle, car l’éditeur dispose de son propre dépôt.

Comme je souhaite garder une base la plus stable possible, j’ai d’abord tenté l’aventure avec le paquet Debian « d’origine », donc la version embarquée dans Wheezy:

Les personnes ayant des besoins spécifiques pourront opter pour le paquet nginx-full afin de disposer de modules complémentaires qui pourraient être utiles. Installer le paquet me permet aussi d’envisager, une fois ajouté le dépôt Nginx, de basculer sur la version la plus récente avec peu de difficultés; en effet, Nginx dispose de modules, mais directement embarqués dans l’application, à la compilation. Il serait donc dommage d’oublier un module lors de la basule.

Configuration globale et par site

Une fois l’installation effectuée, j’ai d’abord créé le fichier /etc/nginx/conf.d/global.conf, dans lequel j’ai mis ceci :

Pourquoi procéder ainsi ? Modifier les fichiers par défaut peut entraîner des conflits lors de modifications futures par l’équipe Debian, ce qui m’est déjà arrivé avec php.ini. Si vous voulez ajuster d’autres paramètres, je vous conseille d’utiliser ce dossier (remarquez, on avait déjà procédé ainsi pour la configuration du module fastcgi d’Apache).

Bref, une fois la config de base ajustée (pas de grand chose, pour l’instant, c’est vrai), on attaque la configuration par vhost. Dans Apache on a sept vhost/sites, mais je vais me concentrer ici sur le vhost de mon blog.

Je me rend donc dans le dossier /etc/nginx/sites-available, et j’y crée un fichier blog_seboss666 dans lequel j’inclus ceci :

C’est dans ce fichier qu’il va falloir faire attention, notamment pour faire fonctionner WordPress. C’est plus particulièrement cette section qu’il faudra éventuellement ajuster pour prendre en charge la réécriture d’URL :

Une fois validé, ce fichier pourra en grande partie servir de base pour les autres (parfois à la limite du copier/coller, avec juste le server_name et root de modifiés). C’est ce que j’ai fait pour Piwik, qui est dans son propre vhost avec son propre sous-domaine, et ça marche nickel.

Activation, test, lancement

Ensuite, je crée un lien vers ce fichier dans le dossier sites-enabled :

On vérifie alors si l’on a pas fait d’erreurs :

Et si aucune erreur ou warning n’est remonté, on tente le lancement :

Si tout va bien, nginx est lancé, un netstat devrait vous permettre d’identifier nginx :

Et voilà !

Si vous constatez que vous avez bien mené votre barque, vous pouvez supprimer tout ce qui touche à Apache (un dpkg -l |grep apache vous guidera). Vous vous doutez bien que si vous lisez l’article, c’est que j’ai déjà migré sous Nginx. Je n’ai pas encore migré tous les sites par contre, et dans le prochain épisode je vous dirais comment faire cohabiter les deux serveurs Web 🙂

PS : J’avais fait le test à la maison, sur ma propre VM avec une sauvegarde du blog. Pour la version « de prod », on a procédé différemment, parce qu’on avait beaucoup de problèmes avec la VM d’alors. On est reparti de zéro, sur une VM Jessie toute fraîche, avec ISPConfig par dessus. Les modifications de configurations sont grosso modo les mêmes, mais il faut passer impérativement par l’interface d’administration, sinon vos configurations seront écrasées. J’en ai fait l’amère expérience…