fonte dell’Immagine: Infografica vettoriale creata da pikisuperstar — www.freepik.com

Content Delivery Network (CDN) sono generalmente utilizzati dai siti e applicazioni per velocizzare il caricamento di elementi statici. Ciò si ottiene memorizzando nella cache i file su server CDN situati in varie regioni del mondo. Dopo aver richiesto i dati tramite CDN, l’utente li riceve dal server più vicino.

I principi alla base delle CDN e la loro funzionalità sono approssimativamente gli stessi per tutti loro. Dopo aver ricevuto una richiesta per un file, un server CDN lo preleva una volta dal server di origine e quindi lo trasferisce all’utente e ne memorizza una copia nella cache per un periodo di tempo. Ulteriori richieste per i dati vengono gestite utilizzando la cache. Tutti i CDN hanno opzioni per il pre-caricamento dei file, la cancellazione della cache, i tempi di conservazione della cache e molto altro.

A volte, per vari motivi, ci si potrebbe trovare nel bisogno di costruire la propria CDN, e così, presentiamo la seguente guida su come realizzarla.

Quando hai bisogno della tua CDN?

Diamo un’occhiata alle situazioni in cui potrebbe essere necessario creare il proprio CDN:

• quando si sta cercando di risparmiare denaro e anche soluzioni accessibili come BunnyCDN alla fine costare centinaia di dollari al mese
• quando si desidera ottenere cache permanente o bisogno di larghezza di banda garantita e risorse
• esistente Cdn non hanno salta in regione di destinazione
• avete bisogno di contenuti speciali impostazioni di consegna
• per accelerare la consegna del contenuto dinamico, servendo più vicino agli utenti
• si sono preoccupati di terze parti Cdn potrebbe illegalmente raccogliere e utilizzare dati utente (hey there, i server che non sono GDPR-compliant) o impegnarsi in altre attività illecite

Nella maggior parte degli altri casi, è più praticabile utilizzare soluzioni già pronte esistenti.

Creiamo la propria CDN

Per creare anche una semplice rete di distribuzione di contenuti è necessario quanto segue:

• nome di dominio o un sottodominio
• un minimo di due server in regioni diverse. I server possono essere dedicati o virtuali
• Strumento geoDNS. Con esso, un utente che invia una richiesta al dominio verrà indirizzato al server più vicino

Registrazione del dominio e ordinazione dei server

La registrazione di un nome di dominio è semplice: basta registrarlo in qualsiasi zona di dominio che preferisci. Per CDN, puoi usare anche un sottodominio, come cdn.domainname.com. Questo il caso per il seguente esempio.

Quando si tratta di server, dovresti noleggiarli nelle regioni e nei paesi in cui si trova il tuo pubblico di destinazione. Se il tuo progetto è intercontinentale, è conveniente scegliere tra i provider di hosting che offrono server in tutto il mondo, come OVH, Leaseweb e 100Tb (per server dedicati) o Vultr e DigitalOcean (per server virtuali e cloud).

Per la nostra CDN privata, ordiniamo tre server virtuali in diversi continenti. Vultr ci offre 25 GB di spazio SSD e 1 TB di traffico per $5 / mese. Durante l’installazione, selezionare l’ultima Debian. Ecco i nostri server:

• Francoforte, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapore, ip: 157.230.240.216

Configurazione di geoDNS

Per garantire che i client siano indirizzati ai server appropriati (più vicini) dopo aver inviato richieste al nostro dominio o sottodominio, avremo bisogno di un server DNS con funzionalità geoDNS.

Ecco come funziona geoDNS:

1. Ottiene l’IP del client (se ha inviato la richiesta DNS) o l’IP del server DNS ricorsivo utilizzato per l’elaborazione della richiesta. In generale, tali server ricorsivi sono di solito i DNSS dei provider Internet.
2. Dall’IP del cliente identifica il loro paese o regione. Questa operazione richiede l’uso di database GeoIP, che sono disponibili in non scarseggiare. Ci sono anche opzioni gratuite decenti.
3. A seconda della posizione del client, geoDNS gli restituisce l’indirizzo IP del server CDN più vicino.

Un server DNS con funzionalità geoDNS è qualcosa che puoi costruire da solo, ma è meglio usare soluzioni già pronte con server in tutto il mondo e un’opzione Anycast pronta all’uso:

• ClouDNS, da 9 9.95 / mese, pacchetto GeoDNS, un Failover DNS è fornito di default
• Zilore, da $25/mese, include Failover DNS
• Amazon Route 53, da $35/mese per 50 milioni di geo-richieste. Il failover DNS è valutato separatamente
• DNS Reso facile, da $125/mese, con 10 failover DNS
• Cloudflare, la funzionalità di Geo Steering è fornita nei pacchetti Enterprise

