🥇Configurazione e personalizzazione del tuo CDN

Le reti di distribuzione dei contenuti (CDN) sono utilizzate su siti web e applicazioni principalmente per accelerare il caricamento degli elementi statici. Questo avviene grazie alla memorizzazione nella cache dei file sui server CDN situati in diverse regioni geografiche. Richiedendo dati tramite il CDN, l'utente li riceve dal server più vicino.

Il principio di funzionamento e le funzionalità di tutte le reti di distribuzione dei contenuti sono abbastanza simili. Quando un server CDN riceve una richiesta di caricamento di un file, lo preleva una sola volta dal server originale e lo restituisce all'utente, memorizzandolo nel proprio cache per un determinato periodo. Per tutte le richieste successive, la risposta viene fornita dalla cache. Tutti i CDN hanno opzioni per il caricamento anticipato dei file, la pulizia della cache, la configurazione della durata di archiviazione e molto altro.

Talvolta, per varie ragioni, è necessario organizzare una propria rete di distribuzione dei contenuti, e quindi — sì, ecco a noi una guida per costruire l'ennesima bicicletta.

Fonte: Infographic vector created by pikisuperstar — www.freepik.com

Quando è necessario un CDN proprietario

Esaminiamo i casi in cui avviare un proprio CDN ha senso:

quando si desidera risparmiare, ma le spese attuali anche utilizzando CDN economici come BunnyCDN ammontano a diverse centinaia di dollari al mese
se vogliamo ottenere una cache persistente o una cache senza vicini nel server e nella banda
nel vostro regione desiderata i servizi CDN non hanno punti di presenza
sono necessarie particolari impostazioni per la distribuzione dei contenuti
vogliamo accelerare la consegna dei contenuti dinamici posizionando i server di produzione più vicino agli utenti
c'è preoccupazione che un servizio CDN esterno possa raccogliere o utilizzare in modo improprio informazioni sul comportamento degli utenti (saluti ai servizi non conformi al GDPR) o impegnarsi in altre attività illecite

Nella maggior parte degli altri casi è più conveniente utilizzare soluzioni esistenti.

Cosa serve per avviare

È fantastico se hai il tuo sistema autonomo (AS). Con esso puoi assegnare lo stesso IP a più server e seguire questa istruzione A livello di rete, indirizzare gli utenti al server più vicino. Vale la pena notare che anche con un blocco di indirizzi /24 è possibile costruire una rete di distribuzione dei contenuti. Alcuni fornitori di server consentono di effettuare un annuncio per essere utilizzato in tutte le regioni disponibili.

Se non sei fortunato possessore di un blocco di indirizzi IP, per avviare un semplice CDN avrai bisogno di:

un nome di dominio o un sottodominio
almeno due server in diverse regioni. Il server può essere sia dedicato che virtuale
geoDNS strumento. Con questo, un utente che accede al dominio sarà indirizzato al server più vicino

Registriamo il dominio e ordiniamo i server

Per la registrazione del dominio è tutto semplice: registralo in qualsiasi zona presso qualsiasi registrar. Inoltre, per il CDN puoi utilizzare un sottodominio, ad esempio qualcosa come cdn.tuodominio.com. In effetti, nel nostro esempio procederemo in questo modo.

Per quanto riguarda l'ordinazione dei server, è consigliabile affittarli nelle regioni e nei paesi dove si trova il tuo pubblico. Se il progetto è intercontinentale, è comodo scegliere fornitori di hosting che offrono server in tutto il mondo. Esempi: OVH, Leaseweb e 100Tb — per server dedicati, Vultr e DigitalOcean — per cloud virtuali*.

Per il nostro CDN privato ordineremo 3 server virtuali su diversi continenti. Su Vultr il server a 5 €/mese otteniamo 25GB SSD spazio e 1TB di traffico. Durante l'installazione sceglieremo l'ultima versione di Debian. I nostri server:

Francoforte, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapore, ip: 157.230.240.216

* Vultr e DigitalOcean offrono 100 $ di credito agli utenti registrati tramite i link nell'articolo, subito dopo aver aggiunto un metodo di pagamento. L'autore riceve anche un piccolo bonus da tale registrazione, che per lui è attualmente molto importante. Vi preghiamo di capire.

Configuriamo geoDNS

Per indirizzare gli utenti al server corretto (il più vicino a loro) quando accedono a un dominio o sottodominio CDN, avremo bisogno di un server DNS con funzionalità geoDNS.

Il principio e il funzionamento del geoDNS sono i seguenti:

Determina l'IP del cliente che ha inviato la richiesta DNS o l'IP del server DNS ricorsivo utilizzato per elaborare la richiesta del cliente. Di solito, questi server ricorsivi sono DNS forniti dai provider.
Dall'IP del cliente determina il suo paese o regione. A tal fine, vengono utilizzate banche dati GeoIP, che al giorno d'oggi sono disponibili in abbondanza. Ce ne sono di buone opzioni gratuite.
A seconda della posizione del cliente, viene assegnato un indirizzo IP del server CDN più vicino.

