Bildkälla: Infographic vector skapad av pikisuperstar — www.freepik.com

content Delivery Networks (CDN) används vanligtvis av webbplatser och applikationer för att påskynda laddningen av statiska element. Detta uppnås genom att cacha filer på CDN-servrar i olika regioner i världen. Efter att ha begärt data via CDN får användaren den från närmaste server.

de underliggande principerna bakom CDN och deras funktionalitet är ungefär desamma för dem alla. Efter att ha fått en begäran om en fil tar en CDN-server den en gång från origin-servern och överför den sedan till användaren och cachar en kopia av den under en tidsperiod. Ytterligare förfrågningar om data hanteras med hjälp av cachen. Alla CDN har alternativ för förladdning av filer, cache-clearing, cache-lagringstider och mycket mer.

ibland kan man av olika skäl finna sig i behov av att bygga sin egen CDN, och så presenterar vi följande guide om hur man realiserar det.

när behöver du din egen CDN?

Låt oss ta en titt på situationer där du kan behöva skapa din egen CDN:

• när du försöker spara pengar och till och med prisvärda lösningar som BunnyCDN slutar kosta dig hundratals dollar per månad
• när du vill få permanent cache eller behöver garanterad bandbredd och resurser
• befintliga CDN har inte PoPs i din målregion
• du behöver speciella innehållsleveransinställningar
• du vill snabba upp din upp leveransen av det dynamiska innehållet genom att betjäna det närmare användarna
• du är orolig för att tredje parts CDN kan olagligt samla in och använda användardata (Hej där, servrar som inte är GDPR-kompatibel) eller delta i andra olagliga aktiviteter

i de flesta andra fall är det mer lönsamt att använda befintliga färdiga lösningar.

Låt oss skapa eget CDN

för att bygga till och med ett enkelt innehållsleveransnätverk behöver du följande:

• domännamn eller en underdomän
• minst två servrar i olika regioner. Servrarna kan vara dedikerade eller virtuella
• geoDNS verktyg. Med den skickas en användare som skickar en förfrågan till domänen till närmaste server

registrera domän och beställa servrar

registrera ett domännamn är enkelt — registrera det bara i vilken domänzon du föredrar. För CDN kan du också använda en underdomän, som cdn.domainname.com. Detta är fallet för följande exempel.

när det gäller servrar bör du hyra dem i regioner och länder där din målgrupp finns. Om ditt projekt är interkontinentalt är det bekvämt att välja bland värdleverantörer som erbjuder servrar över hela världen, till exempel OVH, Leaseweb och 100TB (för dedikerade servrar) eller Vultr och DigitalOcean (för virtuella och molnservrar).

för vår privata CDN, låt oss beställa tre virtuella servrar på olika kontinenter. Vultr erbjuder oss 25 GB SSD-utrymme och 1 TB trafik för $5/månad. Under installationen väljer du den senaste Debian. Här är våra servrar:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapore, ip: 157.230.240.216

konfigurera geoDNS

för att säkerställa att klienterna riktas till rätt (närmaste) servrar när vi skickar förfrågningar till vår domän eller underdomän behöver vi en DNS-server med geoDNS-funktionalitet.

så här fungerar geoDNS:

1. det får klientens IP (om de skickade DNS-begäran) eller IP för den rekursiva DNS-servern som används för att behandla begäran. Generellt sett är sådana rekursiva servrar vanligtvis Internetleverantörernas DNSs.
2. av kundens IP identifierar det sitt land eller region. Denna operation kräver användning av GeoIP databas, som är tillgängliga i någon bristvara. Det finns även anständiga fria alternativ.
3. beroende på klientens plats returnerar geoDNS honom IP-adressen till närmaste CDN-server.

en DNS-server med geoDNS-funktionalitet är något du kan bygga själv, men det är bättre att använda färdiga lösningar som har servrar runt om i världen och ett Out-of the-box Anycast-alternativ:

