bildekilde: Infographic vector opprettet av pikisuperstar — www.freepik.com

Innholdsleveringsnettverk (CDN) brukes vanligvis av nettsteder og applikasjoner for å øke hastigheten på lasting av statiske elementer. Dette oppnås ved å bufre filer på CDN-servere som ligger i ulike deler av verden. Etter å ha bedt om data via CDN, mottar brukeren den fra nærmeste server.

de underliggende prinsippene bak Cdn-Er og deres funksjonalitet er omtrent det samme for Dem alle. ETTER å ha mottatt en forespørsel om en fil, TAR EN CDN-server den en gang fra origin-serveren og overfører den til brukeren og bufrer en kopi av den i en periode. Ytterligere forespørsler om dataene håndteres ved hjelp av hurtigbufferen. Alle CDNs har muligheter for forhåndsinnlasting av filer, cache clearing, cache oppbevaring ganger og mye mer.

noen ganger, av ulike grunner, kan man finne seg selv i behov av å bygge sin EGEN CDN, og så presenterer vi følgende veiledning om hvordan å realisere det.

når trenger du DIN EGEN CDN?

La oss ta en titt på situasjoner der du kanskje trenger å lage DIN EGEN CDN:

• når du prøver å spare penger og til og med rimelige løsninger som BunnyCDN ender opp med å koste deg hundrevis av dollar per måned
• når du vil få permanent cache eller trenger garantert båndbredde og ressurser
• eksisterende Cdn-Er har Ikke PoPs i målområdet
• du krever spesielle innholdsleveringsinnstillinger
• du vil øke hastigheten det nærmere brukerne
• du er bekymret tredjeparts Cdn kan ulovlig samle inn og bruke brukerdata (hei der, servere som ikke er GDPR) eller delta i andre ulovlige aktiviteter

i de fleste andre tilfeller er det mer levedyktig å bruke eksisterende ferdige løsninger.

La oss lage egen CDN

for å bygge enda et enkelt innholdsleveringsnettverk trenger du følgende:

• domenenavn eller et underdomene
• minst to servere i forskjellige regioner. Serverne kan være dedikert eller virtuelle
• geoDNS verktøy. Med det vil en bruker som sender en forespørsel til domenet, bli sendt til nærmeste server

Registrere domene og bestille servere

Registrere et domenenavn er enkelt-bare registrer det i en hvilken som helst domenesone du foretrekker — FOR CDN kan du også bruke et underdomene, som cdn.domainname.com. Dette er tilfellet for følgende eksempel.

når det gjelder servere, bør du leie dem i regioner og land der målgruppen din befinner seg. Hvis prosjektet ditt er interkontinentalt, er det praktisk å velge blant hostingleverandører som tilbyr servere over hele verden, FOR EKSEMPEL OVH, Leaseweb og 100tb (for dedikerte servere), eller Vultr og DigitalOcean (for virtuelle og sky servere).

for vår private CDN, la oss bestille tre virtuelle servere på forskjellige kontinenter. Vultr tilbyr oss 25GB SSD plass OG 1 TB trafikk for $ 5 / måned. Under installasjonen velger Du den nyeste Debian. Her er våre servere:

• Frankfurt, tyskland: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapore, singapore: 157.230.240.216

Konfigurere geoDNS

for å sikre at klientene er rettet til de riktige (nærmeste) serverne ved å sende forespørsler til vårt domene eller underdomene, trenger vi EN DNS-server med geoDNS-funksjonalitet.

slik fungerer geoDNS:

1. det får klientens IP (hvis DE sendte DNS-forespørselen) ELLER IP-en til den rekursive DNS-serveren som brukes til å behandle forespørselen. Generelt sett er slike rekursive servere Vanligvis DNSs av Internettleverandørene.
2. ved klientens IP identifiserer den deres land eller region. Denne operasjonen krever Bruk Av GeoIP database, som er tilgjengelig på ingen mangelvare. Det er enda anstendig gratis alternativer.
3. avhengig av klientens plassering, returnerer geoDNS HAM IP-adressen til nærmeste CDN-server.

EN DNS-server med geoDNS-funksjonalitet er noe du kan bygge selv, men det er bedre å bruke ferdige løsninger som har servere rundt om i verden og et out-of the-box Anycast-alternativ:

