Bunny.Net : Cdn, Load Balancer, Dns, Stockage Et Streaming

Ce que chaque brique fait

Le tableau de bord CDN est le point d'entrée, mais le trafic ne s'arrête pas à une Pull Zone. Chaque produit a un rôle précis.

• Bunny DNS répond aux requêtes du domaine. Le réseau est anycast, en IPv4 et IPv6. On y place le nom qui pointe vers le CDN, les enregistrements mail, et si besoin un équilibrage au niveau DNS.
• Pull Zone (CDN) met en cache ce qui peut l'être au plus près du visiteur. Une réponse déjà en cache ne retourne pas jusqu'à l'origine.
• Load Balancer n'a pas de nom d'hôte propre. C'est une politique de routage rattachée à une ou plusieurs Pull Zones. Il ne voit que les requêtes qui ne sont pas servies par le cache, et les répartit entre plusieurs origines, avec contrôle de santé et bascule.
• Storage garde les fichiers : images, CSS, PDF, exports. Une zone de stockage peut servir d'origine à la Pull Zone, ou de secours si les serveurs applicatifs sont injoignables.
• Stream encode la vidéo en HLS, fournit un lecteur et peut exiger un jeton d'accès. Le serveur Django ou l'API ne transporte plus les flux.

1. Le DNS, avant le CDN

On crée la zone DNS dans Bunny, puis on fait pointer le registrar vers les serveurs de noms Bunny. Deux chemins existent pour migrer : l'import automatique des enregistrements déjà en place, ou l'envoi d'un fichier de zone BIND. On relit chaque ligne avant de changer les NS. Un MX ou un TXT SPF oublié coupe le courrier.

Pour le site, l'enregistrement utile est en général un CNAME du sous-domaine vers le hostname de la Pull Zone, ou l'accélération CDN proposée dans la zone. Le sommet du domaine (exemple.com sans sous-domaine) se traite à part : un CNAME à l'apex n'est pas toujours accepté par le registre, Bunny propose alors un enregistrement adapté ou un ALIAS selon la zone.

Bunny DNS sait aussi équilibrer au niveau des enregistrements : jeux d'enregistrements, poids, routage géographique ou par latence, surveillance de santé. Ce n'est pas le même outil que le Load Balancer du CDN. Le DNS choisit une adresse avant la connexion HTTP. Le Load Balancer choisit une origine après que le visiteur a déjà atteint le edge.

2. La Pull Zone

Dans CDN → Pull Zones, on crée une zone. On lui donne un nom interne, une origine de départ (l'URL HTTPS de l'application), et le hostname public, par exemple cdn.exemple.com. Le certificat est émis sur ce hostname.

Règles que nous appliquons presque toujours :

• Cache long sur /static/, /media/ et les fichiers versionnés (CSS, JS, WebP).
• Pas de cache sur /admin/, les pages de compte, le panier et toute réponse qui dépend d'un cookie de session.
• En-tête Cache-Control explicite côté application. Le CDN respecte une consigne claire mieux qu'une absence de consigne.
• TLS 1.0 et 1.1 désactivés. Redirection HTTP vers HTTPS.
• Optimiseur d'images activé seulement sur les visuels, pour servir WebP ou AVIF sans regénérer les fichiers à la main.

Le cache edge absorbe les pics. L'origine ne voit plus chaque visiteur : elle voit les défauts de cache, les pages dynamiques et les écritures.

3. Le load balancer devant les origines

Le Load Balancer Bunny CDN est disponible en préversion publique. On le crée dans le compte, puis on change le type d'origine de la Pull Zone vers « Load Balancer ». À partir de là, l'URL d'origine unique de la zone n'est plus utilisée : chaque origine du répartiteur porte sa propre destination.

Une origine peut être un serveur HTTPS, une Storage Zone, un Edge Script ou un endpoint Magic Containers. On les range en groupes. Chaque groupe a une priorité, un poids, une méthode d'équilibrage et un contrôle de santé.

Montage type pour une application hébergée en Europe, avec un secours :

1. Groupe principal, priorité 1. Deux serveurs HTTPS dans la même région. Méthode : répartition équitable, ou pondérée si l'un est plus gros.
2. Groupe proche des utilisateurs, priorité 2, seulement si une deuxième région existe vraiment. Méthode géographique ou par latence.
3. Groupe de secours, priorité 3. Une Storage Zone qui sert une page de maintenance statique, ou un second cluster.

Le contrôle de santé retire une origine qui ne répond plus. Le trafic non caché bascule sur le groupe suivant. Les sessions qui doivent rester sur le même serveur utilisent le cookie de persistance chiffré proposé par Bunny. On ne l'active que si l'application n'est pas partageable entre nœuds (fichiers locaux, cache mémoire non partagé). Une application Django derrière un cache et une base communs n'en a en général pas besoin.