Quando ordini geoDNS devi prestare attenzione al numero di richieste incluse nel pacchetto e tenere presente che il numero di richieste reali potrebbe superare di molto le tue aspettative. Ci sono milioni di web crawler, scanner, spammer e altre diavolerie al lavoro in un dato momento.

Quasi tutti i servizi DNS includono una funzionalità utile per la creazione di CDN: il failover DNS. Con esso, è possibile configurare il monitoraggio delle attività in modo che se un server va giù il sistema reindirizzerà automaticamente i client ai server di lavoro, invece.

Per la nostra CDN, usiamo ClouDNS e il suo pacchetto GeoDNS.

Nel profilo, aggiungi una nuova zona DNS e specifica il tuo nome di dominio. Se stai utilizzando il sottodominio e il dominio principale è in uso, non dimenticare di aggiungere i record DNS esistenti immediatamente dopo aver aggiunto la zona. Il passo successivo consiste nel creare diversi record A per il dominio/sottodominio CDN, ognuno dei quali verrà utilizzato per la regione specificata. È possibile designare continenti o paesi come regioni, e le opzioni di subregione sono disponibili per gli Stati Uniti e il Canada.

Nel nostro esempio, la CDN opererà sul cdn.sayt.in sottodominio. Dopo aver aggiunto il sayt.in zona, creare il primo Un record per il sottodominio e dirigere tutti i client NA al server di Chicago:

Ripeti questo passaggio per le altre regioni e non dimenticare di creare un record per le regioni predefinite. Ecco come appare il risultato finale:

L’ultimo record predefinito indica richieste da tutte le regioni non specificate(Europa, Africa, utenti Internet via satellite, ecc.) devono essere indirizzate al server di Francoforte.

Questo conclude la configurazione DNS di base. Tutto ciò che rimane è andare al sito Web del registrar e sostituire i nameserver correnti con quelli forniti da ClouDNS. Mentre vengono aggiornati, imposteremo i server.

Installazione dei certificati SSL

La nostra CDN funzionerà utilizzando HTTPS, quindi se si dispone già di certificati SSL per il dominio o il sottodominio, caricarli su tutti i server, ad esempio, nella directory /etc/ssl/yourdomain/.

Se non si dispone di alcun certificato, è possibile ottenere gratuitamente da Let’s Encrypt. ACME Shell script è una grande opzione. Ha un client user-friendly e, ancora più importante, consente di eseguire la convalida del dominio/sottodominio tramite DNS utilizzando API di ClouDNS.

Installeremo acme.sh su un solo server-quello europeo (199.247.18.199), e da esso, i certificati verranno copiati su tutti gli altri. Per installarlo, eseguire il seguente comando:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Durante l’installazione verrà creata un’attività CRON per l’aggiornamento automatico dei certificati.

La verifica del dominio al momento dell’emissione del certificato verrà eseguita tramite DNS utilizzando API, quindi nel profilo ClouDNS, in API rivenditore, creare un nuovo utente API e specificare una password per esso. Immettere l’auth-id risultante insieme alla password nel seguente file:~/. acme.sh/dnsapi/dns_cloudns.sh (da non confondere con dns_clouddns.sh). Ecco le linee che devi rimuovere il commento e modificare:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

Ora, richiediamo l’emissione del certificato SSL per cdn.dimmi.nel

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

Per un uso futuro, nei parametri, abbiamo lasciato un comando per il riavvio automatico della configurazione dopo ogni rinnovo del certificato.

Il processo di acquisizione del certificato potrebbe richiedere fino a due minuti, quindi non interromperlo. Nel caso in cui si verifichi un errore di convalida del dominio, provare a eseguire nuovamente il comando. Alla fine, vedremo dove sono stati scaricati i certificati.

Ricorda questi percorsi, dovremo specificarli quando copiamo i certificati su altri server e dovremo specificarli nelle impostazioni del server. Ignora l’errore di ricarica della configurazione Nginx, — non si verificherà su un server completamente configurato durante il rinnovo del certificato.

Per quanto riguarda il certificato SSL, tutto ciò che ci resta da fare è copiarlo sugli altri due server salvando i percorsi del certificato. Creare directory identiche su ciascun server e quindi copiare i file del certificato:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Per automatizzare il rinnovo del certificato, è necessario creare un’attività CRON giornaliera su entrambi i server. Di seguito è riportato il comando da aggiungere ai lavori CRON:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload</pre>

