Billedkilde: infografisk vektor oprettet af pikisuperstar — www.freepik.com

indholdsleveringsnetværk (CDN) bruges generelt af steder og applikationer til at fremskynde indlæsningen af statiske elementer. Dette opnås ved at cache filer på CDN-servere placeret i forskellige regioner i verden. Efter at have anmodet om data via CDN, modtager brugeren dem fra den nærmeste server.

de underliggende principper bag CDN ‘ er og deres funktionalitet er omtrent de samme for dem alle. Efter at have modtaget en anmodning om en fil, tager en CDN-server den en gang fra origin-serveren og overfører den derefter til brugeren og cacher en kopi af den i en periode. Yderligere anmodninger om data håndteres ved hjælp af cachen. Alle CDN ‘ er har muligheder for forudindlæsning af filer, cache-clearing, cache-opbevaringstider og meget mere.

nogle gange kan man af forskellige grunde finde sig i behov for at opbygge sin egen CDN, og derfor præsenterer vi følgende vejledning om, hvordan man realiserer det.

Hvornår har du brug for din egen CDN?

lad os se på situationer, hvor du muligvis skal oprette din egen CDN:

• når du prøver at spare penge og endda overkommelige løsninger som BunnyCDN ender med at koste dig hundreder af dollars om måneden
• når du ønsker at få permanent cache eller har brug for garanteret båndbredde og ressourcer
• eksisterende CDN ‘er har ikke PoPs i din målregion
• du har brug for specielle indstillinger for levering af indhold
• du vil fremskynde levering af det dynamiske indhold ved at servere det tættere på brugerne
• du er bekymret for, at tredjeparts-CDN’ er muligvis ulovligt indsamler og bruger brugerdata (Hej der, servere, der ikke er GDPR-kompatibel) eller deltage i andre ulovlige aktiviteter

i de fleste andre tilfælde er det mere levedygtigt at bruge eksisterende færdige løsninger.

lad os oprette eget CDN

for at opbygge selv et simpelt indholdsleveringsnetværk har du brug for følgende:

• domænenavn eller et underdomæne
• mindst to servere i forskellige regioner. Serverne kan være dedikeret eller virtuel
• geoDNS værktøj. Med det sendes en bruger, der sender en anmodning til domænet, til nærmeste server

registrering af Domæne og bestilling af servere

registrering af et domænenavn er nemt — bare registrer det i ethvert domæneområde, du foretrækker. For CDN kan du også bruge et underdomæne, som cdn.domainname.com. dette er tilfældet for følgende eksempel.

når det kommer til servere, skal du leje dem i regioner og lande, hvor din målgruppe er placeret. Hvis dit projekt er interkontinentalt, er det praktisk at vælge blandt hostingudbydere, der tilbyder servere over hele verden, f.eks.

til vores private CDN, lad os bestille tre virtuelle servere på forskellige kontinenter. Vultr tilbyder os 25 GB SSD-plads og 1 TB trafik for $5/måned. Under installationen skal du vælge den nyeste Debian. Her er vores servere:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapore, ip: 157.230.240.216

konfiguration af geoDNS

for at sikre, at klienterne dirigeres til de rigtige (nærmeste) servere ved afsendelse af anmodninger til vores domæne eller underdomæne, har vi brug for en DNS-server med geoDNS-funktionalitet.

sådan fungerer geoDNS:

1. det får klientens IP (hvis de sendte DNS-anmodningen) eller IP ‘ en for den rekursive DNS-server, der bruges til behandling af anmodningen. Generelt er sådanne rekursive servere normalt DNSs for internetudbydere.
2. ved klientens IP identificerer den deres land eller region. Denne operation kræver brug af GeoIP database, som er tilgængelige på ingen mangelvare. Der er endda anstændige gratis muligheder.
3. afhængigt af klientens placering returnerer geoDNS ham IP-adressen på den nærmeste CDN-server.

en DNS-server med geoDNS-funktionalitet er noget, du selv kan bygge, men det er bedre at bruge færdige løsninger, der har servere rundt om i verden og en ud-af-boksen Anycast-mulighed:

