3 février 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.

creuser-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

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de The FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

Retour en haut de page