Nous assemblons et configurons notre CDN

Les réseaux de distribution de contenu (CDN) sont utilisés sur les sites et dans les applications principalement pour accélérer le chargement des éléments statiques. Cela se fait grâce à 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 le CDN, l'utilisateur les reçoit depuis le serveur le plus proche.

Le principe de fonctionnement et la fonctionnalité des réseaux de distribution de contenu sont à peu près les mêmes. Lorsqu'un serveur CDN reçoit une demande de chargement de fichier, il le récupère une fois depuis le serveur d'origine et le transmet à l'utilisateur, tout en le mettant en cache pour une période déterminée. Pour toutes les demandes suivantes, la réponse provient du cache. Tous les CDN disposent d'options de pré-chargement des fichiers, de nettoyage du cache, de configuration de la durée de conservation, et bien plus encore.

Il arrive que pour diverses raisons, il soit nécessaire d'organiser son propre réseau de distribution de contenu, et alors — que notre guide d'assemblage d'un vélo nous aide.

Source : Infographie vectorielle créée par pikisuperstar — www.freepik.com

Quand a-t-on besoin d'un CDN propre?

Examinons les cas où le lancement de son propre CDN a du sens :

• quand il y a un désir d'économiser, alors que les dépenses actuelles même en utilisant des CDN peu coûteux comme BunnyCDN s'élèvent à plusieurs centaines de dollars par mois
• si nous voulons obtenir un cache permanent ou un cache sans voisins sur le serveur et le canal
• dans la région souhaitée, il n'y a pas de points de présence pour les services CDN
• des configurations particulières de livraison de contenu sont nécessaires
• nous voulons accélérer la livraison de contenu dynamique en rapprochant les serveurs de production des utilisateurs
• il y a des inquiétudes qu'un service CDN tiers pourrait collecter ou utiliser indûment des informations sur le comportement des utilisateurs (salut aux services non conformes au RGPD) ou se livrer à d'autres actions inappropriées

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

Que faut-il pour lancer ?

C'est merveilleux si vous avez votre propre système autonome (AS). Avec cela, vous pouvez attribuer la même IP à plusieurs serveurs et suivre ce guide au niveau du réseau pour orienter les utilisateurs vers le plus proche. Il convient de noter qu'il est même possible de construire un réseau de distribution de contenu avec un bloc d'adresses /24. Certains fournisseurs de serveurs permettent de faire une annonce pour une utilisation dans toutes les régions accessibles.

Si vous ne possédez pas un bloc d'adresses IP, vous aurez besoin de pour lancer un CDN simple :

• un nom de domaine ou un sous-domaine
• au moins deux serveurs dans différentes régions. Le serveur peut être dédié ou virtuel
• un outil geoDNS. Grâce à cela, l'utilisateur, en se rendant sur le domaine, sera dirigé vers le serveur le plus proche

Nous enregistrons le domaine et commandons les serveurs

L'enregistrement du domaine est simple — on s'inscrit dans n'importe quelle zone auprès de n'importe quel registrar. Vous pouvez également utiliser un sous-domaine pour le CDN, par exemple quelque chose comme cdn.nomdedomaine.com. En fait, c'est ce que nous allons faire dans notre exemple.

Concernant la commande des serveurs, il est préférable de les louer dans les régions et les pays où se trouve votre audience. Si le projet est intercontinental, il est pratique de choisir des fournisseurs d'hébergement offrant des serveurs partout dans le monde. Exemples : OVH, Leaseweb et 100Tb — pour les serveurs dédiés, Vultr et DigitalOcean — pour les cloud virtuels*.

Pour notre CDN privé, nous allons commander 3 serveurs virtuels sur différents continents. À Vultr notre serveur à $5/mois nous aurons 25Go SSD d'espace et 1 To de trafic. Lors de l'installation, nous choisirons la dernière version de Debian. Nos serveurs :

Francfort, ip : 199.247.18.199

Chicago, ip : 149.28.121.123

Singapour, ip : 157.230.240.216

* Vultr et DigitalOcean offrent un crédit de $100 aux utilisateurs s'inscrivant via les liens de l'article, immédiatement après l'ajout d'un mode de paiement. L'auteur reçoit également un petit bonus, ce qui est significatif pour lui en ce moment. Merci de votre compréhension.

Configurons le geoDNS

Pour que l'utilisateur soit dirigé vers le serveur adéquat (le plus proche de lui) lorsqu'il accède au domaine ou au sous-domaine du CDN, nous avons besoin d'un serveur DNS avec la fonction geoDNS.

Le principe et le fonctionnement du geoDNS sont les suivants :