Un même Load Balancer peut être attaché à plusieurs Pull Zones. On ne le supprime pas tant qu'une zone l'utilise encore. Les statistiques du tableau de bord montrent la répartition, l'état de chaque origine et les bascules.

4. Storage pour les fichiers

Les images produits, les PDF et les exports n'ont pas leur place sur le disque du VPS applicatif. On crée une Storage Zone, on choisit les régions de réplication (par exemple Allemagne, Royaume-Uni, New York, Singapour), puis on verse les fichiers par l'API HTTP, le FTP ou l'API compatible S3.

Cette zone devient l'origine de la Pull Zone pour les chemins statiques, ou le stockage permanent (Perma-Cache) qui garde une copie même quand l'origine applicative est lente. Le hostname public reste celui du CDN : https://cdn.exemple.com/images/produit.webp. Le navigateur ne parle jamais directement à la zone de stockage.

Côté Django, MEDIA et les fichiers générés partent vers ce stockage. Le HTML ne change que le domaine des URLs. Un backup du VPS n'a plus à contenir des gigaoctets d'images.

5. Stream pour la vidéo

Servir un MP4 depuis Gunicorn ou Nginx sature la bande passante et coupe la lecture dès que le client change de réseau. Bunny Stream prend le fichier source, l'encode en HLS (plusieurs débits), et expose un lecteur.

Parcours habituel :

1. Créer une bibliothèque vidéo.
2. Envoyer le fichier source. L'encodage se fait ensuite, sans worker sur le serveur applicatif.
3. Récupérer l'identifiant et l'URL du lecteur, ou l'URL HLS.
4. Activer l'authentification par jeton si la vidéo n'est pas publique. Le serveur signe une URL courte, le lecteur la consomme, le lien expiré ne marche plus.
5. Optionnel : un hostname dédié, par exemple stream.exemple.com, pour séparer la vidéo du reste du site.

La page de l'article ou du cours ne contient qu'un lecteur. Le poids de la page reste celui du HTML et des images. La vidéo part d'un autre réseau.

Ordre de mise en place

Nous suivons toujours le même ordre, pour pouvoir revenir en arrière à chaque étape.

1. Storage Zone, avec une région principale proche des origines et les réplications utiles.
2. Pull Zone de test sur le hostname Bunny (*.b-cdn.net), le temps de vérifier le cache.
3. Load Balancer, groupes, contrôles de santé, puis bascule du type d'origine de la Pull Zone.
4. Hostname personnalisé et certificat.
5. Zone DNS, relecture des MX et TXT, puis changement des serveurs de noms.
6. Bibliothèque Stream, à part, dès qu'il y a de la vidéo.
7. Mesure : temps de réponse edge, taux de cache, bascules du load balancer. On ne coupe l'ancien serveur qu'après cette lecture.

Ce qui ne doit pas passer par le cache

Mettre toute l'application derrière le CDN sans règles est le piège le plus courant. Une page de compte mise en cache se retrouve affichée au visiteur suivant. On exclut donc :

• tout ce qui lit un cookie de session ou un jeton ;
• les formulaires de paiement et les webhooks ;
• l'administration ;
• les réponses personnalisées (nom, panier, solde).

Le HTML public d'un article, les images, les polices et les feuilles de style, eux, se cachent. C'est là que le gain se mesure.

Sécurité minimale

• Origines joignables uniquement en HTTPS, certificat vérifié.
• Le serveur applicatif n'écoute pas sur l'adresse publique pour le HTTP du site : seul le edge Bunny y accède, filtré par IP d'origine ou par un secret d'en-tête.
• Jetons sur les vidéos privées et sur les fichiers sensibles de la Storage Zone.
• Journaux du CDN avec anonymisation d'IP si le registre des traitements l'exige.
• Pas de clé d'API Bunny dans le dépôt Git. Elle reste dans les variables d'environnement du serveur.

Ce que ça change pour l'hébergement

Le VPS ou le conteneur applicatif redevient petit : Django, l'API, la base. Les fichiers vivent dans Storage, la vidéo dans Stream, le cache et la répartition dans le CDN. Une origine qui tombe ne coupe pas les pages déjà en cache, et le load balancer envoie le reste vers le groupe sain.

Le Load Balancer est encore en préversion publique : on le traite comme tel, avec un groupe de secours testé avant la mise en production, pas comme un équilibrage que l'on découvre le jour d'un incident.

Akamasoft monte cette chaîne pour les sites et les plateformes que nous exploitons : Pull Zone, routage des origines, zone DNS, stockage des médias et bibliothèque vidéo, puis les règles de cache qui empêchent de servir la mauvaise page. La configuration se fait dans le tableau de bord CDN Bunny, et le détail du répartiteur est documenté par Bunny dans Load Balancer et Bunny DNS.