🥇Samla och ställa in ditt CDN

Content delivery networks (CDN) används av webbplatser och applikationer främst för att påskynda laddningen av statiska element. Detta sker genom att cachelagra filer på CDN-servrar som finns i olika geografiska regioner. Genom att begära data via CDN får användaren den från närmaste server.

Funktionsprincipen och funktionaliteten för alla innehållsleveransnätverk är ungefär densamma. Efter att ha mottagit en begäran om att ladda ner en fil tar CDN-servern den en gång från den ursprungliga servern och ger den till användaren, samtidigt som den cachelagras under en viss tidsperiod. Alla efterföljande förfrågningar besvaras från cachen. Alla CDN:er har alternativ för att ladda filer i förväg, rensa cacheminne, ställa in cache-utgång och mycket mer.

Det händer att det av en eller annan anledning är nödvändigt att organisera ditt eget nätverk för innehållsleverans, och då - kan instruktionerna för montering av nästa cykel vara till hjälp för oss.

Källa: Infografisk vektor skapad av pikisuperstar — www.freepik.com

När behöver du ditt eget CDN?

Låt oss titta på fall där det är vettigt att köra ditt eget CDN:

när du vill spara pengar och driftskostnader även när du använder billiga CDN som BunnyCDN uppgår till flera hundra dollar i månaden
om vi vill få en permanent cache eller en cache utan grannar på servern och kanalen
CDN-tjänster har inte närvaropunkter i den region du behöver
Eventuella särskilda inställningar för innehållsleverans krävs
vi vill påskynda leveransen av dynamiskt innehåll genom att placera produktionsservrar närmare användarna
det finns en oro för att en CDN-tjänst från tredje part kan samla in eller använda information om användarbeteende på ett felaktigt sätt (hej till tjänster som inte är GDPR-kompatibla) eller delta i andra olagliga aktiviteter

I de flesta andra fall är det lämpligare att använda befintliga färdiga lösningar.

Vad du behöver för att börja

Det är underbart om du har ett eget autonomt system (AS). Med den kan du tilldela samma IP till flera servrar och enligt dessa instruktioner på nätverksnivå, hänvisa användare till den närmaste. Det är värt att säga att även med ett /24-adressblock är det möjligt att bygga ett innehållsleveransnätverk. Vissa serverleverantörer tillåter dig att annonsera för användning i alla tillgängliga regioner.

Om du inte är den lyckliga ägaren av ett block med IP-adresser behöver du för att starta ett enkelt CDN:

domännamn eller underdomän
minst två servrar i olika regioner. Servern kan antingen vara dedikerad eller virtuell
geoDNS-verktyg. Med dess hjälp kommer en användare som kommer åt en domän att dirigeras till närmaste server

Registrera en domän och beställ servrar

Med domänregistrering är allt enkelt - vi registrerar oss i vilken zon som helst hos vilken registrar som helst. Du kan också använda en underdomän för CDN, till exempel något liknande cdn.domainname.com. Faktum är att i vårt exempel kommer vi att göra just det.

När det gäller beställningsservrar bör de hyras i de regioner och länder där din användarpublik finns. Om projektet är interkontinentalt är det bekvämt att välja värdleverantörer som erbjuder servrar över hela världen. Exempel: OVH, Leaseweb и 100Tb - för dedikerade servrar, Vultr и DigitalOcean — för virtuellt moln*.

För vårt privata CDN kommer vi att beställa 3 virtuella servrar på olika kontinenter. U Vultr på servern för $5/månad vi kommer få 25GB SSD platser och 1TB trafik. Under installationen kommer vi att välja den senaste Debian. Våra servrar:

Frankfurt, IP: 199.247.18.199

Chicago, IP: 149.28.121.123

Singapore, IP: 157.230.240.216

*Vultr och DigitalOcean utlovar $100 i kredit till användare som registrerar sig med länkarna i den här artikeln när de har lagt till en betalningsmetod. Författaren får också en liten komplimang av detta, vilket är mycket betydelsefullt för honom nu. Var förstående.

Konfigurera geoDNS

För att säkerställa att när en användare kommer åt en CDN-domän eller underdomän, han dirigeras till den önskade (närmaste) servern kommer vi att behöva en DNS-server med geoDNS-funktionen.

Principen och operationsproceduren för geoDNS är som följer:

Definierar IP-adressen för klienten som skickade DNS-begäran, eller IP-adressen för den rekursiva DNS-servern som används vid bearbetning av klientbegäran. Sådana rekursiva servrar är vanligtvis DNS-leverantörer.
Klientens IP identifierar dess land eller region. Till detta används GeoIP-databaser, som det finns väldigt många av idag. Det finns några bra gratis alternativ.
Beroende på klientens plats ger den IP-adressen till närmaste CDN-server.

