🥇Kogume ja seadistame oma CDN

Sisuhalduse sisu (CDN) kasutatakse veebilehtedel ja rakendustes peamiselt staatiliste elementide laadimise kiirusel. See toimub, salvestades faile CDN-serveritesse, mis asuvad erinevates geograafilistes piirkondades. Kui kasutaja taotleb andmeid läbi CDN-i, saab ta need lähimalt serverilt.

Tööprintsiip ja funktsioonid on kõigil sisuhalduse võrkudel enam-vähem ühesugused. Saades faililaadimise taotluse, tõmbab CDN-server selle esmakordselt originaalserverist ja edastab kasutajale, samal ajal salvestades selle endale etteantud ajavahemikuks. Kõikidele järgnevale taotlusele vastatakse vahemikust. Kõikidel CDN-idel on failide eelneva laadimise, vahemiku tühjendamise, selle säilitamise ajastamise valikud ja palju muud.

Mõnel juhul on vajalik luua oma sisuhalduse võrk ja siis — aitab meid taas kord juhend järgmise jalgratta kokkupanekuks.

Allikas: Infograafia vektor on loodud pikisuperstar - www.freepik.com

Kui on vajalik oma CDN

Kaalume olukordi, kus oma CDN-i käivitamine on mõistlik:

kui on soov säästa raha, samas kui praegused kulud isegi odavaid CDN-e nagu BunnyCDN koosnevad mitmest sajast dollarist kuus
kui soovime pidevat vahemälu või vahemälu ilma serveri ja kanali naabriteta
kui soovitud piirkonnas ei ole CDN-teenustel kohalolekupunkte
kui on vajalikud erilised sisu edastamise seaded
kui tahame kiirendada dünaamilise sisu edastamist, paigutades tootmisserverid lähemale kasutajatele
kui on kahtlus, et kolmas osaline CDN-teenus võib ebaseaduslikult koguda või kasutada kasutajakäitumise kohta teavet (tervitused, teenused, mis ei ole GDPR-i nõuetele vastavad) või tegeleda muude ebaseaduslike tegevustega

Enamikul teistel juhtudel on mõistlikum kasutada olemasolevaid valmis lahendusi.

Mida on tarvis käivitamiseks

Väga hästi, kui teil on oma iseseisev süsteem (AS). Sellega saab määrata mitmele serverile sama IP-aadressi ja selle juhendi järgi suunata kasutajad lähimasse. Tuleb öelda, et isegi /24 aadressibloki olemasolul on võimalik luua sisuhalduse võrk. Mõned serveriteenuse pakkujad lubavad kuulutada kasutamiseks kõikides nende saadaval olevates piirkondades.

Kui teil ei ole õnnelikku IP-aadresside plokki, siis vajate lihtsa CDN-i käivitamiseks järgmist:

domeeninime või alamdomeeni
vähemalt kahte serverit erinevates regionaalses asukohas. Server võib olla nii pühendatud kui ka virtuaalne
geoDNS tööriista. Selle abil suunatakse kasutaja, kes pöördub domeeni poole, lähimale serverile

Registreerime domeeni ja tellime serverid

Domeeni registreerimine on lihtne — registreerime igas tsoonis igasuguse registreerija juures. CDN-i jaoks saab kasutada ka alamdomeeni, näiteks midagi sellist nagu cdn.domeeninimi.com. Meie näites teeme just nii.

Serverite tellimise osas tasub neid rentida piirkondades ja riikides, kus asub teie kasutajaskond. Kui projekt on interkontinentaalne, siis on mugav valida hostimise pakkujad, kes pakuvad servereid üle kogu maailma. Näited: OVH, Leaseweb ja 100Tb — pühendatud serverite jaoks, Vultr ja DigitalOcean — virtuaalsete pilveserverite jaoks.

Meie privaatse CDN-i jaoks tellime 3 virtuaalset serverit eri kontinendidelt. Meie serverite hind on Vultr $5/kuu saame ruumi ja 25GB SSD 1TB liiklust. Paigaldamisel valime viimase Debian'i. Meie serverid:Frankfurdis,

