Construire une solution de vidéoconférence avec Scaleway et Jitsi

Face à la crise de la Covid-19, les équipes de Scaleway se sont mobilisées mi-mars pour mettre en place une solution de vidéoconférence complète baptisée Ensemble. Proposé gratuitement sur notre cloud souverain, ce service basé sur le logiciel open source Jitsi a été disponible pendant toute la durée du confinement puis du déconfinement en France. En trois mois, il a permis à des dizaines de milliers de personnes d’échanger malgré la distance pour discuter, travailler et collaborer.

Aujourd’hui, malgré le progressif retour à la normale de nos activités, le télétravail reste incontournable. Malheureusement, il est souvent difficile de s’assurer de la confidentialité de nos échanges lorsqu’ils transitent par des services externalisés. C’est pourquoi, en tant que plateforme cloud alternative, européenne et ouverte, il est important de vous détailler la solution que nous avons mise en place afin que vous puissez créer votre propre solution de vidéoconférence.

Le fonctionnement en bref

Le site ensemble.scaleway.com a été conçu comme un portail d’entrée. Il a permis de rediriger les visiteurs vers différentes instances cloud sur lesquelles tournaient des serveurs Jitsi. Afin d’assurer une qualité de service constante, la redirection s’est fait selon la charge de chacune des instances. Chaque visiteur se voyait proposer l’instance la moins utilisée pour créer une salle virtuelle et lancer un appel.

Pour identifier l’instance la moins utilisée, une API récupèrait toutes les 30 secondes la liste des serveurs Jitsi disponibles et leur charge via un monitoring basé sur Prometheus.

Voyons maintenant comment a été déployée cette infrastructure en utilisant nos produits et outils pour les développeurs.

Le module Terraform

Terraform est un service d’infrastructure as code qui permet d’automatiser le déploiement d’une infrastructure au moyen d’un fichier de configuration quelque soit la plateforme que vous utilisez. L’outil est compatible avec Scaleway pour favoriser les usages multicloud et nous l’avons utilisé pour gérer toutes les ressources dont nous avions besoin.

Tous les changements apportés au fichier de configuration ont été stockés dans un dépôt Git et pour gérer l’exécution simultanée de plusieurs Terraform, l’état a été stocké dans une base de donnée PostgreSQL grâce à Scaleway Database. Pour cela, nous avons utilisé le backend Terraform [pg]

Les instances nécessaires

Plusieurs types d’instances ont été nécessaires pour faire fonctionner cette application :

• Les plus importantes sont les serveurs Jitsi. Nous en avons créé plus d’une centaine en utilisant des DEV1-L.
• L’instance faisant tourner Prometheus. C’est elle qui a veillé sur l’état de chaque Jitsi et en particulier l’utilisation du processeur de chaque serveur.
• Les deux instances qui ont exécuté l’API. Elles interrogeaient Prometheus pour lister l’utilisation du processeur de tous les serveurs Jitsi afin de les renvoyer à l’application web.

Les placement groups ont permis d’organiser ces instances par groupes afin d’assurer une disponibilité maximale. Nous avons notamment utilisé le mode max_availability sur nos deux serveurs d’API afin qu’ils ne soient pas situés sur le même hyperviseur. En cas d’incident sur une machine, la deuxième instance était ainsi toujours disponible.

Par ailleurs, nous avons utilisé les security groups pour filtrer les connexions aux serveurs. Sur les instances de l’API, nous n’avons ainsi autorisé que les connexions HTTP/HTTPS et l’accès à distance via SSH et sur les instances Jitsi, seuls ont été autorisés le SSH et les ports nécessaires au fonctionnement de l’applications. Tous les autres ont été bloqués.

L’image Jitsi

Lors de la création d’une instance, vous devez sélectionner une image à partir de laquelle sera démarré votre serveur. Les images sont personnalisables et vous pouvez créer la vôtre pour répondre à vos besoins (tutoriel en anglais).

