Erstellen und passen Sie Ihr CDN an

Wenn Sie Ihr eigenes CDN benötigen

• Wenn Sie Geld sparen möchten und die laufenden Kosten selbst bei Verwendung kostengünstiger CDNs wie BunnyCDN mehrere hundert Dollar pro Monat betragen
• wenn wir einen permanenten Cache oder einen Cache ohne Nachbarn auf dem Server und dem Kanal erhalten möchten
• In der Region, die Sie benötigen, haben CDN-Dienste keine Präsenzpunkte
• Alle speziellen Einstellungen für die Bereitstellung von Inhalten sind erforderlich
• Wir möchten die Bereitstellung dynamischer Inhalte beschleunigen, indem wir näher an die Benutzer des Produktionsservers heranrücken
• Es besteht die Sorge, dass ein CDN-Dienst eines Drittanbieters unrechtmäßig Informationen über das Benutzerverhalten sammelt oder verwendet (Hi-to-Dienste ohne GDPR-Konformität) oder andere illegale Handlungen ausführt

Was du zum Laufen brauchst

• . ,
• geoDNS . , ,

Konfigurieren Sie geoDNS

1. Definiert die IP des Clients, der die DNS-Anforderung gesendet hat, oder die IP des rekursiven DNS-Servers, der zur Verarbeitung der Clientanforderung verwendet wird. Diese rekursiven Server sind normalerweise DNS-Anbieter.
2. Per IP kennt der Kunde sein Land oder seine Region. Hierfür werden GeoIP-Basen verwendet, von denen es heute sehr viele gibt. Es gibt einige gute kostenlose Optionen .
3. Abhängig vom Standort des Clients gibt er ihm die IP-Adresse des nächstgelegenen CDN-Servers.

• DlouDNS ab 9,95 USD / Monat , GeoDNS-Tarif, standardmäßig gibt es ein DNS-Failover
• Zilore ab 25 US-Dollar / Monat , DNS-Failover aktiviert
• Amazon Route 53 ab 35 USD / Monat für 50 Mio. Netto-Geo-Anfragen. DNS-Failover wird separat berechnet
• DNS leicht gemacht ab 125 US-Dollar / Monat , es gibt 10 DNS-Failover
• Cloudflare , Geolenkungsfunktion in Enterprise-Tarifen verfügbar

Installieren Sie SSL-Zertifikate

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

Installieren und konfigurieren Sie 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 - Cache-Größe, die den verfügbaren Speicherplatz nicht überschreitet
• inaktiv - Speicherzeit für zwischengespeicherte Daten, auf die niemand zugegriffen hat
• ssl_certificate und ssl_certificate_key - Pfade zu SSL-Zertifikat- und Schlüsseldateien
• proxy_cache_valid - Speicherzeit für zwischengespeicherte Daten
• proxy_pass - Die Adresse des ursprünglichen Servers, von dem das CDN Dateien zum Zwischenspeichern anfordert. In unserem Beispiel ist dies sayt.in

• Wird die Anforderung nicht innerhalb von 7 Tagen wiederholt, werden die Daten nach diesem Zeitraum aus dem Cache gelöscht
• Wenn die Anforderung mindestens alle 7 Tage wiederholt wird, gelten die Daten im Cache nach 90 Tagen als veraltet. Bei der nächsten Anforderung aktualisiert Nginx sie, indem sie vom ursprünglichen Server übernommen werden

root@cdn:~# service nginx reload

Überprüfen der Funktion von 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

Anstelle von Schlussfolgerungen

• Um die CDN-Fehlertoleranz zu erhöhen, wird empfohlen, DNS-Failover zu konfigurieren, um den A-Eintrag bei einem Serverausfall schnell zu ändern. Dies erfolgt in der Systemsteuerung der DNS-Einträge der Domäne
• CDN, . CDN, 6-7 : , (), (), , ,
• CDN. , , -
• , ,
• Versuchen Sie, Pings von verschiedenen Orten auf Ihren Servern zu überprüfen . So können Sie die Regionen sehen, die den CDN-Punkten am nächsten liegen, und GeoDNS korrekt konfigurieren
• Abhängig von den Aufgaben ist es nicht unangebracht, Nginx für bestimmte Caching-Anforderungen zu konfigurieren und die Belastung des Servers zu berücksichtigen. Die Artikel über den Nginx-Cache - hier und die Beschleunigung der Arbeit unter hoher Last: hier und hier haben mir sehr geholfen.