1. Il détermine l'IP du client qui a envoyé la requête DNS, ou l'IP du serveur DNS récursif utilisé lors du traitement de la demande du client. De tels serveurs récursifs sont généralement des DNS des fournisseurs.
2. Par l'IP du client, il détermine son pays ou sa région. Pour cela, on utilise des bases GeoIP, qui sont nombreuses aujourd'hui. Il existe de bonnes options gratuites.
3. En fonction de l'emplacement du client, il lui attribue l'IP du serveur CDN le plus proche.

Un serveur DNS avec la fonction geoDNS peut construit soi-même, mais il est préférable d'utiliser des solutions toutes faites avec un réseau de serveurs DNS à travers le monde et Anycast par défaut :

• CloudDNS à partir de $9.95/mois, tarif GeoDNS, par défaut il y a un DNS Failover
• Zilore à partir de $25/mois, DNS Failover inclus
• Amazon Route 53 à partir de 35 $/mois pour 50 millions de requêtes géographiques. DNS Failover est facturé séparément
• DNS Made Easy à partir de 125 $/mois, il y a 10 DNS Failover
• Cloudflare, la fonction « Geo Steering » est disponible dans les plans Enterprise

Lors de la commande de geoDNS, il est important de prêter attention au nombre de requêtes incluses dans le plan et de garder à l'esprit que le nombre réel d'appels au domaine peut largement dépasser les attentes. Des millions d'araignées, de robots, de spammeurs et autres nuisibles travaillent sans relâche.

Pratiquement tous les services DNS incluent dans leur tarif le service indispensable à la construction d'un CDN : DNS Failover. Grâce à cela, vous pouvez configurer la surveillance de vos serveurs et, en cas d'absence de réponse, remplacer automatiquement l'adresse du serveur non fonctionnel par celle d'un secours dans les réponses DNS.

Pour construire notre CDN, nous allons utiliser ClouDNS, le plan GeoDNS.

Ajoutons dans le tableau de bord une nouvelle zone DNS en spécifiant votre domaine. Si nous construisons le CDN sur un sous-domaine et que le domaine principal est déjà utilisé, n'oubliez pas d'ajouter les enregistrements DNS existants immédiatement après l'ajout de la zone. La prochaine étape consiste à créer plusieurs enregistrements A pour le domaine/sous-domaine du CDN, chacun étant appliqué à la région que nous avons spécifiée. Pour les régions, vous pouvez indiquer des continents ou des pays, avec des sous-régions disponibles pour les États-Unis et le Canada.

Dans notre cas, le CDN sera mis en place sur le sous-domaine cdn.sayt.in. En ajoutant la zone sayt.in, nous allons créer le premier enregistrement A pour le sous-domaine et diriger toute l'Amérique du Nord vers un serveur à Chicago :

Répétons l'action pour d'autres régions, n'oublions pas de créer un enregistrement pour les régions par défaut. Voici ce que cela donnera au final :

Le dernier enregistrement par défaut sur la capture d'écran signifie que toutes les régions non spécifiées (c'est-à-dire l'Europe, l'Afrique, les utilisateurs d'internet par satellite, etc.) seront dirigées vers un serveur à Francfort.

Nous avons donc terminé la configuration de base du DNS. Il reste à se rendre sur le site de l'enregistrement de domaine et à remplacer les NS actuels du domaine par ceux fournis par ClouDNS. Pendant que les NS seront mis à jour, nous préparerons les serveurs.

Installation des certificats SSL

Notre CDN fonctionnera en HTTPS, donc si vous avez déjà des certificats SSL pour le domaine ou le sous-domaine, veuillez les télécharger sur tous les serveurs, par exemple dans le répertoire /etc/ssl/вашдомен/

S'il n'y a pas de certificats, vous pouvez obtenir un certificat gratuit de Let’s Encrypt. Un bon choix serait d'utiliser le script ACME ShellLe client est facile et simple à configurer, et surtout, il permet de valider le domaine/sous-domaine via DNS à travers l'API de ClouDNS.

Nous installerons acme.sh uniquement sur un des serveurs - le serveur européen 199.247.18.199, à partir duquel les certificats seront copiés vers tous les autres. Pour l'installation, exécutez :

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

Au cours de l'installation du script, une tâche CRON sera créée pour la mise à jour future des certificats sans notre intervention.

La vérification du domaine lors de la délivrance du certificat sera effectuée via DNS en utilisant l'API, donc dans le cabinet personnel de ClouDNS, dans le menu Reseller API, vous devez créer un nouvel utilisateur API et définir un mot de passe pour celui-ci. Nous allons inscrire l'auth-id obtenu avec le mot de passe dans le fichier ~/.acme.sh/dnsapi/dns_cloudns.sh (ne pas confondre avec le fichier dns_clouddns.sh). Voici les lignes à décommenter et à modifier :

CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""

Maintenant, demandons la délivrance du certificat SSL pour cdn.sayt.in

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

Dans les paramètres, pour l'avenir, nous avons indiqué la commande pour un redémarrage automatique de la configuration du serveur web après chaque mise à jour de la durée de validité des certificats par la suite.

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

Gardons en mémoire ces chemins, ils devront être indiqués lors de la copie du certificat sur d'autres serveurs, ainsi que dans les paramètres du serveur web. Ne faisons pas attention aux erreurs de redémarrage des configs Nginx, - sur un serveur complètement configuré, lors de la mise à jour des certificats, cela ne se produira pas.

Tout ce qui nous reste à faire concernant SSL, c'est de copier le certificat obtenu sur deux autres serveurs en gardant le chemin vers les fichiers. Créons sur chacun d'eux les mêmes répertoires et faisons une copie :

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/

Pour que la mise à jour des certificats soit régulière, créons sur les deux serveurs une tâche CRON quotidienne avec la commande :

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

À cet égard, l'accès au serveur distant source doit être configuré par clé, c'est-à-dire sans saisie de mot de passe. N'oubliez pas de le faire.

Installation et configuration de Nginx

Pour la distribution de contenu statique, nous allons utiliser Nginx, configuré en tant que proxy-cache. Nous allons mettre à jour les listes de paquets et l'installer sur les trois serveurs :

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

Utilisons à la place la configuration 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;
    }
  }
}

Modifions la configuration :

• max_size — la taille du cache, ne dépassant pas l'espace disponible sur le disque
• inactive — la durée de conservation des données mises en cache qui n'ont pas été sollicitées
• ssl_certificate et ssl_certificate_key — chemins vers les fichiers de certificat SSL et la clé
• proxy_cache_valid — durée de conservation des données mises en cache
• proxy_pass — adresse du serveur d'origine, à partir duquel le CDN demandera des fichiers pour la mise en cache. Dans notre exemple, c'est sayt.in

Comme nous le voyons, c'est simple. La complexité peut seulement surgir dans la configuration du temps de mise en cache en raison de la similitude des directives. inactive et proxy_cache_validAnalysons-les dans notre exemple. Voici ce qui se passe avec inactive=7d et proxy_cache_valid 90d:

• si la requête n'est pas répétée pendant 7 jours, les données seront supprimées du cache à l'expiration de cette période.
• si la requête est répétée au moins une fois tous les 7 jours, les données dans le cache seront considérées comme obsolètes après 90 jours et lors de la prochaine requête, Nginx les mettra à jour en les récupérant sur le serveur d'origine.

Une fois les modifications terminées, nginx.confnous allons recharger la configuration :

root@cdn:~# service nginx reload

Notre CDN est entièrement prêt. Pour 15 $/mois, nous avons obtenu des points de présence sur trois continents et 3 To de trafic : 1 To dans chaque localisation.

Vérifions le fonctionnement du CDN

Jetons un œil aux pings vers notre CDN depuis différentes localisations géographiques. Tous les services de ping devraient fonctionner.

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

Royaume-Uni, 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 test à la racine du site principal test.jpg et vérifier la vitesse de chargement via le CDN. Il a été dit, — a été fait. Le contenu se charge rapidement.

Nous allons écrire un petit script au cas où nous souhaiterions vider le cache au niveau du 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 tout le cache, il suffit de le lancer, un fichier séparé peut être vidé comme suit :

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

Au lieu des conclusions

Enfin, je veux donner quelques conseils utiles pour éviter les pièges qui m'ont fait souffrir par le passé :

• Pour améliorer la résilience du CDN, il est recommandé de configurer le DNS Failover, qui aide à changer rapidement l'enregistrement A en cas de panne du serveur. Cela se fait dans le panneau de gestion des enregistrements DNS du domaine.
• Les sites avec une large couverture géographique nécessitent sans aucun doute un grand nombre de points CDN, mais faisons-le sans excès. Il est 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 de CDN. Donc, si jamais vous décidez de déployer un réseau de livraison de contenu en tant que service, n'oubliez pas de lire à l'avance les règles spécifiques du fournisseur d'hébergement.
• Étudiez la carte des communications sous-marines, pour comprendre comment les continents sont liés et prendre cela en compte lors de la construction du réseau de livraison de contenu.
• Essayez de vérifier les pings depuis différents endroits vers vos serveurs. Cela permet de voir les régions les plus proches des points CDN et de configurer plus correctement le GeoDNS.
• Selon les tâches, il peut être utile de régler Nginx en fonction des exigences 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é dans ce domaine — ici et sur l'accélération des performances en cas de charges importantes : ici et ici

Source : habr.com