• ClouDNS, från $ 9.95 / månad, GeoDNS paket, en DNS Failover tillhandahålls som standard
• Zilore, från $25/månad, inkluderar DNS Failover
• Amazon Route 53, Från $35/månad för 50 miljoner geo-förfrågningar. DNS Failover är prissatt separat
• DNS Made Easy, från $125 / månad, med 10 DNS Failovers
• Cloudflare, Geo Steering funktionalitet tillhandahålls i företagspaket

när du beställer geoDNS måste du vara uppmärksam på antalet förfrågningar som ingår i paketet och kom ihåg att det verkliga förfrågningsnumret kan överträffa dina förväntningar. Det finns miljontals sökrobotar, skannrar, spammare och andra djävul på jobbet vid varje given tidpunkt.

nästan alla DNS – tjänster inkluderar en användbar funktion för CDN-byggnad-DNS Failover. Med det kan du konfigurera Aktivitetsövervakning så att om en server går ner kommer systemet automatiskt att omdirigera klienterna till arbetsservrar istället.

för vårt CDN, låt oss använda ClouDNS och dess GeoDNS-paket.

i profilen lägger du till en ny DNS-zon och anger ditt domännamn. Om du använder underdomän och huvuddomänen används, glöm inte att lägga till befintliga DNS-poster 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 angivna regionen. Du kan ange kontinenter eller länder som regioner, och subregionalternativ är tillgängliga för USA och Kanada.

i vårt exempel kommer CDN att fungera på cdn.sayt.in underdomän. Efter att ha lagt till sayt.in zon, skapa den första en post för underdomänen och rikta alla NA klienter till Chicago server:

upprepa detta steg för de andra regionerna och glöm inte att skapa en post för standardregioner. Så här ser slutresultatet ut:

den sista standardposten betyder förfrågningar från alla ospecificerade regioner (Europa, Afrika, satellitinternetanvändare etc.) ska dirigeras till Frankfurts server.

detta avslutar den grundläggande DNS-konfigurationen. Allt som är kvar är att gå till registrar webbplats och ersätta de nuvarande namnservrar med de som tillhandahålls av ClouDNS. Medan de uppdateras ställer vi in servrarna.

installera SSL-certifikat

vår CDN kommer att fungera med HTTPS, så om du redan har SSL-certifikat för domänen eller underdomänen, ladda upp dem till alla servrar, till exempel till /etc/ssl/yourdomain/ katalog.

om du inte har några certifikat kan du få det gratis från Let ’ s Encrypt. ACME Shell script är ett bra alternativ. Den har en användarvänlig klient och, ännu viktigare, det gör det möjligt att utföra validering av domänen/underdomänen via DNS med API av ClouDNS.

vi installerar acme.sh på endast en server — den europeiska (199.247.18.199), och från den kommer certifikaten att kopieras till alla andra. För att installera det, kör följande kommando:

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

under installationen skapas en CRON-uppgift för automatisk uppdatering av certifikaten.

Domänverifiering vid utfärdandet av certifikatet kommer att utföras via DNS med API, så i ClouDNS-profilen, under Återförsäljare API, skapa en ny API-användare och ange ett lösenord för det. Ange det resulterande auth-id tillsammans med lösenordet i följande fil: ~/.acme.sh/dnsapi/dns_cloudns.sh (ej att förväxla med dns_clouddns.sh). här är de rader du behöver för att Avkommentera och redigera:

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

låt oss nu begära utfärdande av SSL-certifikatet för cdn.sayt.i

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

för framtida bruk, i parametrar, lämnade vi ett kommando för automatisk konfiguration omstart efter varje förnyelse av certifikatet.

processen att förvärva certifikatet kan ta upp till två minuter, så avbryt inte det. Om ett domänvalideringsfel uppstår, försök att köra kommandot igen. I slutändan ser vi var certifikaten hämtades.

kom ihåg dessa sökvägar, vi måste ange dem när vi kopierar certifikaten till andra servrar och vi måste ange dem i serverinställningar. Ignorera nginx config-omladdningsfelet, – det kommer inte att uppstå på en helt konfigurerad server under certifikatförnyelse.

