Afbeeldingsbron: Infographic vector created by pikisuperstar- www.freepik.com

Content Delivery Networks (CDN) worden in het algemeen gebruikt door sites en toepassingen om het laden van statische elementen te versnellen. Dit wordt bereikt door bestanden te cachen op CDN-servers in verschillende regio ‘ s van de wereld. Na het opvragen van gegevens via CDN, ontvangt de gebruiker deze van de dichtstbijzijnde server.

de onderliggende principes achter CDN ’s en hun functionaliteit zijn ongeveer hetzelfde voor alle CDN’ s. Nadat een aanvraag voor een bestand is ontvangen, neemt een CDN-server het een keer van de origin-server en stuurt het vervolgens naar de gebruiker en cacht een kopie ervan voor een periode van tijd. Verdere verzoeken voor de gegevens worden behandeld met behulp van de cache. Alle CDN ‘ s hebben opties voor het vooraf laden van bestanden, cache clearing, cache retentie tijden en nog veel meer.

Soms zou men om verschillende redenen behoefte kunnen hebben aan het bouwen van zijn eigen CDN, en daarom presenteren wij de volgende gids over hoe dit te realiseren.

wanneer hebt u uw eigen CDN nodig?

laten we eens kijken naar situaties waarin u mogelijk uw eigen CDN moet maken:

• als je probeert om geld te besparen en betaalbare oplossingen zoals BunnyCDN uiteindelijk kost je honderden dollars per maand
• wanneer u wilt krijgen een permanente cache of behoefte aan een gegarandeerde bandbreedte en bronnen
• bestaande Cdn ‘ s niet Opduikt in je doelgebied
• u speciale content delivery instellingen
• je wilt de snelheid van de levering van de dynamische inhoud van de door het serveren van het dichter bij de gebruikers
• je bent betrokken van derden Cdn ‘ s kan illegaal verzamelen en gebruiken van gegevens van de gebruiker (hey daar, servers die niet GDPR-compliant) of andere illegale activiteiten

in de meeste andere gevallen is het rendabeler om bestaande kant-en-klare oplossingen te gebruiken.

laten we een eigen CDN

maken om zelfs een eenvoudig content delivery netwerk te bouwen heb je het volgende nodig:

• domeinnaam of subdomein
• minimaal twee servers in verschillende regio ‘ s. De servers kunnen dedicated of virtueel
• geoDNS tool zijn. Hiermee wordt een gebruiker die een verzoek naar het domein verzendt doorverwezen naar de dichtstbijzijnde server

domein registreren en servers bestellen

een domeinnaam registreren is eenvoudig — registreer het gewoon in elke domein zone die u verkiest. Voor CDN kun je ook een subdomein gebruiken, zoals cdn.domainname.com. Dit is het geval voor het volgende voorbeeld.

als het gaat om servers, moet u die huren in regio ‘ s en landen waar uw doelgroep zich bevindt. Als uw project intercontinentaal is, is het handig om te kiezen uit hostingproviders die servers over de hele wereld aanbieden, zoals OVH, Leaseweb en 100Tb (voor dedicated servers), of Vultr en DigitalOcean (voor virtuele en cloud servers).

voor onze private CDN, laten we drie virtuele servers op verschillende continenten bestellen. Vultr biedt US 25GB SSD ruimte en 1TB verkeer voor $5 / maand. Selecteer tijdens de installatie de nieuwste Debian. Hier zijn onze servers:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapore, ip: 157.230.240.216

Als u geoDNS

wilt configureren, hebben we een DNS-server met geoDNS-functionaliteit nodig om ervoor te zorgen dat de clients naar de juiste (dichtstbijzijnde) servers worden geleid bij het verzenden van verzoeken naar ons domein of subdomein.

zo werkt geoDNS:

1. het krijgt het IP van de client (als ze de DNS-aanvraag verzonden) of het IP van de recursieve DNS-server die wordt gebruikt voor het verwerken van de aanvraag. Over het algemeen zijn dergelijke recursieve servers meestal de DNSs van de internetproviders.
2. aan de hand van het IP-adres van de cliënt identificeert het land of de regio van de cliënt. Deze operatie vereist het gebruik van GeoIP-database, die beschikbaar zijn in no short supply. Er zijn zelfs fatsoenlijke gratis opties.
3. afhankelijk van de locatie van de client geeft geoDNS hem het IP-adres van de dichtstbijzijnde CDN-server terug.

een DNS-server met geoDNS-functionaliteit kunt u zelf bouwen, maar het is beter om kant-en-klare oplossingen te gebruiken met servers over de hele wereld en een out – of-the-box Anycast-optie:

• ClouDNS, van $ 9.95 / month, GeoDNS package, one DNS Failover is provided by default
• Zilore, from $ 25 / month, includes DNS Failover
• Amazon Route 53, from $ 35 / month for 50 million geo-requests. DNS Failover is apart geprijsd
• DNS Made Easy, vanaf $ 125 / maand, met 10 DNS Failovers
• Cloudflare, Geo Steering functionaliteit wordt geleverd in Enterprise packages

bij het bestellen van geoDNS moet u aandacht besteden aan het aantal aanvragen in het pakket en houd er rekening mee dat het echte requests nummer aanzienlijk hoger kan zijn dan uw verwachtingen. Er zijn miljoenen webcrawlers, scanners, spammers en andere devilry aan het werk op een bepaald moment.

bijna alle DNS-services bevatten een handige functie voor CDN building – DNS Failover. Hiermee kunt u activity monitoring zo configureren dat als een server uitvalt, het systeem de clients automatisch omgeleid naar werkende servers.

voor onze CDN gebruiken we ClouDNS en het GeoDNS pakket.

voeg in een profiel een nieuwe DNS-zone toe en geef uw domeinnaam op. Als u subdomein gebruikt en het hoofddomein in gebruik is, vergeet dan niet om de bestaande DNS-records onmiddellijk na het toevoegen van de zone toe te voegen. De volgende stap is om meerdere a-records te maken voor het CDN-domein/subdomein, die elk voor het opgegeven gebied zullen worden gebruikt. U kunt continenten of landen als regio ‘ s aanwijzen, en subregio-opties zijn beschikbaar voor de VS en Canada.

in ons voorbeeld zal de CDN werken op de cdn.sayt.in subdomein. Na toevoeging van de sayt.in zone, maak de Eerste a record voor het subdomein en direct alle na clients naar de Chicago server:

herhaal deze stap voor de andere regio ’s en vergeet niet één record voor standaardregio’ s aan te maken. Zo ziet het eindresultaat eruit:

te maken de laatste standaardrecord betekent verzoeken van alle niet-gespecificeerde regio ‘ s (Europa, Afrika, satellietinternetgebruikers, enz.) worden doorgestuurd naar de server van Frankfurt.

hiermee is de basis DNS-configuratie beëindigd. Het enige wat overblijft is om naar de registrar website te gaan en de huidige nameservers te vervangen door de nameservers die door ClouDNS worden geleverd. Terwijl ze worden bijgewerkt, stellen we de servers in.

SSL-certificaten installeren

onze CDN werkt met HTTPS, dus als u al SSL-certificaten hebt voor het domein of het subdomein, upload ze dan naar alle servers, bijvoorbeeld naar de map /etc/ssl/uwdomein/.

Als u geen certificaten hebt, kunt u het gratis verkrijgen bij Let ‘ s Encrypt. ACME Shell script is een geweldige optie. Het heeft een gebruiksvriendelijke client en, nog belangrijker, het maakt het mogelijk om validatie van het domein/subdomein uit te voeren via DNS met behulp van API door ClouDNS.

we zullen installeren acme.sh op slechts één server — de Europese (199.247.18.199), en van daaruit zullen de certificaten worden gekopieerd naar alle andere. Om het te installeren, voer je het volgende commando uit:

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

tijdens de installatie wordt een cron-taak gemaakt voor het automatisch bijwerken van de certificaten.

domeinverificatie bij uitgifte van het certificaat zal worden uitgevoerd via DNS met behulp van API, dus in het ClouDNS-profiel, onder Reseller API, maak een nieuwe API-gebruiker en geef een wachtwoord voor het. Voer de resulterende auth-id samen met het wachtwoord in het volgende bestand: ~/.acme.sh/dnsapi/dns_cloudns.sh (niet te verwarren met dns_clouddns.sh). hier zijn de regels die u moet verwijderen en bewerken:

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

laten we nu de uitgifte van het SSL-certificaat voor cdn aanvragen.sayt.in

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

voor toekomstig gebruik, in parameters, lieten we een commando voor automatische configuratie reboot na elke vernieuwing van het certificaat.

het verkrijgen van het certificaat kan tot twee minuten duren, onderbreek het dus niet. In het geval er een domeinvalidatiefout optreedt, probeer het commando opnieuw uit te voeren. Uiteindelijk zullen we zien waar de certificaten zijn gedownload.

uitgeven Onthoud deze paden, we moeten ze specificeren bij het kopiëren van de certificaten naar andere servers en we moeten ze specificeren in serverinstellingen. Negeer de Nginx config herlaadfout — – het zal niet optreden op een volledig geconfigureerde server tijdens het vernieuwen van het certificaat.

