Indice dei contenuti dell'articolo:
Nei nostri post passati abbiamo sempre dato importanza e risalto su quanto siano importanti i servizi di DNS e di come sia fondamentale avere un TTL basso per non incorrere in problemi gravi come ad esempio dover cambiare IP d’urgenza e trovarsi impossibilitati in una propagazione veloce perchè il Time To Live (TTL) è impostato ad un giorno o più.
Potete trovare un articolo di approfondimento sul TTL dei DNS in questo post, tuttavia è anche vero che spesso si viene coinvolti d’urgenza in situazioni di pericolo in cui è necessaria una migrazione immediata di un sito web da un server ad un altro server e ci si accorge che il proprietario, il webmaster o il precedente sistemista non ha impostato il TTL dei DNS ad un valore consono come ad esempio 5, 15, 30 minuti o un’ora al massimo.
Magari la migrazione del sito e del database e la ricreazione dell’ambiente la facciamo in 1 ora, però poi dobbiamo aspettare fino ad un giorno se ci troviamo un TTL di 86400 secondi impostato, e questo in ambienti di produzione con siti che fanno traffico può essere deleterio ed estremamente dannoso in termini di immagine, visibilità, SEO, mancate vendite e fatturato.
In questo post andremo dunque a vedere come comportarsi in casi d’urgenza in cui si deve migrare un sito da un server ad un altro server, bypassando i limiti del DNS e facendo “propagare” il nuovo sito subito.
E’ richiesto ovviamente un accesso root alla macchina di origine in modo da poter lanciare comandi privilegiati.
Caso 1: Un server che gestisce un solo sito o più siti che vanno migrati in blocco su una seconda macchina.
Immaginiamo di avere un server che contiene 100 vhost, che debbono essere migrati in blocco su una seconda macchina, di questi 100 vhost, di 50 abbiamo noi la gestione del DNS, e dei restanti 50 i rispettivi clienti, su registrar diversi come ad esempio Aruba, OVH, InternetBS, Register, Godaddy, e con i più disparati valori di TTL che vanno da 5 minuti ad una settimana.
Come gestire dunque questa situazione affinchè la migrazione vada in porto correttamente e i dati siano aggiornati evitando di dover fare più migrazioni ed allineare ad esempio i post o gli ordini e le giacenze di siti che continuano a viaggiare sul server primario invece del server secondario ?
In questo caso l’opzione più sensata è quella di migrare file con rsync su un nuovo server, il database grezzo sul nuovo server, generare i pool PHP-FPM, la configurazione del webserver Apache, i certificati SSL ed avviare le istanze.
Sul server primario, quello di origine, andremo a spegnere i servizi DB, PHP e Web ed a quel punto istruiremo il firewall iptables a livello di rete di forwardare tutto il traffico entrante e destinato alle porte HTTP ed HTTPS (ovvero la porta 80 e la porta 443) verso le rispettive porte della nuova macchina.
La sintassi è molto banale ed è la seguente :
sysctl net.ipv4.ip_forward=1 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination IPDIDESTINAZIONE:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination IPDIDESTINAZIONE:443 iptables -t nat -A POSTROUTING -j MASQUERADE
Ovviamente l’esempio sopra riportato tiene conto di voler utilizzare iptables di Linux come port forwarder, magari per motivi inerenti alla rottura di un disco, un boot con una linux live, o simili, ma il concetto alla base è applicabile e proponibile a qualsiasi sistema operativo con software diversi.
Così facendo potremmo sin da subito iniziare ad usare i servizi web che già stanno girando sul nuovo server e poi istruire con calma i proprietari dei siti di cambiare il puntamento dei record DNS verso il nuovo IP, dando ad esempio come deadline un mese. Dopo un mese andremo a spegnere il server di origine, avendo tenuto conto che i clienti che gestivano in autonomia la loro zona DNS hanno ricevuto la comunicazione ed hanno avuto un tempo più che sufficiente per apportare le modifiche.
Caso 2 : un server che gestisce più siti di cui solo alcuni vanno migrati in blocco su una seconda macchina.
La casistica di esempio, è simile alla precedente, la differenza principale e fondamentale sta nel fatto che non tutti i siti vanno migrati sulla seconda macchina e dunque non posso istruire il firewall di rete a fare un port forwarding dell’intero traffico HTTP ed HTTPS sulla seconda macchina.
Debbo invece selezionare quale vhost andranno sulla seconda macchina e far si che i vhost della prima macchina siano istruiti per andare a pescare i dati e forwardare traffico HTTP ed HTTPS dalla seconda macchina.
In questo caso invece di utilizzare port forwarding a livello di rete andrò ad usare un Reverse Proxy.
Nelle reti informatiche un reverse proxy è un tipo di proxy che recupera i contenuti per conto di un client da uno o più server. Questi contenuti sono poi trasferiti al client come se provenissero dallo stesso proxy, che quindi appare al client come un server.
Per far ciò bisognerà andare nei rispettivi file di configurazione del webserver (immaginiamo Apache 2.4 o NGINX ad esempio) e specificare una serie di istruzioni affinchè si possa fare il reverse proxy dei siti già ospitati sulla seconda macchina.
Reverse Proxy in Apache 2.4
Vediamo di seguito una configurazione breve di un reverse proxy in Apache 2.4 con direttive specifiche sia per forwardare HTTP ed HTTPS nonchè evitare il check del certificato HTTPS sulla seconda macchina perchè magari ancora non abbiamo ottenuto un certificato HTTPS con Let’s Encrypt o simile.
Non andremo a trattare ovviamente tutte le direttive di Apache o il fatto che bisogna inserire moduli per far funzionare reverse proxy che può essere fatto su Debian ad esempio utilizzando : sudo a2enmod proxy && sudo a2enmod proxy_http && a2enmod ssl
<VirtualHost *:80> ServerName fcnauticaweb.com ServerAlias www.fcnauticaweb.com ProxyPass / http://65.109.65.190:80/ ProxyPassReverse / http://65.109.65.190:80/ ProxyRequests Off </VirtualHost> <VirtualHost *:443> ServerName fcnauticaweb.com ServerAlias www.fcnauticaweb.com <IfModule mod_ssl.c> SSLEngine on SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCertificateFile /var/www/clients/client0/web1/ssl/fcnauticaweb.com-le.crt SSLCertificateKeyFile /var/www/clients/client0/web1/ssl/fcnauticaweb.com-le.key </IfModule> SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off ProxyPass / https://65.109.65.190:443/ ProxyPassReverse / https://65.109.65.190:443/ ProxyRequests Off ProxyPreserveHost On </VirtualHost>
Nell’esempio sopra andiamo a forwardare un vhost che risponde al nome a dominio fcnauticaweb.com ad un web server con IP 65.109.65.190, dopodichè andremo a riavviare il web server apache tramite il comando apachectl restart.
Tutto il traffico HTTP ed HTTPS verrà forwardato alla seconda macchina con IP 65.109.65.190 e poi con “calma” ci si preoccuperà di puntare il record DNS per il dominio web all’indirizzo IP voluto, considerando che l’attuale TTL è impostato a 86400 secondi (un giorno) ed una modifica anche immediata avrebbe comportato un tempo di propagazione fino a 86400 secondi.
Reverse Proxy su NGINX.
Nell’esempio precedente abbiamo utilizzato Apache perchè il sistema originario utilizzava un pannello ISPConfig basato appunto su Apache 2.4, tuttavia avremmo potuto trovare un altro web server molto diffuso ultimamente nonchè il nostro preferito NGINX.
Anche in questo caso la cosa è molto facile e semplice considerando che la sintassi è simile e che NGINX a differenza di quello schifo di Apache non necessita di moduli aggiuntivi per fungere da reverse proxy, dato che in NGINX la funzione di reverse proxy è utilizzatissima quasi più di quella di web server.
Andiamo dunque a vedere come sarebbe stata la stessa configurazione in NGINX:
server {
listen 80;
server_name fcnauticaweb.com www.fcnauticaweb.com;
rewrite ^ https://www.fcnauticaweb.com? permanent;
}
server {
listen 443 ssl http2;
server_name fcnauticaweb.com www.fcnauticaweb.com;
root /home/mir-project/project/;
ssl on;
ssl_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/fcnauticaweb.com/privkey.pem;
ssl_session_timeout 5m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
ssl_prefer_server_ciphers on; ssl_early_data on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
location / {
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-Forwarded-Proto $scheme;
proxy_pass https://65.109.65.190:443;
}
}
Utilizzando queste tecniche sopra descritte non dovrete essere in balia di scelte e condizionamenti altrui, potrete ridurre i tempi di attesa e andare ad operare di urgenza nel vero senso della parola, ovvero ricevere richieste e garantire la soluzione entro un tempo specifico di una o due ore, un tempo utile per il committente finale che spesso non tecnico, non conosce il funzionamento della risoluzione dei nomi a dominio, ne delle limitazioni tecniche che essi impongono.
