L’une des problématiques de la mise en place d’IP Fail Over sur un domaine existant, c’est la perturbation d’accès au site lié au changement DNS. En effet, lorsque le changement d’IP est fait sur les DNS, il faut faire le remplacement de l’IP dans Plesk. Mais en faisant cela, le site ne pourra plus répondre sur l’ancienne adresse IP et tes utilisateurs vont donc obtenir une page d’erreur. Cette problématique réside dans le fait qu’il y a un temps de propagation des DNS et que Plesk ne gère pas l’IP multiple pour un même domaine.

Cet article va décrire une expérience que j’ai voulu tenter en remplaçant l’IP de mon site internet par une IP Fail Over mais sans avoir cette interruption de service lié au changement du DNS. L’idée va être de toucher à la configuration de Apache et de Nginx de telle sorte à ce que mon site puisse répondre sur deux IP le temps de la propagation.

J’ai un VPS chez OVH qui tourne sur du Debian, et je me sers de Plesk pour administrer le serveur. Je viens d’acheter une IP Fail Over que j’ai liée à mon VPS au niveau de la console d’OVH et je l’ai ajoutée à l’interface réseau du serveur au travers de Plesk.

Si tu ne visualises pas l’état initial, jette un coup d’oeil à l’article que j’avais fait sur IP Fail Over, cela va te permettre de mieux appréhender la suite.

Pendant toute la chirurgie, on va placer le patient (mon site) sous monitoring. En premier, j’ouvre la fenêtre d’un navigateur, c’est elle qui me permet d’accéder à mon site avec une configuration très spécifique (j’explique juste après pourquoi). Ensuite, je lance TOR browser qui va me permettre d’accéder au site comme le ferait n’importe quel utilisateur de manière classique. Le troisième élément, c’est Status Cake qui est un service qui va lancer des requêtes HTTP à intervalle régulier sur mon site depuis plusieurs serveurs établis un peu partout dans le monde et vérifier que le code de retour est du 200, ce qui signifiera que le site est bien up.

L’idée est que pendant toute la durée de l’exercice, je vais pouvoir savoir si j’ai fait une connerie, dès lors que je reçois une alerte du monitoring mis en place ou qu’un test sur mon navigateur me donne une erreur.

La première chose que je fais, c’est simuler le changement DNS en modifiant le fichier hosts de ma machine, de telle sorte à ce que mon ordinateur requête sur la future IP. Le premier test depuis mon navigateur m’indique bien que j’accède au Plesk mais que derrière il ne sait pas quoi faire.

Maintenant mon objectif, c’est de faire répondre le Plesk correctement pour ma config DNS local mais sans perturber les utilisateurs normaux qui viendraient visiter mon site de manière tout à fait habituelle, c’est-à-dire avec l’IP d’origine.

En fouillant dans la documentation de Plesk, je tombe très vite sur le path des fichiers de configuration.

Je me connecte donc en SSH, je vais dans le répertoire relatif à mon domaine et je regarde un peu ce qui s’y trouve.

En inspectant le fichier httpd.conf et le nginx.conf, je trouve ma vielle IP et je me dis à ce moment-là que je vais brancher manuellement l’écoute sur les deux IP à la fois et redémarrer les services.

Au niveau du httpd.conf, je trouve un port un peu bizarre, le 7081. Après quelques recherches, il semblerait que c’est le port d’écoute d’Apache en interne car il fonctionne en proxy avec Nginx qui lui rebalance les requêtes sur ce port. Cela ne change rien pour moi, c’est juste une donnée que je partage car souvent on va vouloir cibler tout ce qui touche à :80 (http) et :443 (https). Là, c’est une petite particularité avec le fonctionnement de Plesk.

La première chose que je fais, c’est m’assurer d’avoir accès aux commandes pour pouvoir relancer Apache ou Nginx en cas de problème.

Je fais les backups des deux fichiers de configuration qui m’intéressent. Si tu fais cela sur un serveur de production, backup tout hein.

