CirruxCache permet d'utiliser la plate-forme Google App Engine comme un CDN. Ce projet est né de l'idée de réduire les coûts d'utilisation de la bande passante chez un fournisseur CDN professionnel. Les coûts d'utilisation d'App Engine n'étant pas excessifs. Cependant, un compte App Engine gratuit suffit amplement à une utilisation pour un blog personnel (sauf si vous vous appelez Korben ;-).
CirruxCache est utilisé en production notamment par la société Zoomorama. CirruxCache implémente aujourd'hui de nombreuses fonctionnalités souvent utilisés par les solutions de CDN professionnels, parmi lesquelles : gestion du TTL à partir du Cache-Control, configuration précise des points de présence (en fonction d'une base URL ou d'un virtual host), extensibilité (développement de WebServices sous forme de "module"), etc.
Vous trouverez une liste exhaustive, ainsi que de la documentation, sur le site officiel du projet.
Aller plus loin
- Site officiel (35 clics)
- Actualités CirruxCache sur le blog de l'auteur (21 clics)
- Overview of a CDN-like killer application (34 clics)
- Zoomorama (21 clics)
- Définition d'un CDN (15 clics)
# Répartition Géographique ?
Posté par lrbabe . Évalué à 2.
Je n'ai jamais vu une seule preuve que c'était effectivement le cas. Si vous en avez une je suis preneur.
Et si ce n'est pas le cas, un sous domaine static.example.com avec un un serveur léger du genre ngnx ou lighttpd ne ferait-il pas tout aussi bien l'affaire ?
[^] # Re: Répartition Géographique ?
Posté par Samuel Alba . Évalué à 2.
Je vous invite à lire les liens à la fin de l'article pour mieux comprendre l'intérêt d'un cloud provider comme Appengine pour ce genre d'application. Ainsi vous comprendrez comment la donnée est localisée géographiquement.
[^] # Re: Répartition Géographique ?
Posté par lrbabe . Évalué à 6.
Le fait que l'architecture de Google soit généralement géographiquement distribuée ne constitue pas une preuve que les applications sur App Engine le soit.
[^] # Re: Répartition Géographique ?
Posté par madmaker . Évalué à 3.
je commence à travailler sur les techno de cloud.
j'ai pu m'apercevoir que quelque soit l'application appspot que tu traceroute ca retombe toujours dans le meme datacenter en californie. apres c'est vrai, je sais pas si c'est forwarder autre part ( le nom de domaine ne fait pas tout dans ces solutions) ...
bref comme le dit lrbabe "ca reste a prouver" (en s'y mettant dedans jusque au cou ^^)
mais GAE est deja une solution SaaS il devrait deja regler ce genre de techno sur leur solution !
par contre, chez Amazon il affiche clairement la couleur. tu choisie l'endroit de ton cloud (plusieurs datacenter par continent) et tu peux gérer toi meme ce CDN ... et la c'est normal c'est une solution IaaS/PaaS. (je parle d'amazon car avec AppScale tu pourrais réintegrer ce CDN sur EC2)
[^] # Re: Répartition Géographique ?
Posté par fcartegnie . Évalué à 2.
[^] # Re: Répartition Géographique ?
Posté par herodiade . Évalué à 1.
A moins que les applis hébergées chez google apps utilisent leurs DNS (auquel cas ils peuvent faire effectivement de l'anycast sur leurs serveurs DNS, comme ils font pour d'ailleurs pour leurs 8.8.8.8 et 8.8.4.4, et dispatcher à partir de là la résolution géographiquement).
Ce qui me fait douter de la répartition effective, c'est que le récent (et excellent) rapport de panne de Google Apps semble signifier qu'il n'y a que deux datacenters :
https://groups.google.com/group/google-appengine/browse_thre(...)
"The oncall engineer discusses performing a failover to our alternate datacenter"
"the oncall engineer attempts to move all traffic into a read-only state in our alternate datacenter"
etc
Mais ça n'enlève pas grand chose à l'interét de l'appli : celui de pouvoir décharger le service de fichiers statiques vers un hébergeur bon marché et tout de même assez bien connecté, quand bien même il ne serait pas particulièrement physiquement proche des utilisateurs finaux.
Aux développeurs: est-ce que le support de ESI est prévu ?
[^] # Re: Répartition Géographique ?
Posté par Samuel Alba . Évalué à 2.
Intéressant comme suggestion. Ça n'est pas prévu pour le moment mais je vais me pencher sur la question.
# Pub indirecte pour la boîte de l'auteur
Posté par fcartegnie . Évalué à -1.
dans les liens (qui n'apporte absolument rien à l'article),
et sur la page du projet (normal): ça fait un peu beaucoup.
[^] # Re: Pub indirecte pour la boîte de l'auteur
Posté par dmp . Évalué à 10.
Pour clarification, je suis le manager de l'auteur (dans la société dont je ne répéterais pas le nom afin de ne pas lui faire plus de pub indirecte :-)).
C'est moi qui ai pris la décision il y a quelques mois d'open-sourcer CirruxCache, ET d'en céder la propriété intellectuelle à Sam.
Je ne l'ai pas fait pour faire de la pub à notre boîte, mais parce que je pense que cette application pourrait être utile à d'autres et qu'elle présente un intérêt qui dépasse notre seul usage.
Le fait que Sam indique la provenance et l'usage actuel de l'appli relève pour moi:
1. de la courtoisie la plus élémentaire de sa part
2. de la promotion de *CirruxCache* (et non de la société en question)
J'espère que cela clarifie les choses et répond à votre question.
Quant à la pertinence des liens et ce qu'ils apportent (ou non) à l'article (en particulier les blog-posts), je suppose que les lecteurs sont seuls juges - il me semble à moi intéressant de fournir un peu de matière sur le sujet CDN.
[^] # Re: Pub indirecte pour la boîte de l'auteur
Posté par fcartegnie . Évalué à -1.
Quand on poste un news redhat, on donne le lien de la page projet, pas redhat.com/. Pareil pour ubuntu, on link vers la page projet, pas vers canonical.
[^] # Re: Pub indirecte pour la boîte de l'auteur
Posté par Elfir3 . Évalué à 5.
# Corps benne
Posté par hugo (site web personnel) . Évalué à -10.
- Ca n'apporte rien
- Ca lui fait de la pub et y'en a bien assez sur son site.
- Et puis c'est nul
ps: desole, j'ai perdu mes accents
[^] # Re: Corps benne
Posté par fcartegnie . Évalué à 3.
Il y a une différence entre mentionner un projet open source d'une société, et un communiqué de presse sur la release d'un projet.
# Utilité d'un tel cache sur les applis dynamiques ?
Posté par gUI (Mastodon) . Évalué à 3.
Merci pour les pécisions (-:
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Utilité d'un tel cache sur les applis dynamiques ?
Posté par fcartegnie . Évalué à 2.
Ca ne concerne que les contenus statiques, a moins qu'ils soient générés par du dynamique.
Mais même dans ce cas, la règle des outils de cache (squid...) est de ne pas retourner de résultat caché pour toute requête qui apparaît dynamique (id de session, paramètres d'url ...).
[^] # Re: Utilité d'un tel cache sur les applis dynamiques ?
Posté par djj (site web personnel) . Évalué à 1.
[^] # Re: Utilité d'un tel cache sur les applis dynamiques ?
Posté par zaurus (site web personnel) . Évalué à 1.
jusqu'a peu, quand le JT de France 2 etait encore visionnable sous Linux, je voyais leur nom dans le debut de l'URL de la video.
[^] # Re: Utilité d'un tel cache sur les applis dynamiques ?
Posté par jve (site web personnel) . Évalué à 4.
[^] # Re: Utilité d'un tel cache sur les applis dynamiques ?
Posté par fcartegnie . Évalué à 1.
http://linuxfr.org/~zaurus/
A voir si c'est qq'un qui le fait exprès.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.