DNS-server med geoDNS-funktion kan vara montera det själv, men det är bättre att använda färdiga lösningar med ett nätverk av DNS-servrar runt om i världen och anycast från lådan:

CloudDNS från $9.95/månad, GeoDNS-taxa, som standard finns det en DNS-failover
Zilore från $25/månad, DNS-failover aktiverad
Amazon väg 53 från $35/månad för rena 50 miljoner geofrågor. DNS-failover debiteras separat
DNS på ett enkelt sätt från $125/månad, det finns 10 DNS-failovers
CloudFlare, "Geo Steering"-funktionen är tillgänglig i Enterprise-tariffer

När du beställer geoDNS bör du vara uppmärksam på antalet förfrågningar som ingår i tariffen och ta hänsyn till att det faktiska antalet förfrågningar till domänen kan vara många gånger högre än förväntat. Miljontals spindlar, skannrar, spammare och andra onda andar arbetar outtröttligt.

Nästan alla DNS-tjänster inkluderar i priset en oumbärlig tjänst för att bygga en CDN - DNS Failover. Med dess hjälp kan du ställa in övervakning av driften av dina servrar och, om det inte finns några tecken på liv, automatiskt ersätta adressen till den icke-fungerande servern i DNS-svar med en backup.

För att bygga vårt CDN kommer vi att använda CloudDNS, GeoDNS-tariff.

Låt oss lägga till en ny DNS-zon i ditt personliga konto, som anger din domän. Om vi bygger ett CDN på en underdomän och huvuddomänen redan används, glöm inte att lägga till de befintliga fungerande DNS-posterna omedelbart efter att du har lagt till zonen. Nästa steg är att skapa flera A-poster för CDN-domänen/underdomänen, som var och en kommer att användas för den region vi har angett. Du kan ange kontinenter eller länder som regioner; underregioner är tillgängliga för USA och Kanada.

I vårt fall kommer CDN att höjas på en underdomän cdn.sayt.in. Genom att lägga till en zon sat.in, låt oss skapa den första A-posten för underdomänen och dirigera hela Nordamerika till servern i Chicago:

Låt oss upprepa åtgärden för andra regioner, utan att glömma att skapa en post för standardregionerna. Här är vad du får till slut:

Den sista standardposten i skärmdumpen innebär att alla ospecificerade regioner (och dessa är Europa, Afrika, satellitinternetanvändare, etc.) kommer att skickas till servern i Frankfurt.

Detta slutför den grundläggande DNS-inställningen. Allt som återstår är att gå till domänregistratorns webbplats och ersätta de nuvarande domän-NS med de som utfärdats av ClouDNS. Och medan NS:erna uppdateras kommer vi att förbereda servrarna.

Installera SSL-certifikat

Vårt CDN kommer att fungera över HTTPS, så om du redan har SSL-certifikat för en domän eller underdomän, ladda upp dem till alla servrar, till exempel till katalogen /etc/ssl/dindomän/

Om du inte har certifikat kan du få ett gratis från Let's Encrypt. Perfekt för detta ACME Shell-skript. Klienten är bekväm och enkel att konfigurera, och viktigast av allt låter den dig validera en domän/underdomän med hjälp av DNS via API:et från ClouDNS.

Vi kommer att installera acme.sh på endast en av servrarna - European 199.247.18.199, från vilken certifikat kommer att kopieras till alla andra. För att installera, gör:

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

Under installationen av skriptet kommer en CRON-uppgift att skapas för ytterligare uppdatering av certifikat utan vår medverkan.

Domänverifiering när du utfärdar ett certifikat kommer att utföras via DNS med hjälp av API:t, så i ditt personliga ClouDNS-konto i Återförsäljar-API-menyn måste du skapa en ny API-användare och ange ett lösenord för den. Vi kommer att skriva det resulterande auth-id med lösenord i en fil ~/.acme.sh/dnsapi/dns_cloudns.sh (inte att förväxla med filen dns_clouddns.sh). Här är raderna som behöver okommenteras och redigeras:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

Låt oss nu begära ett SSL-certifikat för cdn.sayt.in

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

I parametrarna, för framtiden, angav vi ett kommando för att automatiskt ladda om webbserverkonfigurationen efter varje certifikatets giltighetsuppdatering i framtiden.

Hela processen för att få ett certifikat kan ta upp till 2 minuter, avbryt det inte. Om ett domänvalideringsfel uppstår, försök att köra kommandot igen. I slutet kommer vi att se var certifikaten laddades ner:

Låt oss komma ihåg dessa sökvägar; de måste specificeras när du kopierar certifikatet till andra servrar, såväl som i webbserverinställningarna. Vi uppmärksammar inte felet med att ladda om Nginx-konfigurationer - på en fullt konfigurerad server kommer det inte att visas när certifikat uppdateras.