Tieni presente che la connessione al server di origine remoto richiede un accesso tramite chiave senza immettere una password. Non dimenticare di crearlo.

Installazione e configurazione di Nginx

Per la distribuzione di contenuti statici useremo Nginx, configurato come server caching proxy. Aggiorna gli elenchi dei pacchetti e installalo su tutti e tre i server:

root@cdn:~# apt updateroot@cdn:~# apt install nginx

Invece della configurazione predefinita, usa quella qui sotto:

nginx.conf

user www-data;worker_processes auto;pid /run/nginx.pid;events { worker_connections 4096; multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log off; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_proxied any; gzip_vary on; gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml; gunzip on; proxy_temp_path /var/cache/tmp; proxy_cache_path /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d; proxy_cache_bypass $http_x_update;server { listen 443 ssl; server_name cdn.sayt.in; ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer; ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key; location / { proxy_cache cdn; proxy_cache_key $uri$is_args$args; proxy_cache_valid 90d; proxy_pass https://sayt.in; } }}

In config, modifichiamo:

• max_size — cache di dimensioni non eccedenti lo spazio su disco disponibile
• inattivo — tempo di ritenzione per non dati memorizzati nella cache
• ssl_certificate e ssl_certificate_key — percorsi di SSL certificato e la chiave
• proxy_cache_valid — tempo di ritenzione per i dati memorizzati nella cache
• proxy_pass — indirizzo del server di origine, da cui il CDN, con richiesta di dati per la memorizzazione nella cache. Per il nostro esempio, è sayt.in

Come puoi vedere, non è scienza missilistica. L’unica difficoltà è la configurazione del tempo di ritenzione, date le somiglianze tra i parametri inattivi e proxy_cache_valid. Diamo un’occhiata più da vicino. Ecco cosa succede con inattivo=7d e proxy_cache_valid=90d:

• se la richiesta non viene ripetuto entro 7 giorni, l’eliminazione dei dati dalla cache
• se la richiesta viene ripetuta ancora una volta durante 7 giorni, la cache sarà considerato out-of-data dopo 90 giorni e la successiva richiesta di rendere Nginx aggiornamento dal server di origine

Con nginx.conf gestito, ricaricare la configurazione:

root@cdn:~# service nginx reload

Quindi, la nostra CDN è pronta per l’uso! Per $15 / mese abbiamo ottenuto POP in tre continenti e 3 TB di traffico: 1 TB per ogni regione.

Controllo della nostra CDN

Diamo un’occhiata a ping alla nostra CDN da diverse posizioni. Qualsiasi servizio ping farà in questo caso.

I risultati sono buoni. Ora mettiamo un’immagine di prova intitolata test.jpg sul server principale e controllare quanto velocemente si carica tramite CDN. Detto e fatto. Il caricamento è veloce.

Facciamo un piccolo script nel caso in cui abbiamo bisogno di cancellare la cache su un punto CDN.

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

Per cancellare tutta la cache sul server, è sufficiente eseguire lo script. Se hai bisogno di un file eliminato, specifica il suo percorso:

root@cdn:~# ./purge.sh /test.jpg 

Per eliminare la cache ovunque lo script deve essere eseguito su tutti i server CDN.

Al posto delle conclusioni

Infine, vorrei dare alcuni consigli utili in modo da evitare di cadere nelle insidie che ho già eliminato:

• Considera la redditività e i costi di manutenzione della tua futura CDN. Nella maggior parte dei casi, è molto efficiente e più facile acquistare una CDN economica, che molto probabilmente sarà più stabile e di migliore qualità.
• Per migliorare la tolleranza ai guasti della CDN, si consiglia di impostare un Failover DNS, che consentirebbe di cambiare rapidamente il record A nel caso in cui un server si interrompa. È possibile farlo nel pannello di controllo record del DNS.
• I siti Web con ampia copertura richiedono un gran numero di POP, ma non diventano troppo zelanti. Molto probabilmente, un utente non noterà la differenza tra il CDN e uno a pagamento, se si dispone di server in 6-7 sedi (Europa, Nord America (Est), Nord America (Ovest), Singapore, Australia, Hong Kong o Giappone).
• A volte i provider di hosting non consentono di utilizzare server affittati per CDN. Quindi, se stai cercando di creare un servizio CDN, assicurati di leggere i termini e le condizioni del provider di hosting.
• Studia la mappa dei cavi sottomarini per capire come i continenti sono collegati e usa questa conoscenza quando costruisci la tua CDN.
• Prova a eseguire il ping dei server da posizioni diverse. In questo modo, puoi individuare le regioni più vicine ai tuoi POP e ti aiuterà a configurare le GEODN.