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 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:

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

Configuration

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

  • Options et arguments en ligne de commande,
  • 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.

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é. A titre personnel, Minio comme stockage compatible S3 et la configuration nécessaire pour que cela fonctionne avec sitespeed.io est la suivante:

{
   "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 …

Dans ce scope, Graphite reste un standard et nous allons récupérer l’ensemble des métriques récoltées par sitepseedio au cours d’un test. Grafana 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"
}

Il s’agit une configuration minimale pour envoyer les métriques vers un noeud Graphite mais vous pouvez aller beaucoup plus loin avec des tags et des annotations.

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.

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.

D’autre part, il est également possible de paramétrer un « budget performance » pour votre application et depuis la version 12 de sitespeed.io, il est possible de calculer l’impact écologique de votre application web.

Integration CI/CD

Une fois sitespeed.io configuré, il ne reste plus qu’à orchestrer le tout avec l’outil de votre choix. Ansible est mon choix.

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 contexte.

Il reste à intégrer ce playbook dans un pipeline CI/CD, que ce soit Jenkins, Gitlab CI, Github CI ou encore Drone.io.

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.