Allt som återstår för oss med SSL är att kopiera det mottagna certifikatet till två andra servrar och bevara sökvägen till filerna. Låt oss skapa samma kataloger på var och en av dem och göra en kopia:

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/

För att uppdatera certifikat regelbundet kommer vi att skapa en daglig CRON-uppgift på båda servrarna med kommandot:

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

I det här fallet måste åtkomst till fjärrkällservern konfigureras med nyckel, dvs. utan att ange ett lösenord. Glöm inte att göra detta.

Installera och konfigurera Nginx

För att servera statiskt innehåll kommer vi att använda Nginx konfigurerad som en caching proxyserver. Låt oss uppdatera paketlistorna och installera dem på alla tre servrarna:

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

Istället för standarden använder vi konfigurationen från spoilern nedan:
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;
    }
  }
}

I konfigurationen redigerar vi:

max_storlek — cachestorlek som inte överstiger tillgängligt diskutrymme
inaktiv — Lagringstid för cachad data som inte har nåtts
ssl_certificate и ssl_certifikatnyckel — sökvägar till SSL-certifikat och nyckelfiler
proxy_cache_valid — Lagringstid för cachade data
proxy_pass — Adressen till den ursprungliga servern från vilken CDN kommer att begära filer för cachning. I vårt exempel är detta sat.in

Som du kan se är allt enkelt. Den enda svårigheten kan uppstå med att ställa in cachingtiden på grund av likheten mellan direktiven inaktiv и proxy_cache_valid. Låt oss titta på dem med vårt exempel. Detta är vad som händer när inaktiv=7d и proxy_cache_valid 90d:

om begäran inte upprepas inom 7 dagar, kommer uppgifterna att raderas från cachen efter denna period
om begäran upprepas minst en gång var 7:e dag, kommer data i cachen att betraktas som inaktuell efter 90 dagar och med nästa begäran kommer Nginx att uppdatera den och ta den från den ursprungliga servern

Har redigerat klart nginx.conf, ladda om konfigurationen:

root@cdn:~# service nginx reload

Vårt CDN är helt klart. För $15/månad. vi fick närvaropunkter på tre kontinenter och 3 TB trafik: 1 TB på varje plats.

Kontrollerar CDN:s funktion

Låt oss titta på ping till vårt CDN från olika geografiska platser. Alla pingtjänster är lämpliga för detta.

Startpunkt
Värd
IP
Genomsnittlig tid, ms

Tyskland Berlin
cdn.sayt.in
199.247.18.199
9.6

Nederländerna, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Frankrike Paris
cdn.sayt.in
199.247.18.199
16.3

Storbritannien, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, 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

Japan Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australien, Sydney
cdn.sayt.in
157.230.240.216
95.9

Resultaten är bra. Låt oss nu placera en testbild i roten på huvudsidan test.jpg och kontrollera dess nedladdningshastighet via CDN. Det sägs - gjord. Innehållet levereras snabbt.

Låt oss skriva ett litet skript ifall vi vill rensa cachen vid CDN-punkten.
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

För att ta bort hela cachen, kör bara den; du kan rensa en separat fil så här:

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

I stället för slutsatser

Till sist vill jag ge några användbara tips för att omedelbart kliva över raken som en gång gav mig huvudvärk:

För att öka CDN-feltoleransen rekommenderas det att konfigurera DNS Failover, vilket hjälper till att snabbt ändra A-posten i händelse av ett serverfel. Detta görs i kontrollpanelen för domänens DNS-poster
Webbplatser med stor geografisk räckvidd kommer utan tvekan att kräva ett stort antal CDN-poäng, men låt oss inte vara fanatiska. Mest troligt kommer användaren inte att märka någon signifikant skillnad jämfört med ett betald CDN om du placerar servrar på 6-7 platser: Europa, Nordamerika (öst), Nordamerika (väst), Singapore, Australien, Hong Kong eller Japan
Ibland tillåter inte hostare användning av hyrda servrar för CDN-ändamål. Därför, om du plötsligt bestämmer dig för att distribuera ett innehållsleveransnätverk som en tjänst, glöm inte att läsa reglerna för din specifika värdleverantör i förväg
Utforska undervattenskommunikationskartaatt föreställa sig hur kontinenterna hänger ihop och ta hänsyn till detta när man bygger ett nätverk för innehållsleverans
Försök kolla pingar från olika ställen till dina servrar. På så sätt kan du se regionerna närmast CDN-punkter och konfigurera GeoDNS mer korrekt
Beroende på uppgifterna skulle det vara användbart att anpassa Nginx för specifika cachningskrav och med hänsyn till belastningen på servern. Artiklar om Nginx cache hjälpte mig mycket med detta - här och acceleration av arbete under tung belastning: här и här