Un server DNS con funzione geoDNS può essere configurato autonomamente, ma è meglio utilizzare soluzioni pronte con una rete di server DNS in tutto il mondo e Anycast pronto all'uso:

ClouDNS da $9.95/mese, piano GeoDNS, per impostazione predefinita c'è un DNS Failover
Zilore da $25/mese, incluso DNS Failover
Amazon Route 53 da $35/mese per 50M di geo-query. DNS Failover è addebitato separatamente.
DNS Made Easy da $125/mese, ci sono 10 DNS Failover
Cloudflare, la funzione "Geo Steering" è disponibile nei piani Enterprise.

Quando si ordina geoDNS, si deve prestare attenzione al numero di richieste incluse nel piano e considerare che il numero reale di accessi al dominio può superare di gran lunga le aspettative. Milioni di spider, scanner, spammer e altre entità non salutari operano incessantemente.

Praticamente tutti i servizi DNS includono nel costo un servizio essenziale per la costruzione di una CDN: il DNS Failover. Con questo si può configurare il monitoraggio dei server e, in assenza di segnali di attività, sostituire automaticamente negli indirizzi DNS dell'host non funzionante con un server di riserva.

Per costruire la nostra CDN utilizzeremo ClouDNS, piano GeoDNS.

Aggiungeremo una nuova zona DNS nel pannello di controllo, specificando il nostro dominio. Se costruiremo il CDN su un sottodominio, mentre il dominio principale è già in uso, non dimenticate di aggiungere immediatamente i record DNS esistenti dopo aver aggiunto la zona. Il passo successivo è creare per il dominio/sottodominio CDN diversi record A, ognuno dei quali sarà applicato alla regione da noi specificata. Come regioni possiamo indicare continenti o paesi; per gli Stati Uniti e il Canada sono disponibili sottoregioni.

Nel nostro caso, il CDN sarà attivato su un sottodominio cdn.sayt.in. Dopo aver aggiunto la zona sayt.in, creeremo il primo record A per il sottodominio e indirizzeremo tutto il Nord America verso il server di Chicago:

Ripeteremo l'operazione per altre regioni, ricordando di creare un record per le regioni predefinite. Ecco cosa otterremo alla fine:

L'ultimo record di default nello screenshot significa che tutte le regioni non specificate (come Europa, Africa, utenti di Internet satellitare, ecc.) saranno indirizzate verso il server di Francoforte.

La configurazione di base DNS è ora completata. È necessario accedere al sito del registrar del dominio e sostituire i server NS attuali con quelli forniti da ClouDNS. Mentre i NS verranno aggiornati, prepareremo i server.

Installazione dei certificati SSL

Il nostro CDN funzionerà tramite HTTPS, quindi se hai già certificati SSL per il dominio o il sottodominio, caricali su tutti i server, ad esempio nella directory /etc/ssl/вашдомен/

Se non hai certificati, puoi ottenere un certificato gratuito da Let’s Encrypt. Per questo, si adatta perfettamente lo script ACME Shell. Il client è comodo e semplice da configurare, e soprattutto consente di effettuare la convalida del dominio/sottodominio tramite DNS attraverso l'API di ClouDNS.

Installeremo acme.sh solo su uno dei server — quello europeo 199.247.18.199, da cui i certificati verranno copiati su tutti gli altri. Per installarlo, eseguiamo:

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

Durante l'installazione dello script verrà creato un lavoro CRON per l'aggiornamento continuo dei certificati senza il nostro intervento.

Il controllo del dominio per l'emissione del certificato sarà eseguito tramite DNS utilizzando l'API, quindi nel pannello di controllo di ClouDNS nel menu Reseller API è necessario creare un nuovo utente API e impostare una password per esso. L'auth-id ottenuto con la password sarà inserito nel file ~/.acme.sh/dnsapi/dns_cloudns.sh (non confondere con il file dns_clouddns.sh). Ecco le righe che devono essere decommentate e modificate:

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

Ora richiediamo l'emissione del certificato SSL per cdn.sayt.in

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

Nei parametri, per future necessità, abbiamo indicato il comando per riavviare automaticamente la configurazione del server web dopo ogni aggiornamento della validità del certificato.

L'intero processo di ottenimento del certificato può richiedere fino a 2 minuti, non interromperlo. Se si verifica un errore di convalida del dominio, prova a eseguire nuovamente il comando. Alla fine vedremo dove sono stati caricati i certificati:

Ricorda questi percorsi, dovranno essere specificati quando copierai il certificato su altri server e anche nelle impostazioni del server web. Ignora l'errore di ricarica delle configurazioni Nginx, poiché non ci sarà su un server completamente configurato quando aggiornerai i certificati.

