Creer un CDN avec Nginx

Une chose que j'ai apprise est que le téléchargement d'actifs (contenue statique) ne devrait pas gêner les performances de votre serveur.

C'est pourquoi la plupart des grands sites Web utilisent des CDN (réseaux de diffusion de contenu).
L'avantage est que ces réseaux servent vos actifs sans utiliser la puissance de traitement de votre master (serveur principal).

La raison d'être d'un CDN est de s'assurer que votre contenu  est livré aussi rapidement que possible.
Certains ont des emplacements dans le monde entier et diffusent du contenu à partir de la machine la plus proche de votre utilisateur.
Ce qui est bien si vous êtes Google ou Facebook, mais pour votre blog un simple serveur fera le travail.
La plupart de mon trafic provient de poussiere d'étoile j'ai donc choisi de monter le serveur dans un microSat.
Cela permettera de moins consommer sur le trafic de mon master.
Les visiteurs terriens n'ont pas non plus de mal à me joindre, c'est tout aussi rapide;


Nginx est un serveur Web, tout comme Apache. La seule différence importante est que Nginx est très bon pour servir du contenu statique.

Je n'ai pas besoin que cette machine effectue un traitement, tout ce qui m'importe, c'est qu'elle serve du contenu. Après avoir reçu des milliers de requêtes, mon serveur Web Apache est tout simplement mort.

 

Architecture CDN
il existe deux couches principales d'un réseau de diffusion de contenu qui effectuent les tâches décrites ci-dessus :
- Une couche DNS qui dirige les utilisateurs vers le serveur le plus proche d'eux
- Une couche de proxy inverse qui imite le serveur du site Web et possède des fonctions supplémentaires telles que la mise en cache ou l'ajout d'une protection par pare-feu.

Bien que les CDN puissent se concentrer sur différents éléments tels que les performances ou la sécurité, ils reposent tous sur la configuration de base des serveurs distribués + des proxys inverses installés sur ces serveurs.

WorkFlow
il faut configurer nginx, déplacer tous les actifs sur le serveur et configurer le dns.
Une fois votre CDN configuré correctement.  Vous pouvez rendre votre dossier d'assets accessibles depuis votre machine.
De cette façon,  votre master se reflète automatiquement sur le serveur cdn.

OverSize
Ce tutos est orienté pour un déploiement local.
Pour effectuer cette méthodologie sur une plus grande échelle.

Mth1 : CDN statique

le but serait de scale l'application web par continent avec par exemple : {Domain}.{ccTLD} ->  vibix.eu, vibix.asia, vibix.africa, vibix.lat...
que les liens vers les actifs soit dynamique par exemple : cdn.{Domain}.{ccTLD} -> cdn.vibix.eu, cdn.vibix.asia, cdn.vibix.africa, cdn.vibix.lat...  
Mth2 : CDN Dynamique

afin de permettre au cdn.{Domain}.{TLD} de toujours etre le plus pres des end_user, il est nécessaire d'utiliser un reverse-proxy en amont du CDN, afin de déterminer la source la proche
Il suffira ensuite de travailler le rendu de ce tutos et l'entrer dans un worflow de déploiement sur X instances.

 

 

 

 

Mis en Place

Si vous utilisez une machine Debian, vous n'avez besoin que de cette commande :

 

Choisissez un dossier dans lequel vous souhaitez placer votre dossier de ressources : (/var/www/{Domain}.{ccTLD}/httpdocs/assets/). Ensuite, vous pouvez pointer Nginx vers celui-ci. Créez un fichier de configuration Nginx :

Et ajoutez ces paramètres :

Assurez-vous également de créer un lien symbolique dans le sites-enabled dossier.

Redémarrer, et cela devrait etre bon :D


 *** CDN : (Content Distribution Network) réseau de distribution de contenue
 *** ccTLD :  (country-code Top-Level Domains) domaines nationaux ou géographiques

Pourquoi un cache proxy ?

Un proxy de mise en cache est sans aucun doute plus cher qu'un serveur proxy pur. Une capacité de disque nettement plus grande, plus de mémoire et, si nécessaire, un processeur plus puissant sont nécessaires.

Les arguments suivants peuvent néanmoins justifier ces investissements :

• Accélération
  Étant donné que la route proxy -- client est généralement plus courte que la route web serveur -- client, les temps de réponse du proxy à partir de son propre cache sont généralement nettement plus courts. En dehors des serveurs Web du réseau local, selon la distance et la connexion au serveur Web, le temps de réponse du cache peut être de manière réaliste 2 à 100 fois plus rapide que l'accès direct.
• Bande passante
  Étant donné que les données sont stockées dans le cache, de nombreuses requêtes adressées au serveur cible deviennent superflues. Le proxy fournit la réponse à partir du cache au lieu de la récupérer via une connexion (externe). Le trafic entre le proxy et le client est inchangé, mais la connexion du proxy au serveur Web peut être considérablement soulagée. Les économies réalistes de bande passante sont - selon le comportement d'utilisation - d'environ 20 à 50 %.
• Disponibilité
  En cas de connexions non sécurisées ou de mauvaise disponibilité des serveurs web externes, un serveur proxy peut également entraîner une augmentation de la disponibilité de ce contenu. Une fois qu'un objet a été stocké dans le cache, il peut toujours être livré à partir du cache si la connexion ou le serveur Web externe échoue.

Les coûts supplémentaires généralement assez faibles pour le matériel et la configuration d'un cache proxy sont donc éventuellement plus que compensés par une réduction de la bande passante nécessaire, une accélération de l'accès et, si nécessaire, une plus grande disponibilité.

 

Pourquoi pas de cache proxy ?

Outre les nombreux avantages évidents des proxys de cache, il existe également de bonnes raisons qui s'opposent à un proxy de cache. Dans certains cas, il peut être judicieux de ne pas utiliser de fonction de cache :

• Coût d'un cache
  Comme mentionné ci-dessus, vous avez besoin d'une capacité de stockage appropriée pour un cache, à la fois comme disque dur et dans la mémoire principale. L'exigence de stockage principale de votre proxy augmente proportionnellement à l'espace disque du cache.
• Retards causés par un cache
  Un cache fait gagner du temps dans la plupart des cas, mais la recherche d'un objet dans un cache (composite) lui-même demande du temps, qui augmente avec la taille du cache. Si vous utilisez uniquement le proxy pour les serveurs Web dans un réseau local avec une bonne bande passante, dans des circonstances très défavorables, cet effet peut même entraîner des temps de réponse légèrement plus longs qu'avec un accès direct.
• Fraîcheur
  La question ''Quelle est la fraîcheur de l'objet que j'ai dans la cache ?'' peut être un argument de poids contre une cache. Tous les objets ne conviennent pas à une cache. Bien que les serveurs proxy modernes excluent en grande partie ces objets du cache ou vérifient régulièrement qu'ils sont à jour, des objets obsolètes peuvent toujours être livrés. S'il est important pour vous de garder toutes les informations à jour, un cache n'est peut-être pas conseillé.
• Questions juridiques
  Les objets demandés par le client sont stockés dans le cache.
  Selon la situation juridique actuelle, des problèmes pourraient survenir dans des domaines tels que le droit d'auteur (pour les publications protégées, la musique, etc.) ou le droit pénal (contenus illégaux tels que la pornographie ou l'extrémisme de droite).