Ce billet illustre le déploiement d’un serveur de relais du flux vidéo, que nous appelerons player. Un relais permet de n’avoir qu’une seule connexion vers les serveurs SSTIC tout en servant plusieurs clients. Il permet par exemple :

• de soulager la demande en bande passante des serveurs SSTIC. Heureusement, ce problème ne devrait pas se produire, car suffisamment de bande passante a été provisionné ;
• de permettre à une entreprise d’offrir une diffusion locale, limitant ainsi le nombre de connexions externe et donc sa bande passante disponible vers Internet.

L’opération complète dure moins de 10 minutes.

Bien que ce billet ne présente que le déploiement du relais, le dépôt streaming-infra contient de quoi déployer une infrastructure complète de diffusion de flux vidéo en direct.

La chaîne de diffusion des flux vidéo en direct utilisée pour le SSTIC a préalablement été décrite dans une série de 5 billets :

1. introduction et considérations pour le SSTIC ;
2. l’architecture de streaming ;
3. la chaîne de capture audio/vidéo sur place ;
4. le transcodage des flux en différentes qualités ;
5. les serveurs frontaux accédés par les internautes.

Aperçu

Un transcoder reçoit le flux vidéo à diffuser. Les player fournis par l’association SSTIC récupèrent des versions 1080p, 720p et 540p de ce flux, et les fournissent sur streaming.sstic.org en HTTP, HTTPS et RTMP.

L’objectif est ici d’ajouter un relais qui viendra récupérer ses flux depuis streaming.sstic.org.

Première étape : création du relais

Les rôles Ansibles fournis pour le relais ont été testé sur Debian 10 et Alpine 3.11.

Pour ce billet, nous prendrons pour exemple un déploiement sur un VPS (Serveur dédié virtuel) du fournisseur de Cloud OVH. Cette démarche devrait pouvoir s’adapter facilement à n’importe quel fournisseur de Cloud, ou machine.

Nous demandons donc le déploiement d’un VPS :

• avec la distribution Debian 10, Alpine n’étant pas disponible ;
• avec une clé SSH pour la connexion ultérieure.

Une fois la machine disponible, nous nous assurons d’avoir un compte utilisateur accessible en SSH, capable de lancer des commandes via sudo sans demande de mot de passe. Dans notre exemple, il s’agit directement de l’utilisateur debian (pas d’action supplémentaire requise).

Deuxième étape : provisioning

Nous allons utiliser Ansible pour configurer notre machine player. Il est nécéssaire d’avoir Python installé sur player pour l’utilisation d’Ansible. Il est déjà présent sur notre exemple, mais peut nécéssiter d’être préalablement installé (apk add python sur Alpine).

Il convient ensuite d’installer Ansible sur la machine qui servira au déploiement. La documentation du projet décrit les moyens disponibles (bien souvent, il suffira d’installer la version présente dans les dépôts).

On copie ensuite le projet contenant les rôles :

$ git clone https://gitlab.com/sstic/streaming-infra
$ cd streaming-infra

Il va maintenant falloir adapter la configuration pour notre machine. Dans Ansible, cela peut se faire via l’inventaire.

inventory.cfg:

[player]
player ansible_ssh_private_key_file=/path/to/id_rsa ansible_ssh_user=debian ansible_ssh_host=mon_instance.provider

[player:vars]
player_rtmp_src="rtmp://streaming.sstic.org/hls"

Ici, nous précisons que la source du flux vidéo sera un des sites de la chaîne de diffusion du SSTIC.

Pour un premier déploiement, nous allons donner deux rôles à notre relais : - base : fourni l’installation de composant de base - player : fourni l’interface Web et la mécanique de réception et rediffusion du flux

Ainsi, nous créons un fichier relais.yml:

- hosts: player
  roles:
    - base
    - player
  pre_tasks:
    - ping: ~

Il ne reste alors plus qu’à lancer le déploiement :

$ ansible-playbook -i inventory.cfg relais.yml

Dans notre exemple, le premier déploiement mets 4 minutes, principalement occupées par la compilation de Nginx avec le module RTMP.

Une fois le déploiement terminé, le site devrait être fonctionnel. Rendez-vous sur http://mon_instance.provider.

Aller plus loin

Le déploiement actuel ne fournit aucune règle de filtrage. Il conviendra donc de mettre en place un filtrage, par exemple avec le module iptables d’Ansible.

Une version HTTPS du site peut être déployé via le rôle player. Il suffit pour cela de fournir les variables:

• ssl_fullchain: "path/to/local/fullchain.pem"
• ssl_privkey: "path/to/local/privkey.pem"
• server_name: "streaming.mon_instance.provider"

Le dépôt contient aussi des rôles permettant la surveillance de l’état de santé des machines. La chaîne retenue est : CollectD (sur la machine à surveiller) + InfluxDB + Grafana (sur une machine de collecte et visualisation).

Cela se traduit par l’ajout dans l’inventaire :

...
[player:vars]
collector_ip=mon_collector.provider

[collector]
collector ansible_ssh_private_key_file=/path/to/id_rsa ansible_ssh_user=user ansible_ssh_host=mon_collector.provider

Et dans le playbook:

- hosts: player
  roles:
    - base
    - player
    - monitored
  pre_tasks:
    - ping: ~
- hosts: collector
  roles:
    - base
    - collector
  pre_tasks:
    - ping: ~

Une fois l’ouverture des flux faite (udp/25826 vers le collecteur), il ne reste plus qu’à configurer Grafana. Par défaut, celui-ci écoute sur le port TCP 3000, avec les identifiants admin:admin.

Si nécéssaire, les relais peuvent être chaînés entre eux. Il suffira d’adapter la variable player_rtmp_src.

Le reste du dépôt contient un exemple complet d’architecture, incluant notamment le rôle du transcodeur (chargé de recevoir, d’enregistrer et de redistribuer un flux, en plusieurs qualités). Une version locale peut-être mise en place rapidement via vagrant up (se référencer au README du dépôt pour plus de détails).

Il devrait permettre de monter rapidement une architecture complète de chaîne de diffusion de vidéo en direct.

Dans le cas du SSTIC 2020, l’architecture complète composée d’un transcodeur, de deux relais et d’un serveur de collecte, est re-déployable en moins de 10 minutes.

L’intérêt d’utiliser une approche Infratructure-as-code, outre de pouvoir mettre un mot à la mode dans un billet de blog, est que nous y voyons la possibilité d’avoir une architecture :

• dont les machines n’ont pas ou peu d’historique;
• qui peut être mise en place et détruire à la demande;
• testable / débogable localement;
• dont les changements sont faciles à suivre (git-ifiable).