9 juin 2021 - Le collectif IndieHosters

 Rapide rappel : Jitsi c’est la solution libre de visioconférence que nous intégrons de base dans Liiibre.

Le 7 avril dernier, l’équipe de Jitsi organisait un hackathon destiné à l’enjeu de la visioconférence dans le contexte de l’éducation.

Quelques mois auparavant, nous avons répondu à un appel d’offre d’une université pour faire de la visio avec 1000 étudiants en simultané. L’occasion était alors parfaite pour prendre le temps en équipe de développer une solution répondant à ce cas d’usage mais également pour se rapprocher des contributeur·trice·s qui gravitent autour de Jitsi et puis tout simplement par goût du défi technique.

En attendant une potentielle acceptation de notre proposition, (nous croisons les doigts), nous nous sommes attelés à initier le développement d’une solution visant à faciliter l’auto-scaling d’une instance de visioconférence.

Auto quoi ?

L’auto-scaling, c’est la capacité d’un système à répondre à une demande fluctuante de manière dynamique et automatique.

Plus concrètement, ce n’est pas pareil d’héberger une solution de visioconférence à destination d’une dizaine de personnes ou bien pour 1000 personnes. Là où le premier cas nécessiterait un seul serveur, le second cas nécessite une réflexion en amont plus approfondie puisqu’une telle demande peut rapidement nécessiter plusieurs serveurs. S’ouvre alors plusieurs problématiques liées à leur agencement et à la circulation de l’information entre ces différentes machines.

Or dans le cadre d’une université, le nombre d’étudiant·es qui vont se connecter à l’outil de visio peut grandement fluctuer tout au long de la journée et selon que l’on est en semaine ou le weekend.

Pour répondre à un tel besoin on pourrait donc tenter d’évaluer quelle serait la demande maximale potentielle puis mettre en place l’infrastructure adéquate pour y faire face.

C’est ainsi que l’on opère actuellement, mais on pourrait faire mieux.

En effet, cette méthode consiste à estimer la demande maximale selon un processus empirique composé de phases de test de montée en charge puis optimisation puis on recommence… on fera alors ensuite le choix d’allouer des ressources au plus juste (si on est optimiste) ou d’allouer plus de ressources qu’il n’en faut pour parer à l’éventualité d’un pic occasionnel (si on est plus prudent).

Cette solution reste à la fois risquée si on a visé trop juste ou favorise le gaspillage de ressources, d’énergie et d’argent si on vise plus large que nécessaire.

C’est donc là qu’entre en jeu l’auto-scaling ! Rentrons maintenant dans les détails plus technique pour nos ami·es développeur·euse et administrateur·trices système.

Notre proposition basée sur un opérateur Kubernetes

Vous le savez maintenant depuis notre dernier article sur le sujet, notre infrastructure est basée amplement sur l’api Kubernetes.

Un autre aspect particulièrement élégant de l’API Kubernetes est qu’elle permet de gérer des ressources de manière déclarative. Ces resources, comme le CPU, la mémoire, le stockage et le réseau, etc, sont ainsi manipulables comme des briques de Lego.

Et comme cette API est bien pensée, ça donne envie de la réutiliser et de l’étendre. Voyons comment nous nous y sommes pris pour décrire avec ces briques un cluster Jitsi.

C’est parti !

On commence par créer un CRD ou “custom resource definition” que l’on va appeler “Jitsi”. Cela nous offre un niveau d’abstraction supplémentaire et au lieu de gérer simplement des containers, nous allons pouvoir ainsi manipuler des instances de cluster Jitsi (!)

Cela se fait via un fichier en yaml. Voici à quoi ça ressemble:

apiVersion: apps.jit.si/v1alpha1
kind: Jitsi
metadata:
  name: jitsi-sample
spec:
  domain: hack.liiib.re
  region: europe
  timezone: Europe/Paris
  jvb:
    strategy:
      type: autoscaled
  jibri:
    enabled: true

Pour l’instant il manque encore des possibilité de configuration, mais c’est le début. (Nous parlons ici d’un hackathon de 5 jours, n’est-ce pas )