Dans notre cas, nous avons d’abord créé une image qui a servi de point de départ pour toutes les autres. Nous avons démarré une instance avec Ubuntu et y avons installé Docker et un node_exporter utilisé par Prometheus pour remonter la charge du processeur. Nous avons ensuite fait un snapshot de cette instance que nous avons converti en image (cf. tutoriel ci-dessus).

À partir de cette image de base, nous avons créé une image Jitsi en utilisant le docker-compose officiel de l’application. Nous avons juste ajouté un exportateur Nginx Prometheus au fichier pour un monitoring fin.

Lorsqu’une instance démarrait avec cette image, un docker-compose se lançait et le serveur Jitsi conteneurisé se fonctionnait automatiquement.

Notez que nous avons créé l’image de base et l’image Jitsi avec les playbooks Ansible. Cela nous a permis de recréer facilement les images lorsque c’était nécessaire.

Par ailleurs, nous avons créé une image conteneurisée pour rassembler l’application web basée sur React et l’API écrite en Node.js. Cette image était téléchargée depuis un dépôt privé hébergé par Scaleway Container Registry. Cela nous a permis de déployer de nouvelles versions de l’application sans avoir à redémarrer une instance avec une nouvelle image.

Le load balancer

Les load balancers proposés par Scaleway sont des instances hautement disponibles et entièrement managées qui permettent de répartir la charge de travail entre vos différents serveurs. Ils assurent le scaling de vos applications tout en garantissant leur disponibilité continue, même en cas de trafic intense. Ils fournissent une adresse IP publique dédiée et transmettent automatiquement les requêtes à l’un des serveurs de back-end en fonction de la disponibilité de vos ressources.

Dans le cadre de notre solution de vidéoconférence, nous avons utilisé un load balancer pour rediriger les requêtes vers l’un des serveurs API pour fournir aussi vite que possible les informations sur la charge actuelle de chaque serveur Jitsi. Cela nous a permis d’ajouter sans coupure des serveurs API supplémentaires lors des pics de charge et de mettre de côté les instances qui ne répondaient plus aux requêtes suite à une surcharge ou un incident.

Les enregistrements DNS

Enfin, nous voulions gérer l’enregistrement DNS de chacune des instances Jitsi avec une adresse telle que h-5660.ensemble.scaleway.com. Pour cela, nous avons utilisé Scaleway DNS, actuellement en bêta publique. Lors du provisionnement d’un nouveau serveur via Terraform, un nouvel enregistrement DNS était automatiquement généré par API.

Nous avons par ailleurs généré un certificat wildcard pour tous les sous-domaines de ensemble.scaleway.com afin que toutes les connexions soient sécurisées.

Maintenant, c’est à vous

La solution de vidéoconférence que nous venons de vous présenter est robuste et très complète. Elle permet de supporter de milliers de connections simultanées pour peu que les ressources allouées soient proportionnelles aux besoins. Cependant, elle nécessite une certaine expertise technique pour être mise en place. Heureusement, des solutions existent si vous ne vous sentez pas vraiment capable de mettre en place une telle solution.

Vous pouvez contacter notre équipe commerciale au . Ils auront à cœur de vous accompagner dans votre projet et pourront vous mettre en relation avec un intégrateur spécialisé.

Par ailleurs, si vos besoins sont modestes et si vous êtes malgré tout familier avec la gestion d’un serveur, vous pouvez déployer Jitsi sur une unique instance en utilisant Docker. Un tutoriel très détaillé (en anglais) explique la marche à suivre et vous pouvez également être guidé pas à pas grâce à cette vidéo (en français) :

Comment déployer Jitsi Meet sur une instance Scaleway ?

---

Cet article est inspiré de l’article en anglais Building a scalable video conferencing solution in a single day, using Jitsi and Scaleway Elements publié sur notre blog le 19 mars 2020.