• ClouDNS, fra $ 9.95 / måned, geodns-pakke, en DNS Failover leveres som standard
• fra $25/måned, inkluderer DNS Failover
• rute 53, Fra $35/måned for 50 millioner geo-anmodninger. DNS Failover er prissat separat
• DNS gjort nemt, fra $125/måned, med 10 DNS Failovers
• Cloudflare, Geo Styringsfunktionalitet leveres i Enterprise pakker

når du bestiller geoDNS skal du være opmærksom på antallet af anmodninger, der er inkluderet i pakken og huske på, at den reelle anmodninger nummer i høj grad kan overstige dine forventninger. Der er millioner af internetsøgere, scannere, spammere og anden djævel på arbejde til enhver tid.

næsten alle DNS – tjenester inkluderer en nyttig funktion til CDN-bygning-DNS Failover. Med det kan du konfigurere Aktivitetsovervågning, så hvis en server går ned, omdirigerer systemet automatisk klienterne til fungerende servere i stedet.

lad os bruge ClouDNS og dens GeoDNS-pakke til vores CDN.

i profil skal du tilføje et nyt DNS-område og angive dit domænenavn. Hvis du bruger underdomæne, og hoveddomænet er i brug, skal du ikke glemme at tilføje de eksisterende DNS-poster umiddelbart efter tilføjelsen af området. Det næste trin er at oprette flere a-poster til CDN-domænet/underdomænet, som hver vil blive brugt til det angivne område. Du kan udpege kontinenter eller lande som regioner, og subregion muligheder er tilgængelige for USA og Canada.

i vores eksempel vil CDN fungere på cdn.sayt.in underdomæne. Efter at have tilføjet sayt.in første A-post for underdomænet og dirigere alle Na-klienter til Chicago-serveren:

gentag dette trin for de andre regioner, og glem ikke at oprette en post for standardregioner. Sådan ser slutresultatet ud:

den sidste standardpost betyder anmodninger fra alle uspecificerede regioner (Europa, Afrika, satellit-internetbrugere osv.) skal sendes til Frankfurt-serveren.

dette afslutter den grundlæggende DNS-konfiguration. Alt, hvad der er tilbage, er at gå til registrator hjemmeside og erstatte de nuværende navneservere med dem, der leveres af ClouDNS. Mens de opdateres, indstiller vi serverne.

installation af SSL-certifikater

vores CDN fungerer ved hjælp af HTTPS, så hvis du allerede har SSL-certifikater til domænet eller underdomænet, skal du uploade dem til alle serverne, for eksempel til /etc/ssl/yourdomain/ directory.

hvis du ikke har nogen certifikater, kan du få det gratis fra Let ‘ s Encrypt. ACME Shell script er en god mulighed. Det har en brugervenlig klient, og endnu vigtigere giver det mulighed for at udføre validering af domænet/underdomænet via DNS ved hjælp af API af ClouDNS.

vi installerer acme.sh på kun en server — Den Europæiske (199.247.18.199), og fra den kopieres certifikaterne til alle de andre. For at installere det skal du køre følgende kommando:

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

under installationen oprettes en CRON-opgave til automatisk opdatering af certifikaterne.

Domænebekræftelse ved udstedelse af certifikatet udføres via DNS ved hjælp af API, så i ClouDNS-profilen under forhandler API skal du oprette en ny API-bruger og angive en adgangskode til den. Indtast det resulterende auth-id sammen med adgangskoden i følgende fil: ~/.acme.sh/dnsapi/dns_cloudns.sh (ikke at forveksle med dns_clouddns.sh). her er de linjer, du har brug for at fjerne og redigere:

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

lad os nu anmode om udstedelse af SSL-certifikatet for cdn.sayt.i

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

til fremtidig brug, i parametre, forlod vi en kommando til automatisk konfiguration genstart efter hver fornyelse af certifikatet.

processen med at erhverve certifikatet kan tage op til to minutter, så afbryd det ikke. Hvis der opstår en domænevalideringsfejl, kan du prøve at køre kommandoen igen. I sidste ende vil vi se, hvor certifikaterne blev hentet.

husk disse stier, vi bliver nødt til at specificere dem, når vi kopierer certifikaterne til andre servere, og vi bliver nødt til at specificere dem i serverindstillinger. – Det vil ikke forekomme på en fuldt konfigureret server under certifikatfornyelse.

