🥇Construire et configurer votre CDN

Les réseaux de diffusion de contenu (CDN) sont utilisés dans les sites Web et les applications principalement pour accélérer le chargement d'éléments statiques. Cela se produit en raison de la mise en cache des fichiers sur des serveurs CDN situés dans différentes régions géographiques. En demandant des données via CDN, l'utilisateur les reçoit du serveur le plus proche.

Le principe de fonctionnement et la fonctionnalité de tous les réseaux de diffusion de contenu sont à peu près les mêmes. Après avoir reçu une demande de téléchargement d'un fichier, le serveur CDN le récupère une seule fois sur le serveur d'origine et le remet à l'utilisateur, tout en le mettant en cache pendant une période de temps spécifiée. Toutes les demandes ultérieures reçoivent une réponse à partir du cache. Tous les CDN disposent d'options pour précharger les fichiers, vider le cache, définir la date d'expiration, etc.

Il arrive que, pour une raison ou une autre, vous deviez organiser votre propre réseau de diffusion de contenu, puis que les instructions pour assembler le prochain vélo nous soient utiles.

Source: Vecteur infographique créé par pikisuperstar - www.freepik.com

Quand vous avez besoin de votre propre CDN

Considérez les cas où il est logique d’exécuter votre propre CDN :

lorsqu'on souhaite économiser de l'argent et des coûts de fonctionnement, même en utilisant des CDN bon marché comme LapinCDN cela représente plusieurs centaines de dollars par mois
si nous voulons obtenir un cache permanent ou un cache sans voisins de serveur et de canal
Les services CDN n'ont pas de points de présence dans la région dont vous avez besoin
tout paramètre de diffusion de contenu spécial requis
nous souhaitons accélérer la diffusion de contenu dynamique en plaçant le serveur de production plus proche des utilisateurs
il existe une crainte qu'un service CDN tiers puisse collecter ou utiliser illégalement des informations sur le comportement des utilisateurs (bonjour les services non conformes au RGPD) ou se livrer à d'autres activités illégales

Dans la plupart des autres cas, il est plus approprié d'utiliser des solutions prêtes à l'emploi existantes.

De quoi avez-vous besoin pour commencer

C'est merveilleux si vous disposez de votre propre système autonome (AS). Avec lui, vous pouvez attribuer la même IP à plusieurs serveurs et selon cette instruction au niveau du réseau, dirigez les utilisateurs vers le réseau le plus proche. Il faut dire que même avec le bloc d'adresses /24, il est possible de construire un réseau de diffusion de contenu. Certains fournisseurs de serveurs vous permettent de faire une annonce à utiliser dans toutes les régions à leur disposition.

Si vous n'êtes pas l'heureux propriétaire d'un bloc d'adresses IP, alors pour exécuter un simple CDN, vous aurez besoin de :

nom de domaine ou sous-domaine
au moins deux serveurs dans des régions différentes. Le serveur peut être dédié ou virtuel
Outil géoDNS. Avec lui, l'utilisateur, ayant adressé le domaine, sera dirigé vers le serveur le plus proche

Enregistrez un domaine et commandez des serveurs

Avec l'enregistrement de domaine, tout est simple : nous nous enregistrons dans n'importe quelle zone auprès de n'importe quel registraire. Vous pouvez également utiliser un sous-domaine pour un CDN, par exemple quelque chose comme cdn.nomdedomaine.com. En fait, dans notre exemple, c’est exactement ce que nous ferons.

Quant aux serveurs de commande, ils doivent être loués dans les régions et les pays où se trouve votre public d'utilisateurs. Si le projet est intercontinental, il est alors pratique de choisir des hébergeurs proposant des serveurs dans le monde entier à la fois. Exemples: OVH, LocationWeb и 100Tb - pour les serveurs dédiés, Vultr и DigitalOcean — pour le cloud virtuel*.