när det gäller SSL-certifikat är allt vi lämnade att kopiera det till de två andra servrarna som sparar certifikatvägarna. Skapa identiska kataloger på varje server och kopiera sedan certifikatfiler:

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/

för att automatisera certifikatförnyelsen måste du skapa en daglig CRON-uppgift på båda servrarna. Nedan är kommandot du borde lägga till i CRON-jobb:

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

Tänk på att anslutningen till fjärranslutningsservern kräver åtkomst med nyckel utan att ange ett lösenord. Glöm inte att skapa den.

installera och konfigurera Nginx

för statisk innehållsleverans använder vi nginx, konfigurerad som en caching-proxyserver. Uppdatera listorna över paket och installera det på alla tre servrarna:

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

istället för standardkonfigurationen, använd den 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 config, låt oss Redigera:

• max_size — cachestorlek som inte överstiger det tillgängliga diskutrymmet
• inaktiv — retentionstid för obesvarad cachad data
• ssl_certificate och ssl_certificate_key — sökvägar till SSL — certifikat och nyckel
• proxy_cache_valid — retentionstid för cachad data
• proxy_pass-adress för ursprungsservern från vilken CDN kommer att begära data för caching. För vårt exempel är det sayt.in

som du kan se är det ingen raketvetenskap. Den enda svårigheten är att konfigurera retentionstiden, med tanke på likheterna mellan inaktiva och proxy_cache_valid parametrar. Låt oss ta en närmare titt. Här är vad som händer med inaktiv = 7d och proxy_cache_valid = 90d:

• om begäran inte upprepas inom 7 dagar raderas data från cachen
• om begäran upprepas även en gång under 7 dagar kommer cachen att betraktas som föråldrad efter 90 dagar och nästa begäran kommer att göra Nginx uppdatera den från ursprungsservern

med nginx.conf hanteras, ladda om konfigurationen:

root@cdn:~# service nginx reload

så, vår CDN är redo att använda! För $15 / månad fick vi PoPs på tre kontinenter och 3 TB trafik: 1 TB för varje region.

kontrollera vår CDN

Låt oss ta en titt på ping till vår CDN från olika platser. Alla ping-tjänster kommer att göra i det här fallet.

resultaten är bra. Låt oss nu placera en testbild med titeln test.jpg på huvudservern och kontrollera hur snabbt den laddas via CDN. Sagt och gjort. Laddningen är snabb.

Låt oss göra ett litet skript om vi behöver rensa cacheminnet på en CDN-punkt.

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

för att rensa all cache på servern, kör bara skriptet. Om du behöver en viss fil rensas, bara ange dess sökväg:

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

för att rensa cache överallt måste skriptet köras på alla CDN-servrar.

i stället för slutsatser

slutligen vill jag ge några användbara tips så att du kan undvika att falla i de fallgropar som jag redan rensat:

• Tänk på lönsamheten och underhållskostnaderna för din framtida CDN. I de flesta fall är det mycket effektivt och lättare att köpa en billig CDN, som sannolikt kommer att vara stabilare och vara av bättre kvalitet.
• för att förbättra CDN: s feltolerans rekommenderas att du ställer in en DNS Failover, vilket gör att du snabbt kan byta a-posten om en server bryter. Du kan göra det i DNS: s registerkontrollpanel.
• webbplatser med bred täckning kräver ett stort antal Pop, men blir inte överdrivna. Troligtvis kommer en användare inte att märka skillnaden mellan din CDN och en betald, om du har servrar på 6-7 platser (Europa, Nordamerika (öst), Nordamerika (väst), Singapore, Australien, Hong Kong eller Japan).
• ibland tillåter inte värdleverantörer att använda hyrda servrar för CDN. Så om du vill skapa en CDN-tjänst, se till att läsa upp webbhotellets villkor.
• studera ubåtskabelkartan för att förstå hur kontinenterna är anslutna och använd denna kunskap när du bygger din CDN.
• försök att pinga dina servrar från olika platser. På så sätt kan du upptäcka regionerna närmast dina Pop Och det hjälper dig att konfigurera GeoDNS.