L’« Application Performance Management » couvre l’ensemble de la démarche visant à monitorer et améliorer la performance des sites et applications web. C’est donc une discipline importante à époque où le temps de chargement trop long d’une page peut ruiner la réputation ou le business d’une marque ou entreprise.

J’ai présenté sitespeed.io, outil de test de la performance des sites web il y a quelques années déjà. Il vous suffit de (re)lire ce billet pour vous rendre compte de tout le bien que j’en pensais à l’époque. Et ça n’a pas changé; bien au contraire vu les nombreuses évolutions positives qu’a connu cet outil depuis.

Je vous propose dans ce qui pourrait être la suite du précédent billet d’automatiser les tests faits avec sitespeed.io et de voir quels sont les possibilités d’intégration dans une chaîne de CI/CD. A partir de là, il devient possible de tester une application ou site web:

  • A la façon GitOps, de façon automatique à la moindre modification du dépôt du code source applicatif.
  • Dans un esprit plus « observabilité, monitoring », ordonnancer des contrôles à intervalles réguliers de l’application.

Quoique ce soit votre préférence, il me paraît important de rappeler que le mode opératoire le plus pratique pour sitespeed.io est basé sur une image Docker et que c’est celui-ci que nous allons utiliser. Cela permet d’envisager l’automatisation des choses suivantes:

  • Démarrage d’un conteneur Docker à partir de l’image officielle sitespeed.io.
  • Exécution du test sitespeed.io dans ce conteneur.
  • Récupération des résultats.
  • Destruction du conteneur Docker.

Configuration de sitespeed.io

Il est possible de configurer sitespeed.io de deux façons différentes:

  • A partir d’options et arguments sur la ligne commande.
  • A partir d’un fichier de configuration au format JSON.

Nous privilégierons la deuxième méthode, le fichier JSON pouvant être facilement généré automatiquement depuis la description, le « blueprint » de l’application.

Configuration pour le CI/CD

La liste des options de configuration de sitespeed.io est juste énorme et je ne compte pas vous les décrire toutes… Heureusement pour tout le monde! Nous allons juste parcourir les quelques options qui me semblent intéressantes à utiliser quand sitespeed.io est « opéré » en mode automatique.

Configuration S3

Il est possible de stocker le rapport HTML généré par sitespeed.io dans un stockage compatible Amazon S3. Cette option est utile si vous souhaitez par exemple que les développeurs puissent avoir accès au détail d’un test réalisé. J’utilise Minio comme stockage compatible S3 et la configuration nécessaire pour que cela fonctionne avec sitespeed.io est la suivante:

« s3 »: { « endpoint »: « http://192.168.1.7:9000 », « bucketname »: « speedio », « removeLocalResult »: true, « key »: « miniouser », « secret »: « miniopassword », « options »: { « s3ForcePathStyle »: true, « s3BucketEndpoint »: true } }

Il est possible d’utiliser le module « Google Cloud Storage » pour arriver à un résultat identique.

Configuration Graphite

Il paraît évident qu’une chaîne de CI/CD sans monitoring n’en est pas vraiment une… Mais ça va toujours mieux en le reprécisant 🙂 Dans ce scope, Graphite reste bien sûr un standard et nous allons donc utiliser le module correspondant pour pouvoir récupérer l’ensemble des métriques récoltées par sitepseedio au cours d’un testGrafana permettra la visualisation des métriques récoltées. Voici la configuration du module Graphite:

« graphite »: { « host »: « 192.168.1.79 », « port »: 9109, « includeQueryParams »: false, « arrayTags »: false, « namespace »: « speedio » },

C’est une configuration minimale pour envoyer les métriques vers un serveur compatible Graphite mais vous pouvez aller beaucoup plus loin avec des tags, des annotations à disposition. Pour ma part, j’utilise plutôt Prometheus que Graphite et j’ai donc utilisé Graphite Exporter et ces possibilités de « mapping » pour arriver au même résultat qu’avec un serveur Graphite. Vous pouvez aussi utiliser InfluxDB en lieu et place de Graphite si tel est votre bon plaisir.

Autres options de configuration intéressantes

Je n’ai pas encore mis en oeuvre les options de configuration suivantes mais il est possible, à l’instar du module Graphite vu plus haut, d’envoyer des annotations vers Grafana. Il est également possible de paramétrer un « budget performance » pour votre application. Et enfin, la toute nouvelle version 12 de sitespeed.io permet désormais de calculer l’impact écologique de votre application web.

Intégration CI/CD

Une fois sitespeed.io configuré, il ne reste plus qu’à orchestrer le tout avec l’outil de votre choix; Ansible dans mon cas. Voici donc un playbook « quick and dirty » permettant de charger la liste des sites à tester depuis un fichier web.txt et de créer le conteneur Docker pour chacun. Notez l’appel au fichier de configuration avec --config config.json. Un script bash aurait certainement pu faire l’affaire mais utiliser Ansible ou un équivalent permet de pouvoir paramétrer le tout finement et d’aller plus loin avec par exemple un fichier de configuration différent par application…

– name: sitespeed.io docker run hosts: localhost connection: local gather_facts: no become: no vars: iso8601_date: « {{ lookup(‘pipe’, ‘date -u +%Y-%m-%dT%H:%M:%S+00:00’) }}«  root_dir: « {{ lookup(‘env’, ‘PWD’) }}«  tasks: – name: docker_container | check url from file ‘web.txt’ with sitespeed.io docker_container: name: « speedio_{{ site_idx }}«  image: sitespeedio/sitespeed.io:12.1.0 auto_remove: yes network_mode: bridge recreate: yes command: « {{ item }} –config config.json » env: https_proxy: «  » http_proxy: «  » volumes: « {{ root_dir }}:/sitespeed.io » loop: « {{ lookup(‘file’, ‘./web.txt’).splitlines() }}«  loop_control: index_var: site_idx

Ceci n’est bien sûr qu’une base Ansible à adapter à votre environnement, votre contexte. Il reste à intégrer ce playbook dans un pipeline CI/CD, que ce soit Jenkins, Gitlab, Github ou Drone. Il est également possible d’exécuter ce playbook à intervalles réguliers depuis Jenkins, Rundeck, AWX ou depuis votre logiciel de supervision.

En fonction de l’intégration choisie, il peut y avoir pas mal de travail annexe à faire comme la construction de tableaux de bord pour Grafana, un fichier de mapping pour Graphite Exporter… En guise de conclusion, les combinaisons envisageables sont très étendues.