Pour notre CDN privé, nous commanderons 3 serveurs virtuels sur différents continents. À Vultr sur le serveur pour 5 $/mois Nous obtiendrons 25GB SSD des lieux et 1 To de trafic. Lors de l'installation, sélectionnez la dernière Debian. Nos serveurs :

Francfort, adresse IP : 199.247.18.199

Chicago, adresse IP : 149.28.121.123

Singapour, adresse IP : 157.230.240.216

* Vultr et DigitalOcean promettent un crédit de 100 $ aux utilisateurs qui s'inscrivent via les liens contenus dans l'article immédiatement après avoir ajouté un mode de paiement. L'auteur en reçoit également un petit compliment, qui est désormais très significatif pour lui. S'il vous plaît, soyez compréhensif.

Configuration du géoDNS

Pour que l'utilisateur soit dirigé vers le serveur souhaité (le plus proche) lors de l'accès à un domaine ou un sous-domaine CDN, nous avons besoin d'un serveur DNS avec la fonction geoDNS.

Le principe et le fonctionnement du geoDNS est le suivant :

Spécifie l'adresse IP du client qui a envoyé la requête DNS ou l'adresse IP du serveur DNS récursif utilisé lors du traitement de la requête client. Ces serveurs récursifs sont généralement des DNS de fournisseurs.
L'IP du client reconnaît son pays ou sa région. Pour cela, on utilise les bases de données GeoIP, qui sont aujourd'hui très nombreuses. Il y a du bon options gratuites.
En fonction de la localisation du client, lui donne l'adresse IP du serveur CDN le plus proche.

Un serveur DNS avec fonction geoDNS peut être assembler vous-même, mais il vaut mieux utiliser des solutions toutes faites avec un réseau de serveurs DNS à travers le monde et Anycast de la boite:

CloudDNS à partir de 9.95 $/mois, tarif GeoDNS, par défaut il y a un DNS Failover
Ziloré à partir de 25 $/mois, Basculement DNS activé
Amazon Route 53 à partir de 35 $/mois pour un montant net de 50 millions de géo-requêtes. Le basculement DNS est facturé séparément
DNS simplifié à partir de 125 $/mois, il y a 10 basculements DNS
Cloudflare, la fonctionnalité "Geo Steering" est disponible dans les forfaits Entreprise

Lors de la commande de geoDNS, vous devez faire attention au nombre de requêtes incluses dans le tarif et garder à l'esprit que le nombre réel de requêtes vers le domaine peut dépasser plusieurs fois les attentes. Des millions d’araignées, scanners, spammeurs et autres mauvais esprits travaillent sans relâche.

Presque tous les services DNS incluent un service indispensable pour créer un CDN – DNS Failover. Avec son aide, vous pouvez mettre en place une surveillance du fonctionnement de vos serveurs et, en l'absence de signes de vie, remplacer automatiquement l'adresse d'un serveur qui ne fonctionne pas par une adresse de sauvegarde dans les réponses DNS.

Pour construire notre CDN, nous utiliserons CloudDNS, tarif GeoDNS.

Ajoutons une nouvelle zone DNS dans votre compte personnel, en précisant votre domaine. Si nous construisons un CDN sur un sous-domaine et que le domaine principal est déjà utilisé, immédiatement après avoir ajouté la zone, n'oubliez pas d'ajouter les enregistrements DNS fonctionnels existants. L'étape suivante consiste à créer plusieurs enregistrements A pour le domaine/sous-domaine CDN, dont chacun sera appliqué à la région que nous avons spécifiée. Vous pouvez spécifier des continents ou des pays comme régions, des sous-régions sont disponibles pour les États-Unis et le Canada.

Dans notre cas, le CDN sera remonté sur un sous-domaine cdn.sayt.in. En ajoutant une zone dire.dans, créez le premier enregistrement A pour le sous-domaine et pointez toute l'Amérique du Nord vers le serveur de Chicago :

Répétons l'action pour les autres régions, en n'oubliant pas de créer une entrée pour les régions par défaut. Voici ce qui se passe à la fin :