ip: 199.247.18.199, ip: 149.28.121.123

Chicago, ip: 157.230.240.216

Singapur* Vultr ja DigitalOcean lubavad $100 krediiti registreeritud kasutajatele, kes liituvad artiklis toodud linkide kaudu, kohe pärast makseviisi lisamist. Autor saab samuti väikese boonuse, mis on talle praegu vägagi oluline. Palun võtke seda arvesse.

Seadistame geoDNS-i

Et kasutaja suunataks domeeni või alamdomeeni kaudu lähimale (temaga lähimale) serverile, vajame DNS-serverit, millel on geoDNS funktsioon.

geoDNS-i tööpõhimõte ja -järg on järgmine:

Määrab kliendi IP-aadresse, kes saadab DNS-päringu, või IP-aadressi rekursiivse DNS-serveri jaoks, mida kasutatakse kliendipäringu töötlemisel. Need rekursiivsed serverid on tavaliselt teenusepakkujate DNS-serverid.

Kliendi IP-aadressi põhjal määratakse tema riik või piirkond. Selleks kasutatakse GeoIP andmebaase, mida on tänapäeval palju. On head
tasuta variandid. Kliendi asukoha põhjal antakse talle lähima CDN-serveri IP-aadress..
GeoDNS-funktsiooniga DNS-serverit on võimalik

, kuid parem on kasutada valmis lahendusi, millel on DNS-serverite võrk üle kogu maailma ja ise kokku pannaAnycast valmiduses: CloudDNS

$9.95/kuu alates , GeoDNS hind, vaikimisi on olemas üks DNS Failover.Zilore
$25/kuu alates $25/kuus, lisatud DNS Failover
Amazon Route 53 alates $35/kuu puhaste 50M geoloogiliste päringute eest. DNS Failover on eraldi tasuline
DNS Made Easy alates $125/kuu, sisaldab 10 DNS Failover
Cloudflare, funktsioon „Geo Steering” on saadaval Enterprise plaanides

GeoDNS tellimisel tuleks tähelepanu pöörata plaani sisaldatud päringute arvule ja arvestada, et tegelik domeenipäringute arv võib mitu korda ületada ootusi. Miljonid roomikud, skannerid, rämpsposti saatjad ja muud soovimatud isikud töötavad tegevuses pidevalt.

Peaaegu kõikides DNS-teenustes on hinna sees asendamatu CDN-i seadmise teenus — DNS Failover. Selle abil on võimalik seadistada oma serverite töö jälgimine ja, kui elumärke ei ole, asendada automaatselt DNS-vastustes mittetöötava serveri aadress varu serveriga.

CDN-i loomiseks kasutame ClouDNS, plaan GeoDNS.

Lisame iseteeninduse keskkonnas uue DNS-tsooni, märkides oma domeeni. Kui CDN-i ehitatakse alamdomeenile ja põhidomeen on juba kasutuses, siis ärge unustage tsooni lisamisel mõne olemasoleva töötava DNS-kirje lisamist. Järgmiseks sammuks on mitme A-kirje loomine CDN-i domeeni/alamdomeeni jaoks, kus igaüht rakendatakse nimelt meie määratud piirkondade jaoks. Piirkondadeks võivad olla kontinendid või riigid, USA ja Kanada puhul on saadaval ka alampiirkonnad.

Meie puhul tõstame CDN-i alamdomeenil cdn.sayt.in. Lisades tsooni sayt.in, loome alamdomeeni esimese A-kirje ja suuname kogu Põhja-Ameerika serverisse Chicagosse:

Korrake tegevust teiste piirkondade jaoks, unustamata luua üks kirje vaikimisi piirkondade jaoks. Niimoodi näeb tulemus välja:

Viimane vaikimisi kirje ekraanipildil tähendab, et kõik määramata piirkonnad (sh Euroopa, Aafrika, satelliidi interneti kasutajad jms) suunatakse serverisse Frankfurtis.

