Créez et personnalisez votre CDN

Lorsque vous avez besoin de votre propre CDN

• lorsque vous voulez économiser de l'argent et que les coûts de fonctionnement même en utilisant des CDN peu coûteux comme BunnyCDN sont de plusieurs centaines de dollars par mois
• si nous voulons obtenir un cache permanent ou un cache sans voisins sur le serveur et le canal
• dans la région dont vous avez besoin, les services CDN n'ont pas de points de présence
• tout paramètre de diffusion de contenu spécial requis
• nous voulons accélérer la livraison de contenu dynamique en nous rapprochant des utilisateurs du serveur de production
• il existe une crainte qu'un service CDN tiers puisse collecter ou utiliser illégalement des informations sur le comportement des utilisateurs (accès aux services sans GDPR) ou se livrer à d'autres actions illégales

Ce dont vous avez besoin pour courir

• . ,
• geoDNS . , ,

Configurer geoDNS

1. Définit l'IP du client qui a envoyé la demande DNS ou l'IP du serveur DNS récursif utilisé pour traiter la demande client. Ces serveurs récursifs sont généralement des fournisseurs DNS.
2. Par IP, le client connaît son pays ou sa région. Pour cela, des bases GeoIP sont utilisées, dont il existe aujourd'hui un grand nombre. Il existe de bonnes options gratuites .
3. En fonction de l'emplacement du client, il lui donne l'adresse IP du serveur CDN le plus proche.

• louDNS à partir de 9,95 $ / mois , tarif GeoDNS, par défaut il y a un basculement DNS
• Zilore à partir de 25 $ / mois , basculement DNS activé
• Amazon Route 53 à partir de 35 $ / mois pour 50 millions de requêtes géographiques nettes. Le basculement DNS est facturé séparément
• DNS Made Easy à partir de 125 $ / mois , il y a 10 basculements DNS
• Cloudflare , fonction de pilotage géographique disponible dans les tarifs d'entreprise

Installer des certificats SSL

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

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

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

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/

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

Installer et configurer Nginx

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

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;
    }
  }
}

• max_size - la taille du cache ne dépasse pas l'espace disque disponible
• inactif - durée de stockage des données en cache auxquelles personne n'a accédé
• ssl_certificate et ssl_certificate_key - chemins d'accès aux certificats SSL et aux fichiers de clés
• proxy_cache_valid - durée de stockage des données mises en cache
• proxy_pass - l'adresse du serveur d'origine à partir de laquelle le CDN demandera des fichiers pour la mise en cache. Dans notre exemple, c'est sayt.in

• si la demande n'est pas répétée dans les 7 jours, les données seront supprimées du cache après cette période
• si la demande est répétée au moins une fois tous les 7 jours, les données du cache seront considérées comme obsolètes après 90 jours et à la prochaine demande, Nginx la mettra à jour en la récupérant du serveur d'origine

root@cdn:~# service nginx reload

Vérification du fonctionnement de CDN

#!/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

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

Au lieu de conclusions

• Pour augmenter la tolérance aux pannes CDN, il est recommandé de configurer le basculement DNS, ce qui permet de modifier rapidement un enregistrement A en cas de défaillance du serveur. Cela se fait dans le panneau de contrôle des enregistrements DNS du domaine
• CDN, . CDN, 6-7 : , (), (), , ,
• CDN. , , -
• , ,
• Essayez de vérifier les pings de différents endroits vers vos serveurs. Ainsi, vous pouvez voir les régions les plus proches des points CDN et configurer correctement GeoDNS
• Selon les tâches, il n'est pas déplacé de configurer Nginx pour des exigences de mise en cache spécifiques et en tenant compte de la charge sur le serveur. Les articles sur le cache Nginx - ici et l'accélération du travail sous de lourdes charges: ici et ici m'ont beaucoup aidé.