La dernière entrée par défaut dans la capture d'écran signifie que toutes les régions non spécifiées (à savoir l'Europe, l'Afrique, les utilisateurs d'Internet par satellite, etc.) seront envoyées au serveur de Francfort.

Ceci termine la configuration DNS de base. Il reste à se rendre sur le site du registraire de domaine et à remplacer les domaines NS actuels par ceux émis par ClouDNS. Et pendant que les NS seront mis à jour, nous préparerons les serveurs.

Installation de certificats SSL

Notre CDN fonctionnera via HTTPS, donc si vous disposez déjà de certificats SSL pour un domaine ou un sous-domaine, téléchargez-les sur tous les serveurs, par exemple dans l'annuaire /etc/ssl/votredomaine/

S'il n'y a pas de certificat, vous pouvez en obtenir un gratuitement auprès de Let's Encrypt. Parfait pour ça Script de shell ACME. Le client est pratique et facile à mettre en place, et surtout, il permet de valider un domaine/sous-domaine par DNS via l'API ClouDNS.

Nous installerons acme.sh sur un seul des serveurs - européen 199.247.18.199, à partir duquel les certificats seront copiés sur tous les autres. Pour installer, exécutez :

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

Lors de l'installation du script, un travail CRON sera créé pour un renouvellement ultérieur des certificats sans notre participation.

Lors de l'émission d'un certificat, le domaine sera vérifié à l'aide de DNS à l'aide de l'API, donc dans le compte personnel ClouDNS dans le menu API revendeur, vous devez créer une nouvelle API utilisateur et définir un mot de passe pour celle-ci. L'identifiant d'authentification résultant avec un mot de passe sera écrit dans le fichier ~/.acme.sh/dnsapi/dns_cloudns.sh (à ne pas confondre avec le fichier dns_clouddns.sh). Voici les lignes qui doivent être décommentées et modifiées :

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

Nous allons maintenant demander un certificat SSL pour cdn.sayt.in

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

Dans les options, pour le futur, nous avons précisé une commande permettant de recharger automatiquement la configuration du serveur web après chaque renouvellement de la période de validité du certificat dans le futur.

L'ensemble du processus d'obtention d'un certificat peut prendre jusqu'à 2 minutes, ne l'interrompez pas. Si une erreur de validation de domaine se produit, essayez à nouveau d'exécuter la commande. À la fin, nous verrons où les certificats ont été téléchargés :

N'oubliez pas ces chemins, ils devront être précisés lors de la copie du certificat sur d'autres serveurs, ainsi que dans les paramètres du serveur web. Nous ne prêtons pas attention à l'erreur de rechargement des configurations Nginx - elle ne sera pas sur un serveur entièrement configuré lors de la mise à jour des certificats.

Il ne reste plus au SSL que de copier le certificat reçu sur deux autres serveurs tout en conservant le chemin d'accès aux fichiers. Créons les mêmes répertoires sur chacun d'eux et faisons une copie :

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/

Pour mettre à jour régulièrement les certificats, créez une tâche CRON quotidienne sur les deux serveurs avec la commande :

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

Dans ce cas, l'accès au serveur source distant doit être configuré par clé, c'est à dire. sans entrer de mot de passe. N'oubliez pas de le faire.

Installer et configurer Nginx

Pour servir du contenu statique, nous utiliserons Nginx configuré comme serveur proxy de mise en cache. Mettez à jour les listes de packages et installez-les sur les trois serveurs :

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

Au lieu de la configuration par défaut, nous utilisons la configuration du spoiler ci-dessous :
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;
    }
  }
}

Modifier dans la configuration :

taille max — la taille du cache, ne dépassant pas l'espace disque disponible
inactif - durée de stockage des données mises en cache auxquelles personne n'a accédé
ssl_certificate и ssl_certificate_key — chemins vers le certificat SSL et les fichiers de clés
proxy_cache_valid - durée de stockage des données mises en cache
proxy_pass — adresse du serveur d'origine à partir duquel le CDN demandera la mise en cache des fichiers. Dans notre exemple, ceci dire.dans