On peut déjà par exemple agir sur les containers Jibri dédiés au streaming et/ou enregistrement des visioconférences. Comme ces fonctionnalités ne sont pas toujours nécessaires, on peut ainsi désactiver et supprimer ces containers simplement en modifiant la variable jibri dans le fichier de configuration.

Ceci se produit grâce à l’opérateur Kubernetes que nous avons développé. Il traduit ces déclarations en instructions concrètes qui vont permettre le déploiement des ressources : évaluer le nombre de containers nécessaires, à quel version, faire la plomberie pour connecter Internet au Service, demander un certificat pour mettre en place le https et ainsi de suite.

Pour les plus afuté·e·s d’entre vous, nous avons décidé d’utiliser des opérateurs et pas helm car nous préférons manipuler des objets go que de la logique dans du yaml. Rien que ce sujet pourrait faire l’objet d’un article de blog.

Derrière le rideau

On a commencé par cartographier l’architecture envisagée pour le cluster.

Dans le contexte de ce hackathon, notre objectif principal était de déployer un cluster jitsi avec des JVB (Jitsi Video Bridge) connectés en OCTO.

OCTO permet de faire tourner une conférence sur plusieurs JVB en cascade, ce qui aide à fluidifier les flux car ils constituent les goulots d’étranglement du service de visio.

Nous sommes parti de ce que nous avions déjà développé ici en yaml. La première étape consistait donc à transformer cette logique sous forme d’opérateur.

Le deuxieme étape était de le faire auto-scale! Et Kubernetes nous a bien aidé dans cette mission, on pourrait dire que c’est presque tricher car son API possède déjà les primitives pour faire cela. Le seul challenge repose sur le fait que par défaut, Kubernetes scale en se basant sur des metrics comme le CPU, et dans le cadre de jitsi, nous voulions le faire scaler sur des metrics plus proches des contributeurs, plus proche de leur expérience.

Pour ce faire, nous sommes allés voir du côté de ce projet de zalando qui répond précisément à cet enjeu.

Puis nous avons utilisé un HPA, Horizontal Pod Autoscaler tout simplement pour faire le scaling des JVB. C’est-à-dire que si K8s détecte qu’un JVB est “stressé”, il va en ajouté un autre. Un seul suffit pour saturer un noeud, nous avons donc interdit le déploiement de 2 JVB sur le même noeud. Quand les JVB sont stressé et que K8s n’a plus de noeud disponible, le cluster autoscaler, si il est activé, va ajouter des noeuds.

Enfin, lors de nos tests, nous avons réglé le palier de scaling très bas et il suffisait ainsi de rejoindre une conférence pour observer le cluster s’agrandir de lui meme.

Pour aller plus loin

Nous sommes heureux d’avoir pris ce temps pour semer une première graine qui, nous l’espérons, sera utile à nos ami·es des CHATONS qui proposent de la visioconférence.

Nous avions là 5 jours à y consacrer durant ce hackathon et il y a encore pas mal à contribuer pour en faire un opérateur utilisable en production, comme par exemple :

• Enrichir la documentation technique
• Prévoir un downscale gracieux qui éviterait le risque de couper des conférences en cours sur le cluster
• Implémenter des tests automatiques
• Configuration pour CI/CD

Vous pouvez retrouver et contribuer à l’opérateur directement dans le dépôt Github de Jitsi.

Cet opérateur rejoint le projet Libre.sh qui vise à proposer une sorte de distribution kubernetes.

Si vous êtes motivé·e pour contribuer en échange d’une rétribution (car vous ne faites pas partie d’un CHATONS et n’y voyez pas un intérêt direct par exemple) n’hésitez pas à venir en discuter avec nous sur notre chat !

… et on a fini 5ième !

Et pour en revenir au sujet du hackathon, nous avons terminé 5ième et avons ainsi pu bénéficier d’une récompense. On ne s’y attendait pas vraiment pour être honnête et ça nous a fait grandement plaisir.

N’hésitez pas à jeter un oeil aux autres projets qui ont terminé sur le podium, il y a des très belles fonctionnalités en devenir. Autant de promesses qui nous confortent dans l’idée que Jitsi constitue à ce jour une des meilleures solutions libres de visioconférence.