Source de l’image: Vecteur infographie créé par pikisuperstar — www.freepik.com

Les réseaux de diffusion de contenu (CDN) sont généralement utilisés par les sites et les applications pour accélérer le chargement d’éléments statiques. Ceci est accompli en mettant en cache des fichiers sur des serveurs CDN situés dans diverses régions du monde. Après avoir demandé des données via CDN, l’utilisateur les reçoit du serveur le plus proche.

Les principes sous-jacents des CDN et leur fonctionnalité sont à peu près les mêmes pour tous. Après avoir reçu une demande de fichier, un serveur CDN le prend une fois du serveur d’origine, puis le transfère à l’utilisateur et en met en cache une copie pendant un certain temps. D’autres demandes de données sont traitées à l’aide du cache. Tous les CDN ont des options pour le préchargement des fichiers, la suppression du cache, les temps de rétention du cache et bien plus encore.

Parfois, pour diverses raisons, on peut se retrouver dans le besoin de construire son propre CDN, et donc, nous présentons le guide suivant sur la façon de le réaliser.

Quand avez-vous besoin de votre propre CDN ?

Examinons les situations où vous pourriez avoir besoin de créer votre propre CDN:

• lorsque vous essayez d’économiser de l’argent et même des solutions abordables comme BunnyCDN finissent par vous coûter des centaines de dollars par mois
• lorsque vous souhaitez obtenir un cache permanent ou que vous avez besoin d’une bande passante et de ressources garanties
• les CDN existants n’ont pas de POP dans votre région cible
• vous avez besoin de paramètres de diffusion de contenu spéciaux
• vous voulez accélérer la livraison du contenu dynamique en le servant au plus près des utilisateurs
• vous craignez que des CDN tiers ne collectent et n’utilisent illégalement des données utilisateur (hé là, des serveurs qui ne le sont pas Conforme au RGPD) ou se livrer à d’autres activités illicites

Dans la plupart des autres cas, il est plus viable d’utiliser des solutions toutes faites existantes.

Créons notre propre CDN

Pour créer même un réseau de diffusion de contenu simple, vous avez besoin des éléments suivants:

• nom de domaine ou un sous-domaine
• un minimum de deux serveurs dans des régions différentes. Les serveurs peuvent être dédiés ou virtuels
• outil geoDNS. Avec elle, un utilisateur envoyant une demande au domaine sera dirigé vers le serveur le plus proche

Enregistrer un domaine et commander des serveurs

Enregistrer un nom de domaine est facile — il suffit de l’enregistrer dans n’importe quelle zone de domaine que vous préférez. Pour CDN, vous pouvez également utiliser un sous-domaine, comme cdn.domainname.com . C’est le cas pour l’exemple suivant.

En ce qui concerne les serveurs, vous devez les louer dans les régions et les pays où se trouve votre public cible. Si votre projet est intercontinental, il est pratique de choisir parmi les fournisseurs d’hébergement qui proposent des serveurs à travers le monde, tels que OVH, Leaseweb et 100 To (pour les serveurs dédiés), ou Vultr et DigitalOcean (pour les serveurs virtuels et cloud).

Pour notre CDN privé, commandons trois serveurs virtuels sur différents continents. Vultr nous offre 25 Go d’espace SSD et 1 To de trafic pour 5 $ / mois. Lors de l’installation, sélectionnez la dernière Debian. Voici nos serveurs:

• Francfort, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapour, ip: 157.230.240.216

Configuration de geoDNS

Pour nous assurer que les clients sont dirigés vers les serveurs appropriés (les plus proches) lors de l’envoi de demandes à notre domaine ou sous-domaine, nous aurons besoin d’un serveur DNS doté de la fonctionnalité geoDNS.

Voici comment fonctionne geoDNS:

1. Il obtient l’IP du client (s’il a envoyé la demande DNS) ou l’IP du serveur DNS récursif utilisé pour traiter la demande. De manière générale, ces serveurs récursifs sont généralement les DNSs des fournisseurs d’accès Internet.
2. Par l’adresse IP du client, il identifie son pays ou sa région. Cette opération nécessite l’utilisation de la base de données GeoIP, qui sont disponibles en quantité suffisante. Il existe même des options gratuites décentes.
3. Selon l’emplacement du client, geoDNS lui renvoie l’adresse IP du serveur CDN le plus proche.

Un serveur DNS avec la fonctionnalité geoDNS est quelque chose que vous pouvez construire vous-même, mais il est préférable d’utiliser des solutions prêtes à l’emploi qui ont des serveurs dans le monde entier et une option Anycast prête à l’emploi:

