🥇Bygger och konfigurerar vårt eget CDN

Innehållsleveransnätverk (CDN) används på webbplatser och i applikationer främst för att snabba upp laddningen av statiska element. Detta sker genom att filer cachas på CDN-servrar som ligger i olika geografiska regioner. När användaren begär data via CDN får de det från närmaste server.

Principen för hur innehållsleveransnätverk fungerar är i stort sett densamma. När en CDN-server får en begäran om att ladda en fil hämtar den en gång filen från den ursprungliga servern och levererar den till användaren, samtidigt som den cachar den på angiven tid. För alla efterföljande begärningar levereras svaret från cachen. Alla CDN har alternativ för förhandsladdning av filer, rensning av cache, inställningar för lagringstid och mycket mer.

Ibland krävs det av olika skäl att organisera ett eget innehållsleveransnätverk, och då — må instruktionen för att bygga ännu en cykel vara till hjälp.

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

När behöver man ett eget CDN

Låt oss se på situationer där det är meningsfullt att starta ett eget CDN:

när man vill spara pengar, och de nuvarande kostnaderna även vid användning av billiga CDN som BunnyCDN uppgår till flera hundra dollar per månad
om vi vill få en permanent cache eller cache utan grannar på servern och kanalen
i den region du behöver har CDN-tjänster inga punkter för närvaro
speciella inställningar för leverans av innehåll krävs
vi vill snabba upp leveransen av dynamiskt innehåll genom att placera produktionsservrar närmare användarna
det finns oro för att en extern CDN-tjänst kan olagligt samla in eller använda information om användarnas beteende (hej tjänster utan GDPR-efterlevnad) eller utföra andra olagliga handlingar

I de flesta andra fall är det mer rationellt att använda befintliga lösningar.

Vad behövs för att starta

Det är fantastiskt om du har ett eget autonomt system (AS). Med detta kan du tilldela samma IP-adress till flera servrar och enligt denna instruktion på nätverksnivå styra användare till den närmaste. Det är värt att nämna att även med ett adressblock /24 finns det möjlighet att bygga ett innehållsleveransnätverk. Vissa serverleverantörer tillåter att göra en tillkännagivelse för användning i alla tillgängliga regioner.

Om du inte är en lycklig ägare av en IP-adressblock, behöver du följande för att starta ett enkelt CDN:

ett domännamn eller subdomän
minst två servrar i olika regioner. Servern kan vara antingen dedikerad eller virtuell
ett geoDNS-verktyg. Med hjälp av detta kommer användaren, genom att anropa domänen, att dirigeras till den närmaste servern

Vi registrerar domänen och beställer servrar

Att registrera domänen är enkelt — registrera den i valfri zon hos vilken registrar som helst. För CDN kan du också använda en subdomän, som något i stil med cdn.dittdomännamn.com. Egentligen kommer vi att göra just detta i vårt exempel.

När det gäller att beställa servrar — de bör hyras i de regioner och länder där din användarpublik finns. Om projektet är internationellt är det удобно att välja hosting-leverantörer som erbjuder servrar över hela världen. Exempel: OVH, Leaseweb och 100Tb – för dedikerade servrar, Vultr och DigitalOcean – för virtuella moln*.

För vårt privata CDN beställer vi 3 virtuella servrar på olika kontinenter. Vi har Vultr en server för $5/månad och får 25GB SSD plats och 1TB trafik. Vid installationen väljer vi 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 erbjuder $100 kredit till användare som registrerar sig via länkarna i artikeln, direkt efter att de lagt till en betalningsmetod. Författaren får också en liten belöning för detta, vilket just nu är mycket betydelsefullt för honom. Vänligen ha överseende med detta.

Vi konfigurerar geoDNS

För att användaren ska dirigeras till rätt (närmaste) server när de anropar domänen eller subdomänen CDN, behöver vi en DNS-server med geoDNS-funktion.

Principen och arbetsordningen för geoDNS är följande:

Bestämmer IP-adressen för klienten som skickade DNS-förfrågan, eller IP-adressen för den rekursiva DNS-server som används vid hantering av klientens förfrågan. Sådana rekursiva servrar är vanligtvis DNS från leverantörer.
Genom klientens IP-adress tar den reda på vilket land eller region denne kommer ifrån. För detta används GeoIP-databaser, av vilka det idag finns många. Det finns några bra gratisalternativ.
Beroende på klientens plats returnerar den IP-adressen till den närmaste CDN-servern.