J’ajoute ensuite mon IP dans les deux fichiers. Pour Apache, j’ai localisé ma veille IP et j’ajoute juste à la suite la nouvelle, tel que j’ai pu l’observer dans de la documentation en ligne à propos des virtualhost. Je fais cela à deux endroits, pour Apache dans le fichier httpd.conf, tandis que pour Nginx j’ai ajouté une nouvelle ligne listen au début du fichier nginx.conf, voici à quoi ça ressemble :

Maintenant, pour prendre en compte la nouvelle configuration, il faut effectuer un redémarrage. Juste avant, je contrôle quand même que mon site est toujours en ligne sur mon navigateur avec ma config local, sur TOR, et je check Status Cake. Il est bien disponible !

Je dois garder à l’esprit aussi que les fichiers que je viens de modifier peuvent se réécrirent à tout moment, c’est souvent le cas lorsqu’on fait une modification dans la subscription au niveau du hosting, mais ça pourrait être le cas si Plesk fait une mise à jour et même peut-être dans d’autre cas, c’est à prendre en considération dans l’opération. Pour limiter un peu ce risque, j’ai délibérément stoppé les mises à jour de Plesk.

Et le moment tant attendu, le redémarrage des services en une ligne de commande.

Après l’exécution (qui est totalement transparente), je refais un test sur mon local et le site répond enfin, sur TOR mon site est toujours accessible et le service Status Cake n’a toujours pas émis d’alerte, donc ça semble tourner sur deux IP !

Le seul truc bizarre mais qui ne l’est pas, j’ai placé dans un script PHP une ligne qui me permet de voir la superglobale SERVER_ADDR. Je m’attendais à voir deux IP différentes en fonction de l’IP de destination mais cela n’a pas été le cas.

À ce stade et d’après ce que je constate, j’en déduis que si je change ma zone DNS le site devrait toujours répondre et j’ai vraiment envie de réaliser l’expérience jusqu’au bout.

Je vais donc dans OVH et je procède au changement DNS en modifiant l’entrée A du domaine nouslesdevs.com !

Et bien évidemment, je fais un contrôle sur un peu tous les environnements pendant la propagation. En passant, j’utilise la plateforme whatsmydns pour faire des tests de propagation DNS. Tu peux voir sur le screenshot ci-dessous que l’IP est en train d’être propagée mais que ce n’est pas encore le cas partout, mon site est toujours en ligne et mon monitoring me signale que tout est au vert.

Une fois que l’entrée DNS a totalement été propagée (moi j’ai attendu le lendemain), j’exécute le changement définitif de l’IP au niveau de Plesk. J’avais déjà écrit un article mais la commande est vraiment toute bête donc je la remets ici.

Et comme mentionné plus haut, de fait d’avoir lancé cette commande, Plesk a réécrit les fichiers httpd.conf et nginx.conf en remplaçant la configuration spéciale que j’avais faite pour que le site réponde sur deux IP. Maintenant, il y a uniquement l’IP Fail Over présent. Mon site est toujours en ligne et il n’y a eu aucune interruption de service pendant toute l’opération.

J’ai fait cette expérience pour répondre à la problématique de l’indisponibilité du site lors de la mise en place d’une IP Fail Over sur un domaine existant, qui nécessite un changement de DNS et donc un délai d’attente pour répondre sur depuis le nouveau serveur. Le périmètre d’étude se concentrait essentiellement sur le fait que le serveur a toujours la capacité de rendre la page web, je n’ai pas pris en considération d’autres éléments et certaines choses auraient pu être impactées. Cet article va surtout me servir comme référence de fonctionnalité technique et établir une base de discussion avec des gens vraiment experts en la matière (l’équipe Plesk), pour que cela soit possible à l’avenir, en tout cas sur Plesk.

Remplacer l’IP de son site sans provoquer une interruption de service, c’est possible, assez simple, ça demande juste une bonne méthodologie et une bonne compréhension sur toute la chaîne de délivrabilité d’un site web (serveur, HTTP, DNS, Apache,…).

Si toi aussi tu te lances dans ce changement, je te conseille de prendre ton temps, de faire un test sur un sous-domaine comme j’ai pu le faire, de sauvegarder tout ton serveur, bref… De prendre toutes les précautions qui s’imposent.