• ClouDNS, à partir de 9 $.95 / mois, paquet GeoDNS, un basculement DNS est fourni par défaut
• Zilore, à partir de 25 $ / mois, comprend le basculement DNS
• Amazon Route 53, à partir de 35 $ / mois pour 50 millions de requêtes géographiques. Le basculement DNS est facturé séparément
• DNS Made Easy, à partir de 125 $ / mois, avec 10 basculements DNS
• Cloudflare, la fonctionnalité de pilotage géographique est fournie dans les packages d’entreprise

Lors de la commande de geoDNS, vous devez faire attention au nombre de requêtes incluses dans le package et garder à l’esprit que le nombre réel de requêtes peut largement dépasser vos attentes. Il y a des millions d’robots d’exploration Web, de scanners, de spammeurs et d’autres démons au travail à un moment donné.

Presque tous les services DNS incluent une fonctionnalité utile pour la création de CDN : le basculement DNS. Avec lui, vous pouvez configurer la surveillance de l’activité de sorte que si un serveur tombe en panne, le système redirigera automatiquement les clients vers des serveurs fonctionnels à la place.

Pour notre CDN, utilisons ClouDNS et son package GeoDNS.

Dans profil, ajoutez une nouvelle zone DNS et spécifiez votre nom de domaine. Si vous utilisez un sous-domaine et que le domaine principal est utilisé, n’oubliez pas d’ajouter les enregistrements DNS existants immédiatement après l’ajout de la zone. L’étape suivante consiste à créer plusieurs enregistrements A pour le domaine /sous-domaine CDN, chacun étant utilisé pour la région spécifiée. Vous pouvez désigner des continents ou des pays comme régions, et des options de sous-régions sont disponibles pour les États-Unis et le Canada.

Dans notre exemple, le CDN fonctionnera sur le cdn.sayt.in sous-domaine. Après avoir ajouté le sayt.in zone, créez le premier enregistrement A pour le sous-domaine et dirigez tous les clients NA vers le serveur de Chicago:

Répétez cette étape pour les autres régions et n’oubliez pas de créer un enregistrement pour les régions par défaut. Voici à quoi ressemble le résultat final:

Le dernier enregistrement par défaut signifie les demandes de toutes les régions non spécifiées (Europe, Afrique, utilisateurs d’Internet par satellite, etc.) doivent être dirigés vers le serveur de Francfort.

Ceci conclut la configuration DNS de base. Il ne reste plus qu’à aller sur le site Web du registraire et à remplacer les serveurs de noms actuels par ceux fournis par ClouDNS. Pendant qu’ils sont mis à jour, nous définirons 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, téléchargez-les sur tous les serveurs, par exemple, dans le répertoire /etc/ssl/yourdomain/.

Si vous n’avez aucun certificat, vous pouvez l’obtenir gratuitement auprès de Let’s Encrypt. Le script shell ACME est une excellente option. Il dispose d’un client convivial et, plus important encore, il permet d’effectuer la validation du domaine / sous-domaine via DNS en utilisant l’API par ClouDNS.

Nous allons installer acme.sh sur un seul serveur – le serveur européen (199.247.18.199), et à partir de celui-ci, les certificats seront copiés sur tous les autres. Pour l’installer, exécutez la commande suivante:

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

Lors de l’installation, une tâche CRON pour la mise à jour automatique des certificats sera créée.

La vérification du domaine lors de l’émission du certificat sera effectuée via DNS à l’aide de l’API, donc dans le profil ClouDNS, sous l’API du revendeur, créez un nouvel utilisateur de l’API et spécifiez un mot de passe pour celui-ci. Entrez l’auth-id résultant avec le mot de passe dans le fichier suivant: ~/.acme.sh/dnsapi/dns_cloudns.sh (à ne pas confondre avec dns_clouddns.sh ). Voici les lignes que vous devez décommenter et modifier:

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

Maintenant, demandons l’émission du certificat SSL pour cdn.sayt.en

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

Pour une utilisation future, dans paramètres, nous avons laissé une commande de redémarrage automatique de la configuration après chaque renouvellement du certificat.

Le processus d’acquisition du certificat peut prendre jusqu’à deux minutes, alors ne l’interrompez pas. Au cas où une erreur de validation de domaine se produirait, essayez à nouveau d’exécuter la commande. À la fin, nous verrons où les certificats ont été téléchargés.

