Développer avec Fastly en local

Fastly est un service de CDN (Content Delivery Network) en SaaS (Software as a Service) qui permet la mise en cache de votre contenu web tout autour du monde grâce à des dizaines de points d’accès répartis à travers le globe. Grâce à ce type de service, même si votre contenu n’est servi que depuis un seul data-center, les différents points d’accès de Fastly permettent de servir votre cache contenu au plus près de vos utilisateurs.

De même, si votre contenu n’est pas encore en cache ou qu’il ne peut pas l’être, Fastly permet tout de même un gain de latence global grâce aux peering publics et privés de son réseau. Cependant, le grand atout de Fastly réside dans son architecture technologique. En effet, il utilise une version customisée de Varnish 2 comme brique de mise en cache. Et il permet surtout de fournir vos propres fichiers VCL (fichier de configuration de Varnish) pour contrôler finement le comportement de la mise en cache.

Mais cela ne s’arrête pas là. Fastly a continué de développer sa propre version de Varnish pour intégrer une bonne partie des avancées qu’a connues Varnish depuis la version 2. En plus des fonctions natives de Varnish comme le support des ESI (Edge Side Include), ce qui permet de découper une page HTML en plusieurs appels serveurs et de la rendre en un seul morceau, Fastly a ajouté à sa version des fonctionnalités telles que la cryptographie. Cette fonctionnalité peut par exemple permettre de valider l’identité d’un utilisateur sans faire du tout appel à votre serveur.

Un problème se pose cependant si l’on souhaite utiliser ces fonctionnalités ajoutées dans la version de Fastly. La version Open Source de Varnish 2 ne comprend pas ces fonctionnalités et Fastly ne propose pas de télécharger leur version de Varnish. Il devient donc complexe de reproduire en phase de développement les fonctionnalités offertes par Fastly dans un environnement de production.

Nous pourrions en faire abstraction et ne pas les utiliser. Cependant, ces fonctions peuvent s’avérer très précieuses. Dans le cadre de l’un de nos projets, nous avons été amenés à travailler avec Fastly pour fabriquer du cache pour des utilisateurs anonymes et authentifiés. C’est donc l’histoire que je vais vous raconter ici.

L’environnement de développement

Notre première approche lors du démarrage de ce projet a été de créer une stack technique pour le développement local. Nous avons remplacé le service Fastly par un serveur Varnish 2 Open Source, la version développée par Fastly n’étant pas disponible en téléchargement. Les débuts ont été prometteurs, les VCL que nous fabriquions avaient très peu de différences entre la version locale et les versions de recette et de production.

Assez rapidement, nous avons mis en place un système pour « templater » le VCL pour se baser sur les configurations de l’environnement. Ainsi, cela nous évitait de maintenir plusieurs fichiers VCL différents, ce qui nous aurait amené à faire des erreurs, des oublis de report de configurations entre les fichiers, etc. Cela fonctionnait très bien jusqu’au moment où l’on a commencé à utiliser notre première fonctionnalité avancée disponible uniquement dans la version Fastly de Varnish.

Les fonctions cryptographiques de Fastly nous ont permis, à l’aide d’un cookie de session JWT (JSON Web Token), de valider directement dès Varnish l’authenticité de l’identité d’un utilisateur connecté. Elle nous ont également permis de fabriquer facilement le cache en fonction de l’état, connecté ou non, de l’utilisateur. Cela aurait été bien plus complexe à mettre en place sans cette fonctionnalité.

Nous étions malgré tout face au problème que nous avions peur de rencontrer : devoir simuler une fonctionnalité présente dans Fastly, mais pas sur notre stack de développement. Nous avons donc commencé à voir fleurir dans notre template de VCL des bouts de configuration réservés à l’un ou l’autre des environnements.

Nous gardions un tronc commun qui permettait d’avoir la même structure et « globalement » le même comportement sur tous les environnements, mais certaines portions de la configuration VCL avaient une implémentation très différente selon si l’on était en local ou en recette/production. Par exemple, dans la version locale de notre VCL, nous avons dû ajouter un bout de programme en langage C pour émuler la fonctionnalité native de Fastly. Nous parlons ici d’émulation car cela aurait été difficile de reproduire exactement le même comportement qu’avec Fastly, cela induit donc de potentiels divergences sur des cas à la marge.

