Content Delivery Networks (CDN's) wurde brûkt yn websiden en applikaasjes foaral om it laden fan statyske eleminten te rapperjen. Dit bart troch it caching fan bestannen op CDN-tsjinners yn ferskate geografyske regio's. Troch it oanfreegjen fan gegevens fia CDN, krijt de brûker dy fan de tichtstbye server.
It prinsipe fan wurking en funksjonaliteit fan alle netwurken foar levering fan ynhâld is sawat itselde. Nei it ûntfangen fan in fersyk om in bestân te downloaden, nimt de CDN-tsjinner it ien kear fan 'e orizjinele tsjinner en jout it oan 'e brûker, tagelyk caching it foar in bepaalde perioade. Alle folgjende oanfragen wurde beantwurde út de cache. Alle CDN's hawwe opsjes om bestannen foar te laden, de cache te wiskjen, de ferfaldatum yn te stellen, en mear.
It bart dat jo om ien of oare reden jo eigen netwurk foar levering fan ynhâld moatte organisearje, en dan - lit de ynstruksjes foar it gearstallen fan 'e folgjende fyts ús helpe.
Boarne:
As jo jo eigen CDN nedich binne
Beskôgje de gefallen wêryn it útfieren fan jo eigen CDN sin makket:
- as d'r in winsk is om jild te besparjen, en rinnende kosten sels by it brûken fan goedkeape CDN's lykas bedraacht inkele hûnderten dollars yn 'e moanne
- as wy wolle krije in permaninte cache of in cache sûnder tsjinner en kanaal buorlju
- CDN-tsjinsten hawwe gjin punten fan oanwêzigens yn 'e regio dy't jo nedich binne
- eltse spesjale ynhâld levering ynstellings nedich
- wy wolle de levering fan dynamyske ynhâld fersnelle troch de produksjetsjinner tichter by brûkers te pleatsen
- d'r is in soarch dat in CDN-tsjinst fan tredden yllegaal ynformaasje oer brûkersgedrach sammelje of brûke kin (hallo tsjinsten dy't net GDPR-konforme binne) of meidwaan oan oare yllegale aktiviteiten
Yn 'e measte oare gefallen is it better om besteande klearebare oplossingen te brûken.
Wat moatte jo begjinne
It is prachtich as jo jo eigen Autonomous System (AS) hawwe. Mei it, kinne jo tawize deselde IP oan ferskate servers en op it netwurknivo, rjochtsje brûkers nei de tichtste. It is it wurdich te sizzen dat sels mei it /24-adresblok it mooglik is in netwurk foar levering fan ynhâld te bouwen. Guon serverproviders kinne jo in oankundiging meitsje foar gebrûk yn alle foar har beskikbere regio's.
As jo gjin lokkige eigner binne fan in blok fan IP-adressen, dan moatte jo in ienfâldige CDN útfiere:
- domeinnamme of subdomein
- op syn minst twa servers yn ferskate regio's. De tsjinner kin of tawijd of firtueel wêze
- geoDNS-ark. Dêrmei sil de brûker, nei't it domein adres hat, wurde rjochte nei de tichtstbye server
Registrearje in domein en bestel tsjinners
Mei domeinregistraasje is alles ienfâldich - wy registrearje yn elke sône by elke registrar. Jo kinne ek in subdomein brûke foar in CDN, bygelyks soksawat cdn.domainname.com. Eins sille wy yn ús foarbyld dat krekt dwaan.
Wat it bestellen fan servers oanbelanget, moatte se wurde ferhierd yn 'e regio's en lannen wêr't jo brûkerspublyk sit. As it projekt ynterkontinintaal is, dan is it handich om hostingproviders te kiezen dy't servers oer de hiele wrâld tagelyk oanbiede. Foarbylden: , и - foar tawijd servers, и - foar firtuele wolk *.
Foar ús privee CDN sille wy 3 firtuele servers op ferskate kontininten bestelle. By Vultr op de tsjinner foar $5/mo wy krije 25GB SSD plakken en 1TB ferkear. By it ynstallearjen, selektearje de lêste Debian. Us servers:
FrankfurtIP Foarige: 199.247.18.199
ChicagoIP Foarige: 149.28.121.123
СингапурIP Foarige: 157.230.240.216
* Vultr en DigitalOcean tasizze $ 100 kredyt oan brûkers dy't registrearje fia de keppelings yn it artikel fuortendaliks nei it tafoegjen fan in betelmetoade. De skriuwer krijt dêr ek in lyts komplimint fan, dat foar him no tige wichtich is. Wês asjebleaft begryp.
GeoDNS ynstelle
Om de brûker te rjochtsjen nei de winske (nichtste) tsjinner by tagong ta in domein of CDN-subdomein, hawwe wy in DNS-tsjinner nedich mei de geoDNS-funksje.
It prinsipe en wurking fan geoDNS is as folget:
- Spesifisearret it IP fan 'e kliïnt dy't it DNS-fersyk ferstjoerd hat, of it IP fan 'e rekursive DNS-tsjinner dy't brûkt wurdt by it ferwurkjen fan it klantfersyk. Sokke rekursive servers binne meastentiids DNS-s fan providers.
- De IP fan de klant erkent syn lân of regio. Dêrfoar wurde GeoIP-databases brûkt, dêr't der hjoed in protte fan binne. Der binne goede .
- Ofhinklik fan 'e lokaasje fan' e kliïnt, jout him it IP-adres fan 'e tichtstbye CDN-tsjinner.
DNS-tsjinner mei geoDNS-funksje kin wêze , mar it is better om te brûken klearebare oplossings mei in netwurk fan DNS tsjinners om 'e wrâld en út de doaze:
- от $9.95/mo, GeoDNS-taryf, standert is der ien DNS Failover
- от $25/mo, DNS Failover ynskeakele
- от $35/mo foar in netto 50M geo-fersiken. DNS Failover wurdt apart yn rekken brocht
- от $125/mo, der binne 10 DNS Failovers
- , "Geo Steering" funksje is beskikber yn Enterprise plannen
By it bestellen fan geoDNS, moatte jo omtinken jaan oan it oantal oanfragen opnommen yn 'e taryf en hâld yn gedachten dat it eigentlike oantal oanfragen nei it domein ferskate kearen ferwachtingen kin oertreffe. Miljoenen spinnen, scanners, spammers en oare kweade geasten wurkje ûnfoldwaande.
Hast alle DNS-tsjinsten omfetsje in ûnmisbere tsjinst foar it bouwen fan in CDN - DNS Failover. Mei har help kinne jo tafersjoch op 'e wurking fan jo servers ynstelle en, by it ûntbrekken fan tekens fan it libben, automatysk it adres fan in net-wurkjende server ferfange troch in reservekopy yn DNS-antwurden.
Om ús CDN te bouwen, sille wy brûke , GeoDNS taryf.
Litte wy in nije DNS-sône tafoegje yn jo persoanlike akkount, jo domein spesifisearje. As wy in CDN bouwe op in subdomein, en it haaddomein is al yn gebrûk, ferjit dan net direkt nei it tafoegjen fan de sône de besteande wurkjende DNS-records ta te foegjen. De folgjende stap is om ferskate A-records te meitsjen foar it CDN-domein / subdomein, elk fan dat sil tapast wurde op de regio dy't wy spesifisearre hawwe. Jo kinne kontininten as lannen opjaan as regio's, subregio's binne beskikber foar de FS en Kanada.
Yn ús gefal sil de CDN op in subdomein wurde ferhege cdn.sayt.in. Troch it tafoegjen fan in sône sayt.in, meitsje it earste A-record foar it subdomein en wiis hiele Noard-Amearika nei de server yn Chicago:
Litte wy de aksje werhelje foar oare regio's, tink om ien yngong te meitsjen foar de standertregio's. Hjir is wat der op it lêst bart:
De lêste standertyngong yn 'e skermôfbylding betsjut dat alle net spesifisearre regio's (en dit binne Europa, Afrika, satellyt ynternetbrûkers, ensfh.) wurde stjoerd nei de server yn Frankfurt.
Dit foltôget de basis DNS-opset. It bliuwt om te gean nei de webside fan 'e domeinregistrateur en de hjoeddeistige domein NS's te ferfangen mei dy útjûn troch ClouDNS. En wylst de NS's wurde bywurke, sille wy de servers tariede.
Ynstallaasje fan SSL-sertifikaten
Us CDN sil wurkje oer HTTPS, dus as jo al SSL-sertifikaten hawwe foar in domein of subdomein, upload se dan nei alle servers, bygelyks nei de map /etc/ssl/yourdomain/
As d'r gjin sertifikaten binne, kinne jo in fergese krije fan Let's Encrypt. Perfekt foar dit . De kliïnt is handich en maklik yn te stellen, en it wichtichste, it lit jo in domein / subdomein fia DNS fia de ClouDNS API validearje.
Wy sille acme.sh ynstalleare op mar ien fan 'e tsjinners - European 199.247.18.199, wêrfan sertifikaten wurde kopiearre nei alle oaren. Om te ynstallearjen, rinne:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrcTidens de ynstallaasje fan it skript sil in CRON-taak oanmakke wurde foar fierdere fernijing fan sertifikaten sûnder ús dielname.
By it útjaan fan in sertifikaat sil it domein wurde kontrolearre mei DNS mei de API, dus yn it ClouDNS persoanlike akkount yn it Reseller API-menu moatte jo in nije brûkers-API oanmeitsje en in wachtwurd foar ynstelle. De resultearjende auth-id mei in wachtwurd sil yn it bestân skreaun wurde ~/.acme.sh/dnsapi/dns_cloudns.sh (net te betiizjen mei triem dns_clouddns.sh). Hjir binne de rigels dy't net kommentearre en bewurke wurde moatte:
CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"
No sille wy in SSL-sertifikaat oanfreegje foar cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"Yn 'e opsjes, foar de takomst, hawwe wy in kommando opjûn om de konfiguraasje fan' e webserver automatysk opnij te laden nei elke fernijing fan 'e sertifikaatjildigensperioade yn' e takomst.
It hiele proses fan it krijen fan in sertifikaat kin maksimaal 2 minuten duorje, ûnderbrekke it net. As der in flater foar domeinvalidaasje optreedt, besykje it kommando nochris út te fieren. Oan 'e ein sille wy sjen wêr't de sertifikaten binne opladen:
Unthâld dizze paden, se moatte spesifisearre wurde by it kopiearjen fan it sertifikaat nei oare servers, lykas yn 'e webserverynstellingen. Wy jouwe gjin oandacht foar de flater fan it opnij laden fan Nginx-konfiguraasjes - it sil net op in folslein konfigureare server wêze by it bywurkjen fan sertifikaten.
Alles wat wy hawwe oerlitten foar SSL is om it ûntfongen sertifikaat nei twa oare servers te kopiearjen, wylst it paad nei de bestannen behâldt. Litte wy deselde mappen op elk fan har meitsje en in kopy meitsje:
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/
Om sertifikaten regelmjittich te aktualisearjen, meitsje in deistige CRON-taak op beide servers mei it kommando:
scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload
Yn dit gefal moat tagong ta de boarne tsjinner op ôfstân ynsteld wurde , d.w.s. sûnder in wachtwurd yn te fieren. Ferjit it net te dwaan.
Ynstallearje en konfigurearje Nginx
Om statyske ynhâld te tsjinjen, sille wy Nginx brûke konfigureare as in caching proxy-tsjinner. Update de pakketlisten en ynstallearje it op alle trije servers:
root@cdn:~# apt update
root@cdn:~# apt install nginxYnstee fan de standert brûke wy de konfiguraasje fan 'e spoiler hjirûnder:
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;
}
}
}Bewurkje yn de konfiguraasje:
- max_grutte - de grutte fan 'e cache, net grutter as de beskikbere skiifromte
- ynaktyf - opslachtiid fan cache gegevens dy't gjinien tagong hat
- ssl_sertifikaat и ssl_certificate_key - paden nei SSL-sertifikaat en kaaibestannen
- proxy_cache_valid - opslachtiid fan cache gegevens
- proxy_pass - adres fan 'e orizjinele tsjinner wêrfan de CDN bestannen sil oanfreegje foar caching. Yn ús foarbyld, dit sayt.in
Sa't jo sjen kinne, alles is ienfâldich. Swierrichheid kin allinich ûntstean by it ynstellen fan de cachingtiid fanwegen de oerienkomst fan 'e rjochtlinen ynaktyf и proxy_cache_valid. Litte wy se analysearje mei ús foarbyld. Hjir is wat bart wannear ynaktyf=7d и proxy_cache_valid 90d:
- as it fersyk net binnen 7 dagen wurdt werhelle, dan wurde de gegevens nei dizze perioade út 'e cache wiske
- as it fersyk op syn minst ien kear elke 7 dagen wurdt werhelle, dan wurde de gegevens yn 'e cache nei 90 dagen as ferâldere beskôge en Nginx sil it bywurkje mei it folgjende fersyk, en nimt it fan' e orizjinele tsjinner
Klear om te bewurkjen nginx.conf, laad de konfiguraasje opnij:
root@cdn:~# service nginx reloadUs CDN is klear. Foar $ 15 / mo. wy krigen punten fan oanwêzigens op trije kontininten en 3 TB ferkear: 1 TB op elke lokaasje.
Kontrolearje it wurk fan CDN
Litte wy nei de pings nei ús CDN sjen fan ferskate geografyske lokaasjes. Elke ping-tsjinst sil hjirfoar wurkje.
Startpunt
Gasthear
IP
Gem. tiid, mw
Dútslân Berlyn
cdn.sayt.in
199.247.18.199
9.6
Nederland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1
Frankryk Parys
cdn.sayt.in
199.247.18.199
16.3
Feriene Keninkryk, Londen
cdn.sayt.in
199.247.18.199
14.9
Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2
Feriene Steaten, San Francisco
cdn.sayt.in
149.28.121.123
52.7
Feriene Steaten, Dallas
cdn.sayt.in
149.28.121.123
23.1
USA, Chicago
cdn.sayt.in
149.28.121.123
2.6
Feriene Steaten, New York
cdn.sayt.in
149.28.121.123
19.8
Сингапур
cdn.sayt.in
157.230.240.216
1.7
Japan Tokio
cdn.sayt.in
157.230.240.216
74.8
Austraalje, Sydney
cdn.sayt.in
157.230.240.216
95.9
De resultaten binne goed. No sille wy in testôfbylding pleatse yn 'e root fan' e haadside test.jpg en kontrolearje syn ynlaadsnelheid fia CDN. It is sein - . Ynhâld wurdt rap levere.
Litte wy in lyts skript skriuwe foar it gefal dat wy de cache op it CDN-punt wiskje wolle.
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
Om de folsleine cache te wiskjen, útfiere it gewoan, in apart bestân kin sa skjinmakke wurde:
root@cdn:~# ./purge.sh /test.jpgYn plak fan konklúzjes
As lêste wol ik wat nuttige tips jaan om fuortendaliks oer de hark te stappen dy't myn holle doe sear makke:
- Om de fouttolerânsje fan 'e CDN te fergrutsjen, is it oan te rieden om DNS Failover te konfigurearjen, wat helpt om it A-record fluch te feroarjen yn it gefal fan in tsjinner ynbraak. Dit wurdt dien yn it kontrôlepaniel DNS-records fan it domein.
- Siden mei brede geografyske dekking hawwe sûnder mis in grut oantal CDN's nedich, mar litte wy net fanatyk wêze. Meast wierskynlik sil de brûker gjin signifikant ferskil fernimme yn ferliking mei in betelle CDN as jo servers pleatse op 6-7 lokaasjes: Jeropa, Noard-Amearika (east), Noard-Amearika (west), Singapore, Austraalje, Hong Kong of Japan
- Soms tastean hosters it gebrûk fan hierde servers foar CDN-doelen net ta. Dêrom, as jo ynienen beslute om in netwurk foar levering fan ynhâld as tsjinst yn te setten, ferjit dan net de regels fan in bepaalde hostingprovider fan tefoaren te lêzen
- Ferkenne om te fertsjintwurdigjen hoe't de kontininten binne ferbûn en nim dit yn 'e rekken by it bouwen fan in netwurk foar levering fan ynhâld
- Besykje te kontrolearjen nei jo tsjinners. Op dizze manier kinne jo de regio's it tichtst by de CDN-punten sjen en GeoDNS korrekter ynstelle
- Ofhinklik fan 'e taken sil it nuttich wêze om Nginx te fine-tunen foar spesifike caching-easken en rekken hâldend mei de lading op' e tsjinner. De artikels oer Nginx-cache holpen my in protte yn dit - en fersnelling fan wurk ûnder swiere lesten: и
Boarne: www.habr.com