Rappelez-vous ces chemins, nous devrons les spécifier lors de la copie des certificats sur d’autres serveurs et nous devrons les spécifier dans les paramètres du serveur. Ignorez l’erreur de rechargement de la configuration Nginx, elle ne se produira pas sur un serveur entièrement configuré lors du renouvellement du certificat.

Quant au certificat SSL, il ne nous reste plus qu’à le copier sur les deux autres serveurs en enregistrant les chemins de certificat. Créez des répertoires identiques sur chaque serveur, puis copiez les fichiers de certificats:

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 automatiser le renouvellement du certificat, vous devez créer une tâche CRON quotidienne sur les deux serveurs. Voici la commande que vous devez ajouter aux tâches CRON:

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

Gardez à l’esprit que la connexion au serveur d’origine distant nécessite un accès par clé sans entrer de mot de passe. N’oubliez pas de le créer.

Installation et configuration de Nginx

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

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

Au lieu de la configuration par défaut, utilisez celle 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; } }}

Dans la configuration, modifions:

• max_size — taille du cache ne dépassant pas l’espace disque disponible
• inactive — temps de rétention pour les données mises en cache non demandées
• ssl_certificate et ssl_certificate_key — chemins d’accès au certificat et à la clé SSL
• proxy_cache_valid — temps de rétention pour les données mises en cache
• proxy_pass — adresse du serveur d’origine à partir duquel le CDN demandera des données pour la mise en cache. Pour notre exemple, c’est sayt.in

Comme vous pouvez le voir, ce n’est pas sorcier. La seule difficulté est de configurer le temps de rétention, compte tenu des similitudes entre les paramètres inactifs et proxy_cache_valid. Regardons de plus près. Voici ce qui se passe avec inactive=7d et proxy_cache_valid=90d:

• si la requête n’est pas répétée dans les 7 jours, les données sont supprimées du cache
• si la requête est répétée une seule fois pendant 7 jours, le cache sera considéré comme obsolète après 90 jours et la requête suivante obligera Nginx à le mettre à jour depuis le serveur d’origine

Avec nginx.conf manipulé, rechargez la configuration:

root@cdn:~# service nginx reload

Notre CDN est donc prêt à l’emploi ! Pour 15 $ / mois, nous avons obtenu des POP sur trois continents et 3 To de trafic: 1 To pour chaque région.

Vérification de notre CDN

Jetons un coup d’œil au ping vers notre CDN à partir de différents endroits. Tous les services de ping feront l’affaire dans ce cas.

Les résultats sont bons. Maintenant, plaçons une image de test intitulée test.jpg sur le serveur principal et vérifiez à quelle vitesse il se charge via CDN. Dit et fait. Le chargement est rapide.

Faisons un petit script au cas où nous aurions besoin d’effacer le cache sur un point CDN.

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

Pour vider tout le cache sur le serveur, exécutez simplement le script. Si vous avez besoin d’un fichier purgé, spécifiez simplement son chemin:

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

Pour purger le cache partout, le script doit être exécuté sur tous les serveurs CDN.

Au lieu de conclusions

Enfin, je voudrais donner quelques conseils utiles pour que vous puissiez éviter de tomber dans les pièges que j’ai déjà éliminés:

• Tenez compte de la viabilité et des coûts de maintenance de votre futur CDN. Dans la plupart des cas, il est beaucoup plus efficace et plus facile d’acheter un CDN bon marché, qui sera probablement plus stable et de meilleure qualité.
• Pour améliorer la tolérance aux pannes du CDN, il est recommandé de configurer un basculement DNS, ce qui vous permettrait de changer rapidement l’enregistrement A en cas de panne d’un serveur. Vous pouvez le faire dans le panneau de configuration des enregistrements DNS.
• Les sites Web à large couverture nécessitent un grand nombre de POP, mais ne font pas preuve d’excès de zèle. Très probablement, un utilisateur ne remarquera pas la différence entre votre CDN et un CDN payant, si vous avez 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 fournisseurs d’hébergement ne permettent pas d’utiliser des serveurs loués pour les CDN. Donc, si vous cherchez à créer un service CDN, assurez-vous de lire les conditions générales du fournisseur d’hébergement.
• Étudiez la carte des câbles sous-marins pour comprendre comment les continents sont connectés et utilisez ces connaissances lors de la construction de votre CDN.
• Essayez d’envoyer un ping à vos serveurs à partir de différents emplacements. De cette façon, vous pouvez repérer les régions les plus proches de vos POP et cela vous aidera à configurer les géodn.