wat SSL certificaat betreft, alles wat we nog hoeven te doen is het kopiëren naar de twee andere servers die de certificaatpaden opslaan. Maak identieke mappen op elke server en kopieer vervolgens certificaatbestanden:

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/

als u de certificaatvernieuwing wilt automatiseren, moet u een dagelijkse cron-taak op beide servers maken. Hieronder is het commando dat u moet toevoegen aan cron-taken:

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

Houd er rekening mee dat verbinding met de remote origin server een toegang per sleutel vereist zonder een wachtwoord in te voeren. Vergeet niet om het te maken.

installeren en configureren van Nginx

voor het leveren van statische inhoud zullen we Nginx gebruiken, geconfigureerd als een caching proxy server. Update de lijsten met pakketten en installeer het op alle drie de servers:

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

gebruik in plaats van de standaardconfiguratie de onderstaande configuratie:

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; } }}

in config, laten we bewerken:

• max_size — cachegrootte niet groter dan de beschikbare schijfruimte
• inactieve — retentietijd voor niet — opgevraagde gegevens in de cache
• ssl_certificaat en ssl_certificate_key — paden naar SSL — certificaat en-sleutel
• proxy_cache_valid-retentietijd voor gegevens in de cache
• proxy_pass-adres van de oorspronkelijke server van waaruit het CDN zal gegevens opvragen voor caching. Voor ons voorbeeld, het is sayt.in

zoals je kunt zien, is het geen raketwetenschap. De enige moeilijkheid is het configureren van de retentietijd, gezien de overeenkomsten tussen inactieve en proxy_cache_valid parameters. Laten we eens beter kijken. Dit is wat er gebeurt met inactive = 7d en proxy_cache_valid = 90d:

• als het verzoek niet binnen 7 dagen wordt herhaald, worden de gegevens verwijderd uit de cache
• als het verzoek ook maar één keer wordt herhaald gedurende 7 dagen, wordt de cache na 90 dagen als verouderd beschouwd en zal Nginx het bijwerken vanaf de origin-server

met nginx.conf afgehandeld, de configuratie herladen:

root@cdn:~# service nginx reload

dus, onze CDN is klaar voor gebruik! Voor $15 / maand kregen we Pop ‘ s op drie continenten en 3TB van het verkeer: 1TB voor elke regio.

controle van onze CDN

laten we eens kijken naar ping naar onze CDN vanaf verschillende locaties. Elke ping-dienst zal doen in dit geval.

de resultaten zijn goed. Laten we nu een test afbeelding met de titel test plaatsen.jpg op de hoofdserver en controleer hoe snel het laadt via CDN. Gezegd en gedaan. Het laden gaat snel.

laten we een klein script maken voor het geval we de cache op een CDN punt moeten wissen.

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

om alle cache op de server te wissen, voer je gewoon het script uit. Als u een bestand wilt verwijderen, geeft u gewoon het pad op:

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

om cache overal te wissen moet het script op alle CDN servers draaien.

in plaats van conclusies

tot slot zou ik enkele nuttige tips willen geven om te voorkomen dat u in de valkuilen terechtkomt die ik al heb opgelost.:

• overweeg de levensvatbaarheid en onderhoudskosten van uw toekomstige CDN. In de meeste gevallen is het veel efficiënt en gemakkelijker om een goedkope CDN te kopen, die waarschijnlijk stabieler en van betere kwaliteit zal zijn.
• om de fouttolerantie van de CDN te verbeteren, wordt aanbevolen een DNS-Failover in te stellen, waarmee u snel de A-record kunt schakelen in het geval dat een server breekt. U kunt dit doen in het DNS records Configuratiescherm.
• Websites met een brede dekking vereisen een groot aantal Pop ‘ s, maar worden niet overijverig. Hoogstwaarschijnlijk zal een gebruiker het verschil tussen uw CDN en een betaalde niet merken, als u servers hebt op 6-7 locaties (Europa, Noord-Amerika (Oost), Noord-Amerika (West), Singapore, Australië, Hong Kong of Japan).
• soms staan hostingproviders het gebruik van gehuurde servers voor CDN ‘ s niet toe. Dus, als u op zoek bent naar een CDN-dienst te creëren, zorg ervoor dat u lezen op de voorwaarden van de hosting provider.
• Bestudeer de kaart van de onderzeese kabel om te begrijpen hoe de continenten zijn verbonden en gebruik deze kennis bij het bouwen van uw CDN.
• probeer uw servers te pingen vanaf verschillende locaties. Op deze manier kunt u de regio ’s die het dichtst bij uw POP’ s en het zal u helpen bij het configureren van GeoDNS.