Nous avions ainsi vu assez rapidement les limitations de notre solution. L’ajout de nouvelles règles dans le VCL de Varnish s’accompagnait le plus souvent de petites, mais parfois de grosses, adaptations pour fonctionner sur l’ensemble des environnements. Il nous fallait donc trouver une meilleure solution pour nous permettre de développer notre projet de façon plus pérenne et avoir une meilleure reproductibilité entre l’environnement de développement local et les environnements de recette et de production.

Fastly dans notre environnement de développement

Pour pallier ces problèmes et nous permettre d’utiliser pleinement les améliorations de la version Fastly de Varnish, ils nous est apparu qu’il serait peut-être plus efficace de ne pas essayer d’émuler Fastly, mais de l’utiliser directement dans notre environnement de développement. La question restait de savoir comment.

Nos environnements de développement étant inaccessibles depuis l’extérieur du réseau de l’entreprise, nous devions trouver un moyen pour exposer notre serveur web de développement à Fastly, pour nous permettre d’utiliser Fastly en direct. Cette contrainte a été résolue à l’aide d’un autre service SaaS à savoir Ngrok. Ce service permet de créer un tunnel entre votre serveur web et l’extérieur en mettant en place une URL accessible depuis Internet.

Ngrok dispose de plans gratuits et payants en fonction de vos besoins. À partir de $5 par mois et par utilisateur il est possible d’avoir des noms de domaines fixes (le plan gratuit n’offre pas cette possibilité). Cette fonctionnalité permet d’éviter de devoir changer la configuration de Fastly à chaque redémarrage du tunnel.

Il est aussi possible de contourner la limitation du plan gratuit de Ngrok programmatiquement. Les 2 services proposent des APIs pour consulter et modifier la configuration de leurs services. Ainsi, il est possible de modifier la configuration de Fastly à chaque redémarrage du tunnel Ngrok.

Pour permettre aux développeurs d’avoir un environnement de développement stable, il est nécessaire de définir un domaine Fastly ainsi qu’un espace Ngrok reservé par développeur. Ainsi, chaque développeur peut effectuer les modifications nécessaires pour son travail, sans interférer avec les autres développeurs. Des procédures ont aussi été mises en place pour faciliter le démarrage de l’environnement de développement ainsi que la mise à jour de la configuration de Fastly.

Une fois ce processus de développement mis en place, nous avons pu réduire drastiquement les cas particuliers que nous avions, en fonction des environnements. Nous avons aussi pu utiliser pleinement les fonctionnalités avancées de Fastly, sans se restreindre à cause de l’environnement de développement.

Récapitulatif : les plus et les moins

Nous allons tout d’abord commencer par les avantages d’utiliser Fastly en local:

• Homogénéiser la configuration des différents environnements,
• Permettre d’utiliser les fonctionnalités avancées de Fastly sans retenue,
• Faciliter la compréhension globale du projet,
• Faciliter les investigations de débogage.

Et maintenant les moins :

• Mise en place initiale plus longue,
• Création d’un nouvel environnement (Fastly / Ngrok) pour chaque développeur,
• Surcoûts liés à l’utilisation de ces services,
• Impossibilité de développer hors connexion.

Pour ce dernier point, nous avions déjà d’autres services en SaaS, en plus de Fastly, utilisés pour ce projet en développement. Nous avions donc déjà cette contrainte avant ce changement technique.

Fastly est un bon service SaaS qui permet une personnalisation très poussée de sa mise en cache. Mais la mise en place d’un environnement de développement stable et proche de l’environnement de production n’est pas d’un accès direct et facile. Il faut recourir à des moyens détournés pour mettre en place un environnement de développement confortable et pérenne. Nous avons trouvé cela plutôt dommage après coup, au vu de la qualité du service par ailleurs.