🥇Je CDN verzamelen en instellen

Content Delivery Networks (CDN's) worden door websites en applicaties voornamelijk gebruikt om het laden van statische elementen te versnellen. Dit gebeurt door bestanden in de cache op CDN-servers in verschillende geografische regio's te plaatsen. Door gegevens op te vragen via CDN ontvangt de gebruiker deze van de dichtstbijzijnde server.

Het werkingsprincipe en de functionaliteit van alle inhoudleveringsnetwerken zijn ongeveer hetzelfde. Nadat de CDN-server een verzoek heeft ontvangen om een bestand te downloaden, haalt het dit eenmalig van de oorspronkelijke server en geeft het aan de gebruiker, terwijl het tegelijkertijd voor een bepaalde tijd in de cache wordt opgeslagen. Alle volgende verzoeken worden vanuit de cache beantwoord. Alle CDN's hebben opties voor het vooraf laden van bestanden, het wissen van de cache, het instellen van de vervaldatum van de cache en nog veel meer.

Het komt voor dat het om de een of andere reden nodig is om uw eigen netwerk voor het leveren van inhoud te organiseren, en dan kunnen de instructies voor het monteren van de volgende fiets ons helpen.

Bron: Infographicvector gemaakt door pikisuperstar — www.freepik.com

Wanneer heb je een eigen CDN nodig?

Laten we eens kijken naar gevallen waarin het runnen van uw eigen CDN zinvol is:

wanneer u geld en exploitatiekosten wilt besparen, zelfs als u goedkope CDN's gebruikt, zoals Konijntje CDN bedragen enkele honderden dollars per maand
als we een permanente cache of een cache zonder buren op de server en het kanaal willen krijgen
CDN-diensten hebben geen aanwezigheidspunten in de regio die u nodig heeft
Er zijn speciale instellingen voor de levering van inhoud vereist
we willen de levering van dynamische inhoud versnellen door productieservers dichter bij de gebruikers te plaatsen
er bestaat bezorgdheid dat een CDN-service van derden op ongepaste wijze informatie over gebruikersgedrag verzamelt of gebruikt (hallo aan niet-GDPR-compatibele services) of zich bezighoudt met andere illegale activiteiten

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

Wat je nodig hebt om te beginnen

Het is geweldig als je een eigen autonoom systeem (AS) hebt. Hiermee kunt u hetzelfde IP-adres aan meerdere servers toewijzen volgens deze instructie op netwerkniveau, leid gebruikers naar de dichtstbijzijnde. Het is de moeite waard om te zeggen dat het zelfs met een /24-adresblok mogelijk is een netwerk voor het leveren van inhoud op te bouwen. Bij sommige serverproviders kunt u adverteren voor gebruik in alle beschikbare regio's.

Als u niet de gelukkige eigenaar bent van een blok IP-adressen, heeft u voor het starten van een eenvoudige CDN het volgende nodig:

domeinnaam of subdomein
minimaal twee servers in verschillende regio's. De server kan dedicated of virtueel zijn
geoDNS-tool. Met zijn hulp wordt een gebruiker die toegang krijgt tot een domein doorgestuurd naar de dichtstbijzijnde server

Registreer een domein en bestel servers

Met domeinregistratie is alles eenvoudig: we registreren ons in elke zone bij elke registrar. Je kunt voor het CDN ook een subdomein gebruiken, bijvoorbeeld zoiets als cdn.domeinnaam.com. In ons voorbeeld zullen we precies dat doen.

Wat betreft het bestellen van servers: deze moeten worden gehuurd in de regio's en landen waar uw gebruikerspubliek zich bevindt. Als het project intercontinentaal is, is het handig om hostingproviders te kiezen die servers over de hele wereld aanbieden. Voorbeelden: OVH, web huren и 100Tb - voor speciale servers, Vultr и DigitalOcean — voor virtuele cloud*.

Voor ons private CDN bestellen we 3 virtuele servers op verschillende continenten. U Vultr op de server voor $ 5/maand we zullen krijgen 25GB SSD plaatsen en 1TB verkeerTijdens de installatie selecteren we de nieuwste versie. DebianOnze servers:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapore, ip: 157.230.240.216

*Vultr en DigitalOcean beloven $ 100 aan tegoeden aan gebruikers die zich aanmelden via de links in dit artikel zodra ze een betaalmethode hebben toegevoegd. De auteur krijgt hier ook een klein compliment van, wat voor hem nu heel veelbetekenend is. Wees alstublieft begripvol.

GeoDNS instellen

Om ervoor te zorgen dat wanneer een gebruiker toegang krijgt tot een CDN-domein of subdomein, hij naar de gewenste (dichtstbijzijnde) server wordt geleid, hebben we een DNS-server nodig met de geoDNS-functie.

Het principe en de werkwijze van geoDNS zijn als volgt:

Definieert het IP-adres van de client die het DNS-verzoek heeft verzonden, of het IP-adres van de recursieve DNS-server die wordt gebruikt bij het verwerken van het clientverzoek. Dergelijke recursieve servers zijn meestal DNS-providers.
Het IP-adres van de klant identificeert het land of de regio ervan. Hiervoor worden GeoIP-databases gebruikt, waarvan er tegenwoordig heel veel zijn. Er zijn enkele goede gratis opties.
Afhankelijk van de locatie van de client krijgt deze het IP-adres van de dichtstbijzijnde CDN-server.

DNS-server met geoDNS-functie kan zijn zet hem zelf in elkaar, maar het is beter om kant-en-klare oplossingen te gebruiken met een netwerk van DNS-servers over de hele wereld anycast uit de doos:

CloudDNS van $ 9.95/maand, GeoDNS-tarief, standaard is er één DNS-failover
Zilore van $ 25/maand, DNS-failover ingeschakeld
Amazon Route 53 van $ 35/maand voor pure 50M geo-query's. DNS-failover wordt afzonderlijk in rekening gebracht
DNS gemakkelijk gemaakt van $ 125/maand, zijn er 10 DNS-failovers
Cloudflare, is de functie “Geo Steering” beschikbaar in Enterprise-tarieven

Let bij het bestellen van geoDNS op het aantal aanvragen dat in het tarief is inbegrepen en houd er rekening mee dat het daadwerkelijke aantal aanvragen naar het domein vele malen hoger kan zijn dan verwacht. Miljoenen spinnen, scanners, spammers en andere boze geesten werken onvermoeibaar.

Bijna alle DNS-diensten bevatten in de prijs een onmisbare service voor het bouwen van een CDN - DNS Failover. Met zijn hulp kunt u de werking van uw servers monitoren en, als er geen tekenen van leven zijn, automatisch het adres van de niet-werkende server in DNS-reacties vervangen door een back-upadres.

Om ons CDN te bouwen zullen we gebruiken CloudDNS, GeoDNS-tarief.

Laten we een nieuwe DNS-zone toevoegen aan uw persoonlijke account, waarin uw domein wordt aangegeven. Als we een CDN op een subdomein bouwen en het hoofddomein al in gebruik is, vergeet dan niet onmiddellijk na het toevoegen van de zone de bestaande werkende DNS-records toe te voegen. De volgende stap is het maken van verschillende A-records voor het CDN-domein/subdomein, die elk worden gebruikt voor de regio die we hebben opgegeven. U kunt continenten of landen opgeven, aangezien er regio's beschikbaar zijn voor de VS en Canada.

In ons geval wordt de CDN op een subdomein geplaatst cdn.sayt.in. Door een zone toe te voegen zeg.in, laten we het eerste A-record voor het subdomein maken en heel Noord-Amerika naar de server in Chicago leiden:

Laten we de actie voor andere regio's herhalen en niet vergeten één item voor de standaardregio's te maken. Dit is wat je uiteindelijk krijgt:

De laatste standaardinvoer in de schermafbeelding betekent dat alle niet-gespecificeerde regio's (en dit zijn Europa, Afrika, satellietinternetgebruikers, enz.) naar de server in Frankfurt worden verzonden.

Hiermee is de basis-DNS-installatie voltooid. Het enige dat overblijft is om naar de website van de domeinregistreerder te gaan en de huidige domein-NS's te vervangen door die uitgegeven door ClouDNS. En terwijl de NS’en worden bijgewerkt, bereiden wij de servers voor.

SSL-certificaten installeren

Ons CDN werkt via HTTPS, dus als u al SSL-certificaten heeft voor een domein of subdomein, upload deze dan naar alle servers, bijvoorbeeld naar de directory /etc/ssl/uwdomein/

Als u geen certificaten heeft, kunt u er gratis een krijgen van Let's Encrypt. Perfect hiervoor ACME Shell-script. De client is handig en eenvoudig te configureren, en het belangrijkste is dat u hiermee een domein/subdomein kunt valideren met behulp van DNS via de API van ClouDNS.

We zullen acme.sh op slechts één van de servers installeren - de Europese 199.247.18.199, waarvan de certificaten naar alle andere worden gekopieerd. Ga als volgt te werk om te installeren:

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

Tijdens de installatie van het script wordt er een CRON-taak aangemaakt voor het verder bijwerken van certificaten zonder onze tussenkomst.

Domeinverificatie bij uitgifte van een certificaat gebeurt via DNS met behulp van de API, dus in uw persoonlijke ClouDNS-account in het Reseller API-menu moet u een nieuwe API-gebruiker aanmaken en hiervoor een wachtwoord instellen. We zullen de resulterende auth-id met wachtwoord in een bestand schrijven ~/.acme.sh/dnsapi/dns_cloudns.sh (niet te verwarren met het bestand dns_clouddns.sh). Dit zijn de regels die moeten worden verwijderd en bewerkt:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

Laten we nu een SSL-certificaat aanvragen cdn.sayt.in

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

In de parameters hebben we voor de toekomst een opdracht gespecificeerd om de webserverconfiguratie automatisch opnieuw te laden na elke update van de geldigheid van het certificaat in de toekomst.

Het hele proces voor het verkrijgen van een certificaat kan maximaal 2 minuten duren. Onderbreek dit niet. Als er een domeinvalidatiefout optreedt, probeert u de opdracht opnieuw uit te voeren. Aan het einde zullen we zien waar de certificaten zijn gedownload:

Laten we deze paden onthouden; ze moeten worden opgegeven bij het kopiëren van het certificaat naar andere servers, evenals in de webserverinstellingen. We letten niet op de fout bij het opnieuw laden van Nginx-configuraties - op een volledig geconfigureerde server zal deze niet verschijnen bij het updaten van certificaten.

Het enige dat ons bij SSL rest, is het ontvangen certificaat naar twee andere servers te kopiëren, waarbij het pad naar de bestanden behouden blijft. Laten we op elk ervan dezelfde mappen maken en een kopie maken:

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/

Om certificaten regelmatig bij te werken, zullen we op beide servers een dagelijkse CRON-taak aanmaken met de opdracht:

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

In dit geval moet de toegang tot de externe bronserver worden geconfigureerd per sleutel, d.w.z. zonder een wachtwoord in te voeren. Vergeet dit niet te doen.

Nginx installeren en configureren

Om statische inhoud aan te bieden, zullen we Nginx gebruiken die is geconfigureerd als een caching-proxyserver. Laten we de pakketlijsten bijwerken en op alle drie de servers installeren:

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

In plaats van de standaard gebruiken we de configuratie uit de onderstaande spoiler:
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 de configuratie bewerken we:

max_grootte — cachegrootte die de beschikbare schijfruimte niet overschrijdt
inactief — opslagtijd voor gegevens in de cache waartoe nog geen toegang is verkregen
ssl_certificate и ssl_certificate_key — paden naar SSL-certificaat en sleutelbestanden
proxy_cache_valid — opslagtijd van gegevens in de cache
proxy_pass — het adres van de oorspronkelijke server waarvan het CDN bestanden zal opvragen voor caching. In ons voorbeeld is dit het geval zeg.in

Zoals je kunt zien, is alles eenvoudig. De enige moeilijkheid kan zich voordoen bij het instellen van de cachingtijd vanwege de gelijkenis van de richtlijnen inactief и proxy_cache_valid. Laten we ze bekijken aan de hand van ons voorbeeld. Dit is wat er wanneer gebeurt inactief=7d и proxy_cache_valid 90d:

Als het verzoek niet binnen 7 dagen wordt herhaald, worden de gegevens na deze periode uit de cache verwijderd
als het verzoek minstens één keer per zeven dagen wordt herhaald, worden de gegevens in de cache na 7 dagen als verouderd beschouwd en bij het volgende verzoek zal Nginx deze bijwerken, waarbij ze deze van de oorspronkelijke server halen

Ben klaar met bewerken nginx.conf, laad de configuratie opnieuw:

root@cdn:~# service nginx reload

Ons CDN is helemaal klaar. Voor $ 15/maand. we ontvingen aanwezigheidspunten op drie continenten en 3 TB aan verkeer: 1 TB op elke locatie.

Controle van de werking van het CDN

Laten we eens kijken naar pings naar ons CDN vanaf verschillende geografische locaties. Eventuele pingdiensten zijn hiervoor geschikt.

Startpunt
Gastheer
IP
Gem. tijd, mevrouw

Duitsland Berlijn
cdn.sayt.in
199.247.18.199
9.6

Nederland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Frankrijk Parijs
cdn.sayt.in
199.247.18.199
16.3

Groot-Brittannië, Londen
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

VS, San Francisco
cdn.sayt.in
149.28.121.123
52.7

VS, Dallas
cdn.sayt.in
149.28.121.123
23.1

VS, Chicago
cdn.sayt.in
149.28.121.123
2.6

Verenigde Staten, New York
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Japan Tokio
cdn.sayt.in
157.230.240.216
74.8

Australië, Sydney
cdn.sayt.in
157.230.240.216
95.9

De resultaten zijn goed. Laten we nu een testafbeelding in de hoofdmap van de hoofdsite plaatsen test.jpg en controleer de downloadsnelheid via CDN. Het is gezegd - gedaan. Inhoud wordt snel geleverd.

Laten we een klein script schrijven voor het geval we de cache op het CDN-punt willen wissen.
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 volledige cache te verwijderen, voert u deze gewoon uit. U kunt een afzonderlijk bestand als volgt wissen:

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

In plaats van conclusies

Tot slot wil ik nog enkele nuttige tips geven om meteen over de hark heen te stappen waar ik ooit hoofdpijn van kreeg:

Om de CDN-fouttolerantie te vergroten, wordt aanbevolen DNS Failover te configureren, wat helpt om het A-record snel te wijzigen in het geval van een serverstoring. Dit gebeurt in het configuratiescherm voor domein-DNS-records
Sites met een groot geografisch bereik zullen ongetwijfeld een groot aantal CDN-punten nodig hebben, maar laten we niet fanatiek zijn. Hoogstwaarschijnlijk zal de gebruiker geen significant verschil merken ten opzichte van een betaald CDN als je servers op 6-7 plaatsen plaatst: Europa, Noord-Amerika (oost), Noord-Amerika (west), Singapore, Australië, Hong Kong of Japan
Soms staan hosters het gebruik van gehuurde servers voor CDN-doeleinden niet toe. Als u daarom plotseling besluit een content delivery network als dienst in te zetten, vergeet dan niet vooraf de regels van uw specifieke hostingprovider te lezen
Ontdekken onderwatercommunicatiekaartom je voor te stellen hoe de continenten met elkaar verbonden zijn en hiermee rekening te houden bij het opbouwen van een contentleveringsnetwerk
Probeer het te controleren pingt vanaf verschillende plaatsen naar uw servers. Op deze manier kunt u de regio's zien die zich het dichtst bij CDN-punten bevinden en kunt u GeoDNS correcter configureren
Afhankelijk van de taken zou het nuttig zijn om Nginx aan te passen voor specifieke cachingvereisten en rekening houdend met de belasting van de server. Artikelen over de Nginx-cache hebben me hier enorm mee geholpen - hier en versnelling van het werk onder zware belasting: hier и hier