Table des matières de l'article :
Dans nos articles précédents, nous avons toujours accordé de l'importance et mis l'accent sur l'importance des services DNS et sur le fait qu'il est essentiel d'avoir un TTL bas afin de ne pas rencontrer de problèmes graves tels que devoir changer une adresse IP urgente et se retrouver incapable d'effectuer rapidement propagation car la durée de vie (TTL) est définie sur un jour ou plus.
Vous pouvez trouver un article détaillé sur DNS TTL dans cet article, mais il est également vrai que vous êtes souvent impliqué de toute urgence dans des situations dangereuses dans lesquelles une migration immédiate d'un site Web d'un serveur à un autre serveur est requise et vous vous rendez compte que le propriétaire, le webmaster ou l'ancien administrateur système n'a pas réglé le TTL du DNS à une valeur convenable comme par exemple 5, 15, 30 minutes ou une heure au maximum.
Peut-être que la migration du site et de la base de données et la recréation de l'environnement peuvent se faire en 1 heure, mais ensuite il faut attendre jusqu'à une journée si on trouve un TTL de 86400 secondes fixé, et cela dans des environnements de production avec des sites qui faire du trafic peut être délétère et extrêmement préjudiciable en termes d'image, de visibilité, de référencement, de perte de ventes et de chiffre d'affaires.
Dans cet article, nous allons donc voir comment se comporter en cas d'urgence dans laquelle un site doit être migré d'un serveur à un autre serveur, en contournant les limites DNS et en faisant « propager » le nouveau site immédiatement.
Bien sûr, un accès root à la machine source est requis pour exécuter des commandes privilégiées.
Cas 1 : Un serveur exécutant un seul site ou plusieurs sites qui doivent être migrés en bloc vers une deuxième machine.
Imaginons que nous ayons un serveur qui contient 100 vhosts, qu'il faut migrer en bloc vers une deuxième machine, sur ces 100 vhosts, sur 50 nous gérons le DNS, et sur les 50 restants les clients respectifs, sur différents registrars comme Aruba , OVH, InternetBS, Register, Godaddy, et avec les valeurs TTL les plus disparates allant de 5 minutes à une semaine.
Alors comment gérer cette situation pour que la migration se passe correctement et que les données soient mises à jour en évitant de devoir faire plus de migrations et aligner, par exemple, les publications ou les commandes et les stocks des sites qui continuent à circuler sur le serveur primaire au lieu du serveur secondaire ?
Dans ce cas, l'option la plus sensée consiste à migrer les fichiers avec rsync vers un nouveau serveur, la base de données brute vers le nouveau serveur, générer les pools PHP-FPM, la configuration du serveur Web Apache, les certificats SSL et démarrer les instances.
Sur le serveur principal, celui d'origine, nous allons désactiver les services DB, PHP et Web et à ce moment-là nous demanderons au pare-feu iptables au niveau du réseau de transférer tout le trafic entrant et destiné aux ports HTTP et HTTPS (c'est-à-dire le port 80 et le port 443) vers les ports respectifs de la nouvelle machine.
La syntaxe est très triviale et est la suivante :
sysctl net.ipv4.ip_forward=1 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination IPDESTINATION:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination IPDESTINATION:443 iptables -t nat -A POSTROUTING -j MASQUERADE
Évidemment, l'exemple ci-dessus prend en compte le désir d'utiliser Linux iptables comme redirecteur de port, peut-être pour des raisons liées à une panne de disque, un démarrage avec un Linux en direct, ou similaire, mais le concept sous-jacent est applicable et peut être proposé à n'importe quel système fonctionnant avec différents logiciels.
Ce faisant, nous pourrions commencer immédiatement à utiliser les services Web qui fonctionnent déjà sur le nouveau serveur, puis demander calmement aux propriétaires du site de modifier le pointage des enregistrements DNS vers la nouvelle IP, en donnant, par exemple, un délai d'un mois. Après un mois, nous éteindrons le serveur d'origine, en tenant compte du fait que les clients qui ont géré indépendamment leur zone DNS ont reçu la communication et ont eu plus qu'assez de temps pour effectuer les modifications.
Cas 2 : un serveur qui gère plusieurs sites dont seuls certains doivent être migrés en masse vers une deuxième machine.
L'étude de cas est similaire à la précédente, la différence principale et fondamentale réside dans le fait que tous les sites n'ont pas besoin d'être migrés vers la deuxième machine et donc je ne peux pas demander au pare-feu du réseau de faire la redirection de port de l'ensemble du trafic HTTP et HTTPS sur la deuxième voiture.
Au lieu de cela, je dois sélectionner les vhosts qui iront sur la deuxième machine et m'assurer que les vhosts de la première machine sont chargés de récupérer les données et de transférer le trafic HTTP et HTTPS à partir de la deuxième machine.
Dans ce cas, au lieu d'utiliser la redirection de port au niveau du réseau, je vais utiliser un proxy inverse.
Dans les réseaux informatiques un Proxy inverse est un type de proxy qui récupère du contenu pour le compte d'un client à partir d'un ou plusieurs serveurs. Ce contenu est alors transféré au client comme s'il provenait du même proxy, qui apparaît alors au client comme un serveur.
Pour ce faire, vous devrez vous rendre dans les fichiers de configuration du serveur Web respectif (imaginons Apache 2.4 ou NGINX par exemple) et spécifier une série d'instructions afin que vous puissiez inverser le proxy des sites déjà hébergés sur la deuxième machine.
Proxy inverse Apache 2.4
Ci-dessous, nous voyons une brève configuration d'un proxy inverse dans Apache 2.4 avec des directives spécifiques à la fois pour le transfert HTTP et HTTPS ainsi que pour éviter de vérifier le certificat HTTPS sur la deuxième machine car nous n'avons peut-être pas encore obtenu de certificat HTTPS avec Let's Encrypt ou similaire.
On ne rentrera évidemment pas dans toutes les directives Apache ou sur le fait qu'il faut insérer des modules pour faire fonctionner le reverse proxy ce qui peut se faire sur Debian par exemple en utilisant : sudo a2enmod proxy && sudo a2enmod proxy_http && a2enmod ssl
ServerName fcnauticaweb.com ServerAlias www.fcnauticaweb.com ProxyPass / http://80:65.109.65.190/ ProxyPassReverse / http://80:65.109.65.190/ ProxyRequests Off Nom du serveur fcnauticaweb.com Alias du serveur www.fcnauticaweb.com SSLEngine sur SSLProtocol Tous -SSLv80 -SSLv443 -TLSv2 -TLSv3 SSLCertificateFile /var/www/clients/client1/web1.1/ssl/fcnauticaweb.com-le.crt SSLCertificateKeyFile /var/www/clients/client0/web1/ssl/fcnauticaweb .com-le.key SSLProxyEngine activé SSLProxyVerify aucun SSLProxyCheckPeerCN désactivé SSLProxyCheckPeerName désactivé ProxyPass / https://0:1/ ProxyPassReverse / https://65.109.65.190:443/ ProxyRequests désactivé ProxyPreserveHost activé
Dans l'exemple ci-dessus, nous allons transférer un vhost qui répond au nom de domaine fcnauticaweb.com vers un serveur Web avec IP 65.109.65.190, après quoi nous allons redémarrer le serveur Web apache à l'aide de la commande apachectl restart.
Tout le trafic HTTP et HTTPS sera transmis à la deuxième machine avec l'IP 65.109.65.190, puis avec "calme", nous nous soucierons de pointer l'enregistrement DNS du domaine Web vers l'adresse IP souhaitée, étant donné que le TTL actuel est défini sur 86400 secondes (un jour) et même une modification immédiate aurait entraîné un temps de propagation allant jusqu'à 86400 secondes.
Proxy inverse sur NGINX.
Dans l'exemple précédent, nous avons utilisé Apache car le système d'origine utilisait un panneau ISPConfig basé précisément sur Apache 2.4, mais nous aurions pu trouver un autre serveur Web très populaire ces derniers temps ainsi que notre NGINX préféré.
Dans ce cas également, la chose est très facile et simple étant donné que la syntaxe est similaire et que NGINX contrairement à cette merde Apache ne nécessite pas de modules supplémentaires pour agir comme un proxy inverse, étant donné que dans NGINX, la fonction de proxy inverse est presque plus utilisée que celle de serveur Web.
Voyons donc à quoi la même configuration aurait ressemblé dans NGINX:
serveur { écouter 80 ; nom_serveur fcnauticaweb.com www.fcnauticaweb.com ; réécrire ^ https://www.fcnauticaweb.com ? permanent; } serveur { écouter 443 ssl http2 ; nom_serveur fcnauticaweb.com www.fcnauticaweb.com ; root /home/mir-project/project/ ; SSL activé ; certificat_ssl /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem ; clé_certificat_ssl /etc/letsencrypt/live/fcnauticaweb.com/privkey.pem ; SSL_session_timeout 5 m ; ssl_protocols TLSv1.2 TLSv1.3 ; chiffrements_ssl -AES256-GCM-SHA384 : ECDHE-ECDSA-AES256-SHA384 : ECDHE-RSA-AES20-SHA1305 : ECDHE-ECDSA-AES20-SHA1305 : ECDHE-RSA-AES128-SHA256 ; ssl_prefer_server_ciphers activé ; SSL_early_data activé ; ssl_dhparam /etc/ssl/certs/dhparam.pem ; ssl_session_cache partagé : SSL : 128 m ; add_header Strict-Transport-Security "max-age=256 ; includeSubdomains" ; ssl_stapling activé ; ssl_stapling_verify activé ; ssl_trusted_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem ; résolveurs 256 384 valid=256s ; emplacement / { proxy_set_header Host $host ; proxy_set_header X-Real-IP $remote_addr ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header X-ForwardedProto $scheme ; proxy_pass https://384:128; } }
En utilisant ces techniques décrites ci-dessus, vous n'aurez pas à être à la merci des choix et des influences des autres, vous pourrez réduire les temps d'attente et aller opérer en urgence dans le vrai sens du terme, c'est-à-dire recevoir les demandes et garantir la solution dans un délai précis d'une ou deux heures, une fois utile pour le client final qui est souvent non technique, ne connaît pas le fonctionnement de la résolution de noms de domaine, ni les limitations techniques qu'elles imposent.