Sellega on DNS-i põhi seadistus lõpetatud. Ülejäänud on see, et minna domeeni registri kodulehele ja asendada domeeni praegused NS-id ClouDNS-i antud omadega. Ja seni, kuni NS-id uuenevad, valmistame serverid ette.

SSL-sertifikaatide installimine

Meie CDN töötab HTTPS-i kaudu, seega kui teil on juba domeeni või alamdomeeni jaoks SSL-sertifikaadid, laadige need kõikidele serveritele üles, näiteks katalooge /etc/ssl/вашдомен/

Kui sertifikaate ei ole, saate tasuta sertifikaadi Let’s Encryptilt. Selleks sobib suurepäraselt ACME Shell skriptKlient on mugav ja lihtne seadistada ning mis kõige tähtsam — võimaldab valideerida domeeni/aladomeeni DNS kaudu ClouDNS API abil.

Installeerime acme.sh ainult ühele serverile — Euroopa serverile 199.247.18.199, kust sertifikaadid kopeeritakse kõikidele teistele. Installimiseks täidame:

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

Installimise käigus luuakse skripti jaoks CRON-ülesanne sertifikaatide automaatseks uuendamiseks meie osaluseta.

Domeeni kontroll sertifikaadi väljastamise ajal toimub DNS-i kaudu, kasutades API-d, seetõttu tuleb ClouDNS iseteeninduses Reseller API menüüs luua uus API kasutaja ja määrata talle parool. Saadud auth-id koos parooliga kirjutame faili ~/ .acme.sh/dnsapi/dns_cloudns.sh (ära sega seda faili segi dns_clouddns.sh). Siin on read, mida tuleb kommenteerimisest vabastada ja redigeerida:

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Nüüd taotleme SSL sertifikaadi saamist cdn.sayt.in

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

Parameetrites oleme tuleviku tarbeks määranud käsu veebiserveri konfiguratsiooni automaatseks taaskäivitamiseks pärast iga sertifikaadi kehtivusaja värskendamist.

Kogu sertifikaadi saamise protsess võib võtta kuni 2 minutit, ära katkesta seda. Kui domeeni valideerimisel tekib tõrge, proovi käsku uuesti käivitada. Lõpus näeme, kuhu sertifikaadid on laaditud:

Jätame need teed meelde, neid tuleb näidata sertifikaadi kopeerimisel teistesse serveritesse ning ka veebiserveri seadistustes. Nginxi konfiguratsioonide taaskäivitamise tõrketeateid ignoreerime — täielikult seadistatud serveris sertifikaatide värskendamisel neid ei esine.

Kõik, mis meil SSL-i osas jäänud on — tuleb kopeerida saadud sertifikaat kahte teise serverisse, säilitades failide teed. Loome igas neist sarnased kataloogid ja teeme koopia:

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/

Sertifikaatide regulaarseks uuendamiseks loome mõlemal serveril iga päev CRON-ülesande järgmise käsuga:

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

Samas peab ligipääs kaugserverile allikaks olema seadistatud võtmega, st. parooli sisestamata. Ära unusta seda teha.

Nginxi installimine ja seadistamine

Meie staatilise sisu edastamiseks kasutame Nginx'i, mis on seadistatud vahemälu proxy-serverina. Uuendame paketite nimekirju jainstallime selle kõigile kolmele serverile:

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

Kasutame vaikimisi asemel allpool toodud konfiguratsiooni:
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;
    }
  }
}

Muudame konfiguratsioonis:

max_size — vahemälu maksimaalne suurus, mis ei ületa saadaval olevat kettaruumi
inactive — mitteaktiivsete vahemälu andmete säilitamise aeg
ssl_certificate ja ssl_certificate_key — SSL-sertifikaadi ja võtme failide teed
proxy_cache_valid — vahemälu andmete säilitamise aeg
proxy_pass — originaalserveri aadress, millest CDN pärib faile vahemälu jaoks. Meie näites on see sayt.in