• ClouDNS, fra $ 9.95 / måned, GeoDNS pakke, en DNS Failover leveres som standard
• Zilore, fra $25/måned, inkluderer DNS Failover
• Amazon Route 53, fra $35 / måned for 50 millioner geo-forespørsler. DNS Failover er priset separat
• DNS Gjort Enkelt, fra $125 / måned, med 10 DNS Failovers
• Cloudflare, Geo Steering funksjonalitet er gitt I Enterprise packages

når du bestiller geoDNS, må du være oppmerksom på antall forespørsler som er inkludert i pakken, og husk at det virkelige forespørselsnummeret kan i stor grad overgå forventningene dine. Det er millioner av web crawlere, skannere, spammere og andre djevelskap på jobb til enhver tid.

Nesten ALLE DNS-tjenester inkluderer en nyttig funksjon FOR CDN-bygning-DNS Failover. Med det kan du konfigurere aktivitetsovervåking slik at hvis en server går ned, vil systemet automatisk omdirigere klientene til fungerende servere i stedet.

for VÅR CDN, la oss bruke ClouDNS og Dens GeoDNS-pakke.

i profil legger du til EN NY DNS-sone og angir domenenavnet ditt. Hvis du bruker underdomene, og hoveddomenet er i bruk, må du ikke glemme å legge til DE eksisterende DNS-postene umiddelbart etter at du har lagt til sonen. Det neste trinnet er å opprette Flere a-poster FOR CDN-domenet / underdomenet, som hver vil bli brukt for den angitte regionen. Du kan angi kontinenter eller land som regioner, og underregionsalternativer er tilgjengelige FOR USA og Canada.

I vårt eksempel vil CDN operere på cdn.sayt.in underdomene. Etter å ha lagt til sayt.in sone, opprett den forste a registrere for underdomenet og direkte ALLE NA-klienter til Chicago-serveren:

Gjenta dette trinnet for de andre områdene, Og ikke glem å opprette en post for standardområder. Her er hva sluttresultatet ser ut som:

den siste standard posten betyr forespørsler fra alle uspesifiserte regioner(Europa, Afrika, satellitt internett-brukere, etc.) skal rettes til Frankfurt-serveren.

dette avslutter den grunnleggende DNS-konfigurasjonen. Alt som er igjen er å gå til registrarwebsiden og erstatte de nåværende navneserverne med De som Tilbys av ClouDNS. Mens de blir oppdatert, setter vi serverne.

Installere SSL-sertifikater

VÅR CDN vil operere MED HTTPS,så hvis du allerede har SSL-sertifikater for domenet eller underdomenet, last dem opp til alle serverne, for eksempel til/etc/ssl/ yourdomain / katalogen.

hvis du ikke har noen sertifikater, kan du få det gratis Fra Let ‘ S Encrypt. ACME Shell script er et flott alternativ. Den har en brukervennlig klient, og enda viktigere, det gjør det mulig å utføre validering av domenet/underdomenet via DNS ved HJELP AV API av ClouDNS.

vi installerer acme.sh På bare En server — Den Europeiske (199.247.18.199), og fra det, vil sertifikatene bli kopiert til alle de andre. For å installere det, kjør følgende kommando:

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

UNDER installasjonen opprettes EN CRON-oppgave for automatisk oppdatering av sertifikatene.

domenebekreftelse ved utstedelse av sertifikatet vil bli utført VIA DNS ved HJELP AV API, så i ClouDNS-profilen, under Reseller API, opprett en ny API-bruker og angi et passord for det. Skriv inn den resulterende auth-id sammen med passordet i følgende fil:~/. acme.sh/dnsapi/dns_cloudns.sh (må ikke forveksles med dns_clouddns.sh). Her er linjene du trenger for å uncomment og redigere:

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

la Oss nå be om utstedelse AV SSL-sertifikatet for cdn.sayt.i

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

for fremtidig bruk, i parametere, forlot vi en kommando for automatisk konfigurering omstart etter hver fornyelse av sertifikatet.

prosessen med å anskaffe sertifikatet kan ta opptil to minutter, så ikke avbryt det. Hvis det oppstår en domenevalideringsfeil, kan du prøve å kjøre kommandoen på nytt. Til slutt ser vi hvor sertifikatene ble lastet ned.

Husk disse stiene, vi må spesifisere dem når du kopierer sertifikatene til andre servere, og vi må spesifisere dem i serverinnstillinger. Ignorer Nginx config reloading feil — – det vil ikke oppstå på en fullt konfigurert server under sertifikatfornyelse.