hvad angår SSL-certifikat, er alt, hvad vi har tilbage at gøre, at kopiere det til de to andre servere, der gemmer certifikatstierne. Opret identiske mapper på hver server, og kopier derefter 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/

for at automatisere certifikatfornyelsen skal du oprette en daglig CRON-opgave på begge servere. Nedenfor er den kommando, du skal tilføje til CRON jobs:

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

Husk, at forbindelsen til den eksterne origin-server kræver en adgang med nøgle uden at indtaste en adgangskode. Glem ikke at oprette det.

installation og konfiguration af Ngink

til levering af statisk indhold bruger vi Ngink, konfigureret som en cache-fuldmagts server. Opdater listerne over pakker og installer den på alle de tre servere:

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

i stedet for standardkonfigurationen skal du bruge nedenstående:

ngink.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, lad os redigere:

• maks.størrelse — cache — størrelse, der ikke overstiger den tilgængelige diskplads
• inaktiv retentionstid for ikke — anmodede cachelagrede data
• ssl_certificate and ssl_certificate_key — stier til SSL — certifikat og nøgle
• fuldmægtig_cache_valid-retentionstid for cachelagrede data
• fuldmagts_pass-adresse på oprindelsesserveren, hvorfra CDN vil anmode om data til caching. For vores eksempel er det sayt.in

som du kan se, er det ingen raketvidenskab. Det eneste problem er at konfigurere retentionstiden i betragtning af lighederne mellem inaktive og fuldmægtige parametre. Lad os se nærmere på. Her er hvad der sker med inaktiv=7d og fuldmægtig_cache_valid=90d:

• hvis anmodningen ikke gentages inden for 7 dage, slettes dataene fra cachen
• hvis anmodningen gentages en gang i løbet af 7 dage, vil cachen blive betragtet som forældet efter 90 dage, og den næste anmodning vil få Ngink til at opdatere den fra origin server

med ngink.conf håndteres, genindlæs konfigurationen:

root@cdn:~# service nginx reload

så vores CDN er klar til brug! For $15 / måned fik vi PoPs på tre kontinenter og 3 TB trafik: 1 TB for hver region.

kontrol af vores CDN

lad os se på ping til vores CDN fra forskellige steder. Eventuelle ping-tjenester vil gøre i dette tilfælde.

resultaterne er gode. Lad os nu placere et testbillede med titlen test.jpg på hovedserveren og kontroller, hvor hurtigt den indlæses via CDN. Sagt og gjort. Indlæsningen er hurtig.

lad os lave et lille script, hvis vi skal rydde cache på et 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

for at rydde al cache på serveren skal du blot køre scriptet. Hvis du har brug for en fil renset, skal du bare angive dens sti:

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

for at rense cache overalt skal scriptet køres på alle CDN-servere.

i stedet for konklusioner

endelig vil jeg gerne give nogle nyttige tips, så du kan undgå at falde i de faldgruber, jeg allerede har ryddet:

• overvej levedygtighed og vedligeholdelsesomkostninger for din fremtidige CDN. I de fleste tilfælde er det meget effektivt og lettere at købe en billig CDN, som sandsynligvis vil være mere stabil og være af bedre kvalitet.
• for at forbedre CDNs fejltolerance anbefales det, at du opretter en DNS Failover, som giver dig mulighed for hurtigt at skifte a-post i tilfælde af, at en server går i stykker. Du kan gøre det i DNS ‘ s records Kontrolpanel.
• hjemmesider med bred dækning kræver et stort antal PoPs, men bliver ikke overdrevne. Mest sandsynligt vil en bruger ikke bemærke forskellen mellem din CDN og en betalt, hvis du har servere på 6-7 steder (Europa, Nordamerika (øst), Nordamerika (Vest), Singapore, Australien, Hong Kong eller Japan).
• nogle gange tillader hostingudbydere ikke at bruge lejede servere til CDN ‘ er. Så hvis du ønsker at oprette en CDN-tjeneste, skal du sørge for at læse op på hostingudbyderens vilkår og betingelser.
• Undersøg ubådskabelkortet for at forstå, hvordan kontinenterne er forbundet, og brug denne viden, når du bygger din CDN.
• prøv at pinge dine servere fra forskellige steder. På denne måde kan du få øje på de regioner, der er tættest på dine PoPs, og det hjælper dig med at konfigurere GeoDNS.