Nagu näeme, on kõik lihtne. Ainult vahemälu seadistamisel võib tekkida keerukus sarnaste direktiivide tõttu. inactive ja proxy_cache_validVaatame neid meie näites. Siin, mis juhtub, kui inactive=7d ja proxy_cache_valid 90d:

kui päringut ei kordata 7 päeva jooksul, kustutatakse andmed vahemälust pärast seda perioodi
kui päringut kordatakse vähemalt kord 7 päeva jooksul, loetakse andmed vahemälus aegunuks 90 päeva möödumisel ja Nginx uuendab need, võttes need originaalserverist

Lõpetanud muudatused nginx.conf, taaskäivitame konfiguratsiooni:

root@cdn:~# service nginx reload

Meie CDN on täielikult valmis. 15 dollari eest kuus saime kohaloleku kolmele mandrile ja 3 TB liiklust: 1 TB igas asukohas.

Kontrollime CDN-i toimimist

Vaadakem meie CDN-i pingeid erinevatest geograafilistest asukohtadest. Selleks sobivad igasugused pingeteenused.

Käivitamispunkt
Host
IP
Keskmine aeg, ms

Saksamaa, Berliin
cdn.sayt.in
199.247.18.199
9.6

Holland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Prantsusmaa, Pariis
cdn.sayt.in
199.247.18.199
16.3

Suurbritannia, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7

USA, Dallas
cdn.sayt.in
149.28.121.123
23.1

USA, Chicago
cdn.sayt.in
149.28.121.123
2.6

USA, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Jaapan, Tokyo
cdn.sayt.in
157.230.240.216
74.8

Austraalia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Tulemused on head. Paigutame nüüd põhisaidi juurese testpildi test.jpg ja kontrollime selle laadimiskiirust CDN-i kaudu. Ütlesin, — tehtud. Sisu edastatakse kiiresti.

Kirjutame väikese skripti juhuks, kui soovime CDN-i punktis vahemälu tühjendada.
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

Kogu vahemälu eemaldamiseks piisab lihtsalt selle käivitamisest, eraldi faili saab puhastada nii:

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

Järeldused

Lõpetuseks tahan anda mõned kasulikud näpunäited, et kohe üle tõkete astuda, mis kunagi mul peavalu tekitas:

CDN-i katkestusteta töö tagamiseks soovitatakse seadistada DNS Failover, mis aitab kiiresti A-kirje vahetada serveri rikke korral. Seda tehakse domeeni DNS-kirjete haldamise paneelis
Laialdase geograafilise katvusega veebisaidid vajavad kahtlemata suurt arvu CDN-punkte, aga teeme seda mõõdukalt. Tõenäoliselt ei märka kasutaja olulist erinevust võrreldes tasulise CDN-iga, kui paigutate serverid 6-7 kohta: Euroopa, Põhja-Ameerika (ida), Põhja-Ameerika (lääs), Singapur, Austraalia, Hongkong või Jaapan
Mõnikord ei luba hostijat teenindavad serverid CDN-i eesmärkidel kasutada. Seetõttu, kui otsustate luua sisu edastamise võrgustiku teenusena, ärge unustage eelnevalt tutvuda konkreetse hostimisteenuse pakkuja reeglitega
Uurige alajõudude kaarti, et mõista, kuidas kontinendid on omavahel seotud ja arvestada seda sisu edastamise võrgustiku loomisel
Proovige kontrollida pingisid erinevates kohtades teie serverite suhtes. Nii saab näha kõige lähemal asuvaid CDN-i punkte ja õigesti seadistada GeoDNS-i
Sõltuvalt ülesannetest on kasulik Nginx-i täiustamine konkreetsete vahemälu nõuete ja serveri koormuse arvessevõtmisega. Selles aitas mind väga Nginx-i vahemälu ja töö kiirus suurtel koormustel käsitlevad artiklid: siin ja töö kiirus suurte koormuste korral: siin ja siin