NÅR DET GJELDER SSL-sertifikat, er alt vi igjen å gjøre, å kopiere det til de to andre serverne som lagrer sertifikatbanene. Opprett identiske kataloger på hver server og kopier deretter sertifikatfiler:

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 å automatisere sertifikatfornyelsen må du opprette en DAGLIG CRON-oppgave på begge serverne. Nedenfor er kommandoen du bør legge 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 tilkoblingen til den eksterne origin-serveren krever tilgang med nøkkel uten å skrive inn et passord. Ikke glem å lage den.

Installere Og konfigurere Nginx

For statisk innholdslevering bruker Vi Nginx, konfigurert som en caching proxy-server. Oppdater lister over pakker og installer den på alle de tre serverne:

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

i Stedet for standardkonfigurasjonen, bruk den nedenfor:

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, la oss redigere:

• max_size — cachestørrelse som ikke overskrider den tilgjengelige diskplassen
• inaktiv — oppbevaringstid for ikke forespurte bufrede data
• ssl_certificate_key — baner TIL SSL — sertifikat og NØKKEL
• proxy_cache_valid — oppbevaringstid for bufrede data
• proxy_pass-adressen til origin-serveren som cdn vil be om data for caching. For vårt eksempel er det sayt.in

Som du kan se, er det ingen rakettvitenskap. Det eneste problemet er å konfigurere retensjonstiden, gitt likhetene mellom inaktive og proxy_cache_valid parametere. La oss ta en nærmere titt. Her er hva som skjer med inactive=7d og proxy_cache_valid=90d:

• hvis forespørselen ikke gjentas innen 7 dager, slettes dataene fra cache
• hvis forespørselen gjentas enda en gang i løpet av 7 dager, vil cachen bli vurdert utdatert etter 90 dager, og neste forespørsel vil gjøre Nginx oppdatere den fra origin server

med nginx.conf håndteres, laste konfigurasjonen:

root@cdn:~# service nginx reload

SÅ, VÅR CDN er klar til bruk! For $15 / måned fikk Vi PoPs på tre kontinenter OG 3tb trafikk: 1TB for hver region.

Sjekker VÅR CDN

La oss ta en titt på ping til VÅR CDN fra forskjellige steder. Eventuelle ping-tjenester vil gjøre i dette tilfellet.

resultatene er gode. La oss nå plassere et testbilde med tittelen test.jpg på hovedserveren og sjekk hvor fort den laster via CDN. Sagt og gjort. Lasten er rask.

La oss lage et lite skript hvis vi trenger å fjerne 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 å fjerne all cache på serveren, bare kjøre skriptet. Hvis du trenger en fil renset, bare angi banen:

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

å rense cache overalt skriptet må kjøres på ALLE CDN-servere.

i stedet for konklusjoner

Til Slutt vil Jeg gjerne gi noen nyttige tips slik at du kan unngå å falle i fallgruvene jeg allerede ryddet:

• Vurder levedyktigheten og vedlikeholdskostnadene for din fremtidige CDN. I de fleste tilfeller er det mye effektivt og enklere å kjøpe en billig CDN, som mest sannsynlig vil være mer stabil og være av bedre kvalitet.
• for å forbedre CDNS feiltoleranse anbefales det at du konfigurerer EN DNS-Failover, noe som gjør at du raskt kan bytte A-posten i tilfelle en server bryter. Du kan gjøre det i DNS ‘ s poster kontrollpanel.
• Nettsteder med bred dekning krever et stort antall PoPs, men blir ikke overivrig. Sannsynligvis vil en bruker ikke merke forskjellen mellom CDN og en betalt, hvis du har servere på 6-7 steder (Europa, Nord-Amerika (Øst), Nord-Amerika (Vest), Singapore, Australia, Hong Kong eller Japan).
• noen ganger tillater ikke vertsleverandører å bruke leide servere For Cdn-Er. Så, hvis du ønsker å opprette EN CDN-tjeneste, sørg for å lese opp på vertsleverandørens vilkår og betingelser.
• Studer sjøkabelkartet for å forstå hvordan kontinentene er koblet sammen og bruk denne kunnskapen når DU bygger CDN.
• prøv å pinge serverne dine fra forskjellige steder. På denne måten kan du oppdage områdene nærmest PoPs, og det vil hjelpe Deg med Å konfigurere GeoDNS.