Comment g√©rer les migrations de site d'urgence sans se soucier de la propagation DNS et vivre heureux pour toujours. - ūüŹÜ Serveurs g√©r√©s
Février 3 2023

Comment gérer les migrations de site d'urgence sans se soucier de la propagation DNS et vivre heureux pour toujours.

Parfois, nous rencontrons des situations dans lesquelles le TTL du DNS est d√©fini sur un jour ou plus. Comment afficher le site migr√© imm√©diatement ?

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.

filtre-iptables

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.

Reverse Proxy

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.

dig-TTL-DNS

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.

Bannières NGINX

 

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.

Vous avez des doutes ? Vous ne savez pas par o√Ļ commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modèle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

Remonter en haut