En DNS-server med geoDNS-funktion kan byggas på egen hand, men det är bättre att använda färdiga lösningar med ett nätverk av DNS-servrar över hela världen och Anycast Out-of-the-box:

CloudDNS från $9.95/månad, GeoDNS-tariff, som har en DNS Failover som standard
Zilore från $25/månad, inkluderat DNS Failover
Amazon Route 53 från $35/månad för 50M rena geo-förfrågningar. DNS Failover debiteras separat
DNS Made Easy från $125/månad, har 10 DNS Failover
Cloudflare, funktionen "Geo Steering" är tillgänglig i Enterprise-planer

Vid beställning av geoDNS bör du vara uppmärksam på antalet förfrågningar som ingår i planen och tänka på att det faktiska antalet förfrågningar till domänen kan överstiga förväntningarna med flera gånger. Miljontals spindlar, skannrar, spammare och annan oönskad trafik arbetar oförtrutet.

Nästan alla DNS-tjänster inkluderar den ovärderliga tjänsten DNS Failover för att bygga CDN. Med den kan du ställa in övervakning av dina servrar och automatiskt ersätta adressen till den icke fungerande servern med en reservadress i DNS-svaren vid avsaknad av livstecken.

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

Vi lägger till en ny DNS-zon i vårt användarkonto och anger vår domän. Om vi bygger CDN på en subdomän och den huvudsakliga domänen redan används, glöm inte att lägga till de befintliga arbets-DNS-posterna direkt efter att zonen har lagts till. Nästa steg är att skapa flera A-poster för CDN-domänen/subdomänen, var och en som ska gälla för den region vi har angivit. Som regioner kan vi ange kontinenter eller länder, för USA och Kanada är subregioner tillgängliga.

I vårt fall kommer CDN att byggas på subdomänen cdn.sayt.in. Efter att ha lagt till zonen sayt.in, skapar vi den första A-posten för subdomänen och dirigerar hela Nordamerika till servern i Chicago:

Vi upprepar åtgärden för andra regioner, och glömmer inte att skapa en post för standardregioner. Så här blir det slutgiltiga resultatet:

Den sista standardposten på skärmdumpen innebär att alla icke angivna regioner (som Europa, Afrika, användare av satellitinternet osv.) kommer att dirigeras till servern i Frankfurt.

Så här avslutas den grundläggande DNS-inställningen. Det är dags att gå till domänregistrarens webbplats och ersätta de nuvarande NS-posterna för domänen med de som ClouDNS tillhandahöll. Under tiden NS-posterna uppdateras förbereder vi servrarna.

Installation av SSL-certifikat

Vårt CDN kommer att fungera över HTTPS, så om du redan har SSL-certifikat för domänen eller subdomänen, ladda upp dem till alla servrar, till exempel till katalogen /etc/ssl/вашдомен/

Om det inte finns några certifikat kan du få ett gratis från Let’s Encrypt. För detta passar ACME Shell script. Klienten är bekväm och enkel att konfigurera, och viktigast av allt – den tillåter validering av domän/subdomän via DNS genom ClouDNS API.

Vi installerar acme.sh bara på en av servrarna – den europeiska 199.247.18.199, från vilken certifikaten kommer att kopieras till alla andra. För installationen kör vi:

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

Under installationen av skriptet kommer ett CRON-jobb att skapas för framtida uppdateringar av certifikaten utan vår medverkan.

Domainverifiering vid utfärdande av certifikat kommer att ske via DNS med användning av API, så i ClouDNSs personliga konto behöver du skapa en ny API-användare i menyn Reseller API och ange ett lösenord för den. Den erhållna auth-id med lösenordet kommer att anges i filen ~/acme.sh/dnsapi/dns_cloudns.sh (förväxla inte med filen dns_clouddns.sh). Här är raderna som behöver avkommenteras och redigeras:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Nu begär vi SSL-certifikatet 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, har vi angett kommandot för automatisk omstart av webbserverns konfiguration efter varje förnyelse av certifikatets giltighet.

Hela processen för att få certifikatet kan ta upp till 2 minuter, avbryt den inte. Om det uppstår ett valideringsfel, försök att köra kommandot igen. I slutet ser vi vart certifikaten har laddats upp:

Vi kommer att minnas dessa vägar, de måste anges vid kopiering av certifikatet till andra servrar samt i webbserverns inställningar. Vi bryr oss inte om fel vid omstart av Nginx-konfigar, – på en helt konfigurerad server kommer det inte att finnas något.

Allt som återstår med SSL är att kopiera det erhållna certifikatet till två andra servrar med bibehållande av filvägarna. Vi skapar samma kataloger på var och en av dem och gör 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 certifikatförnyelser ska ske regelbundet skapar vi ett dagligt CRON-jobb 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

Därmed måste åtkomsten till den avlägsna källservern vara konfigurerad med nyckel, det vill säga utan att ange lösenord. Glöm inte att göra det.

Installation och konfiguration av Nginx

För att leverera statiskt innehåll kommer vi att använda Nginx, konfigurerad i cache-proxy-läge. Låt oss uppdatera paketlistorna och installera det på alla tre servrar:

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

Istället för standard-konfigurationen använder vi den nedanstående konfigurationen:
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_size — storleken på cachen, som inte får överskrida det tillgängliga utrymmet på disken
inactive — tiden som cachelagrade data hålls när ingen har begärt dem
ssl_certificate och ssl_certificate_key — sökvägar till SSL-certifikat- och nyckelfiler
proxy_cache_valid — tiden som cachelagrade data hålls
proxy_pass — adressen till den ursprungliga servern som CDN kommer att begära filer för caching från. I vårt exempel är detta sayt.in

Som vi ser, är allt ganska enkelt. Svårigheten kan bara uppstå vid inställning av cachens tidsperiod på grund av likheten mellan direktiven inactive och proxy_cache_valid. Låt oss gå igenom dem med vårt exempel. Så här fungerar det vid inactive=7d och proxy_cache_valid 90d:

om förfrågan inte upprepas inom 7 dagar, kommer data att raderas från cachen efter denna period
om förfrågan upprepas åtminstone en gång var 7:e dag, kommer data i cachen att betraktas som föråldrade efter 90 dagar och vid nästa förfrågan kommer Nginx att uppdatera dem genom att hämta från den ursprungliga servern

När vi har avslutat redigeringen nginx.conf, laddar vi om konfigurationen:

root@cdn:~# service nginx reload

Vår CDN är nu helt klar. För $15/mån. har vi fått närvaropunkter på tre kontinenter och 3 TB trafik: 1 TB i varje plats.

Vi testar CDN:ns funktionalitet

Låt oss titta på pingarna till vårt CDN från olika geografiska lägen. Några ping-tjänster fungerar bra 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

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Resultaten är bra. Nu lägger vi en testbild i roten av huvudwebbplatsen. test.jpg och kontrollerar hastigheten för dess laddning via CDN. Som sagt, — det som gjordes. Innehållet levereras snabbt.

Vi kommer att skriva ett litet skript om vi vill rensa cachen på 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 räcker det att köra det, enskilda filer kan rensas så här:

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

Istället för slutsatser

Till sist vill jag ge några användbara tips för att undvika de fallgropar som tidigare har gett mig huvudvärk:

För att öka redundansen i CDN rekommenderas det att konfigurera DNS Failover, vilket hjälper att snabbt ändra A-posten om servern går sönder. Detta görs i kontrollpanelen för domänens DNS-poster.
Webbplatser med stor geografisk täckning kräver utan tvekan många CDN-punkter, men låt oss vara rimliga. Användaren kommer troligen inte att märka någon betydande skillnad jämfört med en betald CDN om du placerar servrar på 6-7 platser: Europa, Nordamerika (östra), Nordamerika (västra), Singapore, Australien, Hongkong eller Japan.
Ibland tillåter inte webbhotell att använda hyrda servrar för CDN-ändamål. Så om du av någon anledning beslutar dig för att driftsätta ett content delivery network som en tjänst, glöm inte att läsa reglerna för den specifika webbhotellleverantören i förväg.
Studera kartan över undervattenskommunikationer, för att förstå hur kontinenterna hänger ihop och ta hänsyn till detta när du bygger ett nätverk för content delivery.
Försök att kontrollera pingarna från olika platser till dina servrar. På så sätt kan man se de närmaste regionerna till CDN-punkterna och optimera GeoDNS.
Beroende på uppgifterna kan det vara bra att justera Nginx för de specifika cachekraven och med hänsyn till serverbelastningen. Jag fick mycket hjälp av artiklar om Nginx-cache — här och hastighetsökning under hög belastning: här och här