CDN Gratuit : utiliser les serveurs frontaux de Google pour créer son Content Data Network
Un CDN (Content Data Network) permet à stocker des données statiques d’un site internet « in the cloud ». Cette méthode offre différents avantages non négligeables :
- Réduction de la bande passante utilisée sur le serveur principal,
- Réduction de la charge processeur sur votre serveur, l’économie peut-être consacrée au traitement des fichiers dynamiques,
- Parallélisation des téléchargements côté client (donc plus rapide),
- Les fichiers statiques sont servis à partir du serveur le plus proche de l’internaute, les « routes » sont donc plus courtes,
- Les entêtes envoyées à partir du CDN sont personnalisables, il est donc possible d’envoyer du contenu sans Cookies (cookieless content) ni autres fioritures.
Bref, pour vous la faire courte, l’utilisation d’un CDN est un bon moyen d’accélérer l’affichage de son site tout en délestant son serveur.
Comment ça marche ?
Le principe est simple, le site web fait appel à votre domaine pour tout ce qui est dynamique et tout le contenu statique est appelé via un (ou plusieurs) domaine(s) dédié(s). Votre site utilise donc au moins 2 types d’url : www.mondomaine.ext et www.monCDN.ext.
Bien entendu, il est tout à fait possible de personnaliser l’url du domaine afin d’obtenir une adresse du type monCDN.mondomaine.ext, du coup, on ne touche pas au référencement et on n’en fout pas partout.
Dans la pratique, on peut se dire qu’il va falloir publier le contenu statique d’un côté, et le dynamique de l’autre. Ce pourrait être le cas, mais avec CirruxCache notamment (on y vient, on y vient) le principe est beaucoup plus simple :
- Vous appelez une image sur le domaine du CDN : www.monCDN.ext/mon-image.png.
- Soit cette image est présente sur le CDN est elle est envoyée directement au navigateur client,
- Soit c’est la première fois qu’elle est appelée et le CDN va récupérer l’image sur votre serveur principal, la stocke, et la diffuse.
Bien entendu, des tâches automatiques nettoient régulièrement le CDN de manière à ne pas diffuser de contenu périmé. En gros le plus dur consiste à répartir les URL entre le serveur principal et le CDN, le reste se gère tout seul.
Les préparatifs
- Si vous n’en possédez pas encore, créez vous un compte gratuit sur Google Apps Engine.
- Ensuite, il faut créer une nouvelle application dans son compte App Engine. Donnez lui un nom et un titre. Dans les options de stockage « Storage Options (Advanced) » cochez l’option « High Replication ».
Le « réceptacle » pour notre application App Engine est créé, maintenant, on passe à l’application en elle-même.
- Téléchargez et installez (en autorisant la création de liens symboliques sur Linux ou Mac) le Google App Engine SDK pour Python.
- Téléchargez ensuite le dernier package de CirruxCache et décompressez le dans un coin.
- Lancez GoogleAppEngineLauncher que vous venez d’installer avec le SDK pour Python et créez une nouvelle application.
- Faites pointer l’application vers le répertoire de CirruxCache, mais surtout, ne donnez pas de nom à votre application au risque de créer un sous-répertoire ou d’écraser les fichiers de config déjà présents. On enregistre.
Configuration du fichier app.yaml
Cliquez ensuite sur le gros bouton « Edit » pour paramétrer votre appli (ou aller chercher le fichier app.yaml à la racine de CirruxCache) et remplacez la ligne
application: appnamepour lui donner le nom de votre application.
application: test-sltOn enregistre et ce sera tout pour ce fichier (trop dur j’vous dis).
Configuration du fichier config.py
Ouvrez le fichier config.py qui se trouve, lui aussi, à la racine de votre répertoire CirruxCache, via votre éditeur de sources habituel. C’est la partie la plus sensible du truc. Mais rien d’extraordinaire non plus hein 😉
# EDIT BELOW
urls['default'] = (
#'(/debug/.*)', 'Debug',
'(/data/.*)', 'config.Static',
'/www(/.*)', 'config.Www'
)
# POP definition
# You can define and configure your Point Of Presence
class Static(cache.Service):
origin = 'http://static.mydomain.tld'
maxTTL = 2592000 # 1 month
ignoreQueryString = True
class Www(cache.Service):
origin = 'http://www.mydomain.tld'
allowFlushFrom = ['127.0.0.1']
forceTTL = 3600 # 1 hour
ignoreQueryString = True
forwardPost = False
Ce fichier est composé de deux parties. La première est une liste d’URL associée à une liste de fonctions. Selon l’URL appelée, on exécute telle ou telle fonction (dans notre cas, soit du cache, soit du redirect). Vous trouverez la liste des fonctions et leurs paramètres dans la doc de CirruxCache.
Dans mon cas, je suis sous WordPress, donc mes fichiers statiques sont dans /wp-content/ et dans /wp-includes/. Pour le reste, ce ne sera pas géré par le CDN.
Je vais donc configurer deux types de services : d’une part un cache pour tout ce qui est appelé sur les deux répertoires définis, et du redirect pour tout le reste.
Dans d’autres cas de figure, on aurait très bien pu imaginer un répertoire /images/, un répertoire /css/ et un répertoire /js/ par exemple. On aurait alors eu 4 URL renvoyant pour 3 d’entre-elles sur du cache, et pour les autres vers le site.
Un petit exemple valant mieux qu’un long discours, voici mon fichier de config actuel :
# EDIT BELOW
urls['default'] = (
'(/wp-content/.*)', 'config.Static',
'(/wp-includes/.*)', 'config.Static',
'/(.*)', 'config.Www'
)
# POP definition
# You can define and configure your Point Of Presence
class Www(redirect.Service):
origin = 'https://www.souslestoits.net'
class Static(cache.Service):
origin = 'https://www.souslestoits.net'
forceTTL = 2592000 # 1 month
allowFlushFrom = ['127.0.0.1']
ignoreQueryString = True
forwardPost = False
headerBlacklist = ['Set-Cookie']
Vous noterez au passage que pour tout ce qui touche au cache, je vire le header concernant les cookies. On en a pas besoin puisqu’il s’agit de fichiers statiques et on économise un brin de bande passante. Cette ligne n’est pas impérative. Si vous appelez votre CDN sur un nom de domaine différent du site, aucun soucis. Dans mon cas, j’ai préféré l’appeler sur un sous domaine, donc les cookies du domaines ont tendance à se propager.
Tester son CDN
Une fois ces config faites, nous sommes prêts pour lancer l’application. On va tout de même tester avant. Il suffit de cliquer sur le bouton vert « Run » et l’application tourne alors en local sur l’ordinateur.
En vous rendant sur https://www.souslestoits.net:8080/ (le numéro du port est indiqué sur votre GoogleAppEngineLauncher), on doit obtenir une ligne du type :
CirruxCache (0.4.1) / http://code.google.com/p/cirruxcache/Si c’est le cas, on appelle une image ou un fichier statique concerné par le CDN en remplaçant le nom de domaine par notre https://www.souslestoits.net:8080/. Dans mon cas, ça donne ça :
https://www.souslestoits.net:8081/wp-content/uploads/2011/01/xubuntu_logo1.pngMon image s’affiche, j’ai réussi mon coup, mon CDN est prêt à être déployé.
Roule ma poule !
Pour le déploiement, c’est très compliqué : il faut cliquer sur le bouton bleu « Deploy » et rentrer les identifiants et mots de passe de son compte Google.
Un nouveau test sur l’application en production en remplaçant cette fois le https://www.souslestoits.net:8080/ par http://leNomDeVotreApplication.appspot.com et le tour est joué.
http://test-slt.appspot.com/wp-content/uploads/2011/01/xubuntu_logo1.pngFaire pointer votre application Google App Engine vers un sous-domaine
On peut en rester là. Appeler d’un côté les fichiers statiques sur http://leNomDeVotreApplication.appspot.com et le reste sur http://mondomaine.ext. Perso, je trouve intéressant d’utiliser un sous domaine pour mon CDN.
Pour ce faire, il vous faudra passer votre domaine sur Google Apps. C’est gratuit jusqu’à 50 utilisateurs et, si c’est juste pour faire pointer votre sous-domaine, vous n’aurez besoin que d’un utilisateur.
Au niveau de votre compte Google App Engine, dans « Application Settings » vous trouverez la rubrique « Domain Setup » qui vous permettra d’ajouter un domaine déjà passé sur Google Apps. Saisissez votre nom de domaine et validez les conditions d’utilisation.
Il faudra ensuite retourner dans l’interface de Google Apps où vous trouverez maintenant votre application dans les « paramètres du service ». On peut maintenant ajouter un sous-domaine. Google sera alors fin-prêt pour recevoir les appels faits sur cette URL.
La seconde phase consiste à faire pointer ce sous-domaine vers les serveurs de Google afin qu’il serve votre App. Cette étape là se passera chez votre hébergeur, dans la zone DNS.
Il vous faudra personnaliser un CNAME vers les serveur Google : ghs.google.com. Attention, le temps de propagation des DNS peut aller jusqu’à 72h, donc une fois fait, ça peut prendre un peu de temps avant que ça ne soit visible…
Et pour la gestion des URL du site alors ?
Si vous êtes sur une architecture propre, le plus simple à mettre en place reste les répertoires dédiés aux CSS, aux images de design et autres JavaScripts.
Pour les CMS, il existe le plus souvent des plugins ou des configurations qui permettent de rediriger facilement les images vers un CDN. Pour DotClear, il existe un plugin développé par Julien Murdy.
Personnellement, sur WordPress, j’ai choisi d’utiliser W3 TotalCache de W3Edge que je trouve très bien ficelé à plus d’un titre.
En guise de conclusion
La méthode a l’air un peu longue vue comme ça, mais c’est essentiellement parce que j’ai voulu détailler un max. Honnêtement, le tout se fait à peu près en une heure en tâtonnant un peu.
Google impose quelques limitations à l’utilisation de Google Apps, notamment au travers de quotas (au delà, l’utilisation est payante). J’attire votre attention sur le fait que les quotas sont quotidiens et non pas mensuels comme on a l’habitude de le voir. Donc du coup, ça peut tout de même supporter une sacrée charge.
Amusez vous bien ! Le premier qui coince laisse un commentaire 😉
[…] [Source] et [Source] Cet article a été écrit par Jowy, posté le 29 mars 2011 à 12:57 et […]
[…] Network) gratuit, utilisable par WordPress muni de l’extension W3 Total Cache, entre autre:http://www.souslestoits.net/cdn-gratuit-utiliser-les-serveurs-frontaux-de-google-pour-creer-son-cont…Merci à Serge Bregliano pour son article assez détaillé ! Categories: Uncategorized | Permalink […]
[…] Network) gratuit, utilisable par WordPress muni de l’extension W3 Total Cache, entre autre:http://www.souslestoits.net/cdn-gratuit-utiliser-les-serveurs-frontaux-de-google-pour-creer-son-cont…Merci à Serge Bregliano pour son article assez détaillé ! Categories: Uncategorized | Permalink […]
[…] de manière efficace quel que soit le pays d’appel. J’ai déjà parlé des nombreux avantages des CDN dans un billet précédent (et je n’ai pas changé […]