Comme vous pouvez le constater, tout est simple. La difficulté ne peut survenir que dans le réglage du temps de mise en cache en raison de la similitude des directives inactif и proxy_cache_valid. Analysons-les avec notre exemple. Voici ce qui se passe lorsque inactif = 7j и proxy_cache_valid 90j:

si la demande n'est pas répétée dans les 7 jours, alors les données seront supprimées du cache après ce délai
si la requête est répétée au moins une fois tous les 7 jours, alors les données dans le cache seront considérées comme obsolètes après 90 jours et Nginx les mettra à jour avec la requête suivante, en les retirant du serveur d'origine

Terminé la modification nginx.conf, rechargez la configuration :

root@cdn:~# service nginx reload

Notre CDN est prêt. Pour 15 $/mois. nous avons reçu des points de présence sur trois continents et 3 To de trafic : 1 To dans chaque emplacement.

Vérification du travail de CDN

Examinons les pings vers notre CDN à partir de différents emplacements géographiques. N'importe quel service ping fonctionnera pour cela.

Point de lancement
Hôte
IP
Temps moyen, ms

Allemagne Berlin
cdn.sayt.in
199.247.18.199
9.6

Pays-Bas, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

France Paris
cdn.sayt.in
199.247.18.199
16.3

Grande Bretagne, Londres
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

États-Unis, San Francisco
cdn.sayt.in
149.28.121.123
52.7

États-Unis, Dallas
cdn.sayt.in
149.28.121.123
23.1

États-Unis, Chicago
cdn.sayt.in
149.28.121.123
2.6

États-Unis, New York
cdn.sayt.in
149.28.121.123
19.8

Singapour
cdn.sayt.in
157.230.240.216
1.7

Japon Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australie, Sydney
cdn.sayt.in
157.230.240.216
95.9

Les résultats sont bons. Nous allons maintenant placer une image de test à la racine du site principal test.jpg et vérifiez sa vitesse de téléchargement via CDN. C'est dit - fait. Le contenu est livré rapidement.

Écrivons un petit script au cas où nous voudrions vider le cache sur le point CDN.
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

Pour supprimer l'intégralité du cache, exécutez-le simplement, un fichier séparé peut être nettoyé comme ceci :

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

Au lieu de conclusions

Enfin, je souhaite donner quelques conseils utiles afin d'enjamber immédiatement le râteau qui m'a fait mal à la tête à l'époque :

Pour augmenter la tolérance aux pannes du CDN, il est recommandé de configurer le basculement DNS, qui permet de modifier rapidement l'enregistrement A en cas de panne du serveur. Cela se fait dans les enregistrements DNS du panneau de contrôle du domaine.
Les sites à large couverture géographique nécessitent sans doute un grand nombre de CDN, mais ne soyons pas fanatiques. Il est fort probable que l'utilisateur ne remarquera pas de différence significative par rapport à un CDN payant si vous placez des serveurs dans 6 à 7 emplacements : Europe, Amérique du Nord (est), Amérique du Nord (ouest), Singapour, Australie, Hong Kong ou Japon.
Parfois, les hébergeurs n'autorisent pas l'utilisation de serveurs loués à des fins CDN. Par conséquent, si vous décidez soudainement de déployer un réseau de diffusion de contenu en tant que service, n'oubliez pas de lire à l'avance les règles d'un fournisseur d'hébergement particulier.
Étude carte de communications sous-marinesreprésenter la façon dont les continents sont connectés et en tenir compte lors de la construction d'un réseau de diffusion de contenu
Essayez de vérifier pings de différents endroits à vos serveurs. De cette façon, vous pouvez voir les régions les plus proches des points CDN et configurer GeoDNS plus correctement
En fonction des tâches, il sera utile d'affiner Nginx pour des besoins spécifiques de mise en cache et en tenant compte de la charge sur le serveur. Les articles sur le cache Nginx m'ont beaucoup aidé - ici et accélération du travail sous de lourdes charges : ici и ici

Source: habr.com