L'unica cosa che ci resta da fare per l'SSL è copiare il certificato ottenuto su altri due server, mantenendo i percorsi ai file. Creeremo per ciascuno di essi le stesse directory e faremo una copia:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Per garantire che l'aggiornamento dei certificati sia regolare, creeremo un'attività CRON giornaliera su entrambi i server con il comando:

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Durante questo processo, l'accesso al server di origine remoto deve essere configurato con una chiave, cioè senza inserire una password. Non dimenticare di farlo.

Installazione e configurazione di Nginx

Per servire contenuti statici utilizzeremo Nginx, configurato in modalità proxy server cache. Aggiorneremo le liste dei pacchetti e lo installeremo su tutti e tre i server:

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

Utilizziamo la configurazione dal spoiler qui sotto invece di quella di default:
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;
    }
  }
}

Modificheremo nella configurazione:

max_size — dimensione della cache, non superiore allo spazio disponibile su disco
inactive — tempo di conservazione dei dati in cache a cui nessuno ha accesso
ssl_certificate e ssl_certificate_key — percorsi ai file del certificato SSL e della chiave
proxy_cache_valid — tempo di conservazione dei dati in cache
proxy_pass — indirizzo del server originale da cui il CDN richiederà i file per la cache. Nel nostro esempio si tratta di sayt.in

Come vediamo, è tutto semplice. La complessità può sorgere solo nella configurazione del tempo di caching a causa della somiglianza delle direttive. inactive e proxy_cache_validAnalizziamole nel nostro esempio. Ecco cosa succede quando inactive=7d e proxy_cache_valid 90d:

se la richiesta non viene ripetuta per 7 giorni, i dati verranno rimossi dalla cache al termine di questo periodo.
se la richiesta viene ripetuta almeno una volta ogni 7 giorni, i dati nella cache saranno considerati obsoleti dopo 90 giorni e alla successiva richiesta Nginx li aggiornerà, prelevandoli dal server originale.

Finito di modificare nginx.conf, riavviamo la configurazione:

root@cdn:~# service nginx reload

Il nostro CDN è completamente pronto. Per $15/mese abbiamo ottenuto punti di presenza su tre continenti e 3 TB di traffico: 1 TB in ciascuna posizione.

Verifichiamo il funzionamento del CDN

Diamo un'occhiata ai ping verso il nostro CDN da diverse località geografiche. Qualsiasi servizio di ping andrà bene.

Punto di partenza
Host
IP
Tempo medio, ms

Germania, Berlino
cdn.sayt.in
199.247.18.199
9.6

Paesi Bassi, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francia, Parigi
cdn.sayt.in
199.247.18.199
16.3

Regno Unito, Londra
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

USA, Dallas
cdn.sayt.in
149.28.121.123
23.1

USA, Chicago
cdn.sayt.in
149.28.121.123
2.6

USA, New York
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Giappone, Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

I risultati sono buoni. Ora posizioniamo un'immagine di prova nella root del sito principale. test.jpg e controlliamo la velocità di caricamento tramite CDN. Detto, fatto — fatto. I contenuti vengono consegnati rapidamente.

Scriveremo un piccolo script nel caso volessimo svuotare la cache nel punto CDN.
purge.sh

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

Per rimuovere tutta la cache basta semplicemente eseguirlo; un file separato può essere pulito così:

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

Invece delle conclusioni

Infine, voglio dare alcuni utili consigli per evitare gli errori che, in passato, mi hanno creato dolore:

Per aumentare l'affidabilità del CDN, è consigliabile configurare il DNS Failover, che aiuta a cambiare rapidamente il record A in caso di guasto del server. Questo può essere fatto nel pannello di controllo dei record DNS del dominio
Siti con ampia copertura geografica richiedono senza dubbio un numero elevato di punti CDN, ma procediamo con cautela. Probabilmente, l'utente non noterà una differenza sostanziale rispetto a un CDN a pagamento, se posizionerete i server in 6-7 luoghi: Europa, Nord America (est), Nord America (ovest), Singapore, Australia, Hong Kong o Giappone.
A volte gli host non consentono di utilizzare i server affittati per scopi CDN. Pertanto, se decidete di implementare una rete di distribuzione dei contenuti come servizio, ricordate di leggere in anticipo le regole del fornitore di hosting specifico.
Esplora la mappa delle comunicazioni sottomarine, per avere un'idea di come siano collegate le continenti e tenerne conto nel costruire la rete di distribuzione dei contenuti.
Provate a controllare i ping da diverse località verso i vostri server. In questo modo potrete vedere le regioni più vicine ai punti CDN e configurare meglio il GeoDNS.
A seconda delle esigenze, potrebbe essere utile ottimizzare ulteriormente Nginx in base alle specifiche di caching e al carico del server. A questo proposito, mi sono stati molto utili articoli sul caching di Nginx — qui e sull'accelerazione delle prestazioni in caso di carichi elevati: qui e qui