Ah, la propagazione dei DNS... una invenzione di tutto rispetto ma una vera piaga se il sito da migrare ha una quantità di visitatori dignitosa oppure è una applicazione web che comporta importanti disservizi se va giù anche solo per poco... E se si tratta di DNS il disservizio può essere di diverse ore!
Ma non esiste un modo per ovviare al problema della propagazione dei DNS o quanto meno arginare il problema durante la migrazione della propria applicazione o sito web?
Apache, nella sua complessità, ha come di consueto un meraviglioso modulo in grado di aiutarci ma sembra un disastro come sempre da implementare se si guarda la documentazione ufficiale...
Il modulo in questione è "proxy_http".
Come funziona?
Vediamo di semplificare un po' la questione riducendola ai minimi termini.
Si tratta di reindirizzare le richieste http o https dei nostri visitatori che atterreranno sul vecchio indirizzo ip tramite questo reverse proxy fornito da mod proxy http al nuovo indirizzo ip; il nuovo server rimanderà indietro il contenuto elaborato al vecchio server che lo spedirà al visitatore.
Ecco un bel disegnino, che detto così suona un po' idiota ma che è sicuramente utile per chiarire la questione:
Non serve che ve lo racconti nuovamente, credo sia già chiaro così e da ora farò riferimento ai nomi presenti in figura.
Cosa fare quindi? Vediamo direttamente il caso con https, http ormai andrà in disuso in produzione.
Si parte col configurare i certificati per https sul server2. Si può fare anche con let's encrypt utilizzando la challenge dns ma questo è tutto un altro argomento che magari tratterò un'altra volta.
L'operazione successiva è di trasferire i contenuti dal server1 sul nuovo server2 ed eventualmente caricare il database o puntare al db originale o ad una replica, magari effettuando il tutto con uno script così si fa più in fretta, si può testare prima e si evitano errori umani.
Configurate il VirtualHost di Apache sul server2 per rispondere alle richieste dell'utente per il dominio (non verrà trattato qui come, parto dal presupposto che lo sappiate fare o che ricerchiate su Google come fare; bisognerebbe sprecare una dose eccessiva di parole e di imprecazioni per questo argomento se trattato per la prima volta).
Potete testare se sul nuovo sito tutto è funzionante modificando temporaneamente il file hosts del vostro computer puntando al nuovo dominio.
Tornate ora su server1 che in questo momento sta rispondendo da solo alle richieste degli utenti ed attivate mod_proxy con il comando:
sudo a2enmod proxy_http
Andate nel VirtualHost di server1 e piazzate tra il tag <VirtualHost> e </VirtualHost> la seguente dicitura:
SSLProxyEngine On
SSLProxyCheckPeerCN on
SSLProxyCheckPeerExpire on
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / https://7.244.5.22/
ProxyPassReverse / https://7.244.5.22/
Salvate il file e riavviate Apache con un bel:
sudo systemctl restart apache2 (per Debian e company)
sudo systemctl restart httpd (per RedHat e company... chissà perchè non si non messi d'accordo sul nome, vabbè me lo sono sempre chiesto, magari mi cercherò perché....)
Ora tutte le richieste che arriveranno a server1 verranno indirizzate a server2 anche senza girare i DNS. Direi che però a questo punto è giunto il momento di girarli eh, non ce lo dimentichiamo!
Come nota, grazie alla direttiva ProxyPreserveHost a on, questo sistema funziona anche se su server2 è attivo mod_jk per permettere ad Apache di reindirizzare le richieste in arrivo a Tomcat (anche in questo caso, magari vi parlerò un'altra volta di questa possibilità).
Mi raccomando, fate sempre prima delle prove in degli ambienti di test, è molto probabile che riavviando Apache nel punto precedente, senza aver fatto nemmeno un test, vi ritroviate la produzione giù per qualche assurdo motivo quindi la tecnica deve assolutamente essere testata prima in un ambiente sicuro.
Spero di essere stato utile e che sia tutto chiaro, se qualquaglia non cosa, fatemelo sapere né!
Marco Brenna