Docker & les serveurs

Pourquoi plusieurs serveurs ?

Faire de la visioconférence temps réel, c’est trois métiers très différents :

• Distribuer les flux — recevoir la caméra de chacun et la renvoyer à tous les autres, avec le moins de retard possible.
• Traverser les réseaux — faire se rejoindre deux machines derrière deux box, deux pare-feux, parfois deux opérateurs.
• Encoder — transformer une composition en fichier ou en flux diffusable.

Aucun logiciel unique ne fait bien les trois. Studio Local assemble donc des briques éprouvées, chacune spécialiste de son métier, et les fait tourner ensemble sur votre machine.

Docker, en deux minutes

Ces serveurs sont des logiciels exigeants : chacun réclame une version précise de ses dépendances, parfois incompatibles entre elles. Les installer directement sur Windows serait un cauchemar de maintenance.

Docker résout ce problème en emballant chaque serveur dans un conteneur : une boîte scellée qui contient le logiciel et tout ce dont il a besoin. La boîte fonctionne à l’identique sur toutes les machines, et n’installe rien dans votre Windows.

Les quatre conteneurs

Studio Local fait tourner exactement quatre conteneurs. Les voici, dans l’ordre d’importance.

1. LiveKit — le distributeur de flux

C’est le cœur. LiveKit est un SFU (Selective Forwarding Unit) : un serveur qui reçoit la vidéo de chaque participant et la redistribue aux autres, sans la décoder ni la ré-encoder.

La plage de ports est volontairement courte — vingt ports au lieu des milliers habituels. La raison est pratique : les box domestiques plafonnent le nombre de redirections automatiques qu’elles acceptent. Vingt ports suffisent largement à une émission, et passent partout.

2. Redis — la mémoire de travail

LiveKit a besoin d’un endroit rapide pour noter qui est connecté, dans quelle session, avec quelles permissions. Redis est une base de données qui garde tout en mémoire vive : les réponses sont quasi instantanées.

Elle est partagée entre LiveKit et le service d’enregistrement, ce qui leur permet de savoir en permanence ce que fait l’autre. Elle écoute sur le port 6379 à l’intérieur du réseau Docker et dispose d’un volume dédié, pour que son état survive à un redémarrage.

3. Coturn — le passe-muraille

C’est le service le plus méconnu, et pourtant celui qui décide si votre invité arrive à se connecter.

Deux machines derrière deux box ne peuvent pas se joindre directement : chacune est cachée derrière une adresse partagée. Il faut une négociation, et parfois un intermédiaire. C’est le rôle de Coturn, qui parle deux protocoles :

Coturn écoute sur 3478 (en UDP et en TCP) et dispose de sa propre plage de relais, 40000-40020.

4. Egress — l’enregistreur

Egress est le service officiel d’extraction de LiveKit. Il rejoint votre session comme un participant invisible, compose la scène, et l’écrit dans un fichier ou l’envoie vers une plateforme.

Il n’expose aucun port : personne ne s’y connecte, c’est lui qui va chercher ce dont il a besoin. Il écrit directement dans votre dossier d’enregistrements, partagé depuis Windows.

Le serveur applicatif

Les quatre conteneurs ne servent qu’au transport. L’application elle-même — l’interface, les scènes, les licences, les jeux — tourne en dehors de Docker, dans un serveur Node.js lancé directement par Studio Local.

Pourquoi hors conteneur ? Parce que c’est la partie qui doit toucher Windows : lire vos fichiers, dialoguer avec les composants de capture, piloter l’encodeur matériel. Un conteneur est justement conçu pour ne pas pouvoir faire cela.

La vue d’ensemble

Navigateur (vous)              Navigateur (invité, ailleurs)
        │                                   │
        └──────────────┬────────────────────┘
                       │  HTTPS
                 ┌─────▼─────┐
                 │   Caddy   │  ports 80 / 443
                 └─────┬─────┘
            ┌──────────┴──────────┐
            │                     │
    ┌───────▼───────┐     ┌───────▼───────┐
    │  Node.js      │     │   LiveKit     │  ← SFU
    │  :3000        │     │   :7880       │
    │  l'application│     └───┬───────┬───┘
    └───────┬───────┘         │       │
            │             ┌───▼──┐ ┌──▼─────┐
            │             │Redis │ │ Coturn │
            │             └──────┘ └────────┘
            │                 │
     ┌──────▼──────┐    ┌─────▼─────┐
     │  Encodeur   │    │  Egress   │
     │  GPU        │    │  fichiers │
     │ (hors Docker)│   └───────────┘
     └─────────────┘

     ░░░░ Docker ░░░░  LiveKit · Redis · Coturn · Egress

Le réseau interne

Les quatre conteneurs partagent un réseau privé, avec des adresses fixes plutôt qu’attribuées au hasard.

Ce qui se passe au démarrage

Lancer Studio Local déclenche une séquence ordonnée. Chaque étape est visible dans la fenêtre de démarrage, ce qui permet de voir précisément où ça bloque le cas échéant.

1. Nettoyage — les processus d’une session précédente mal fermée sont arrêtés, et le port de l’application est libéré.
2. Détection réseau — la machine identifie sa propre adresse, puis régénère les fichiers de configuration à partir de modèles. C’est ce qui rend l’installation portable d’une machine à l’autre.
3. Démarrage des conteneurs — Docker lance les quatre services.
4. Attente de LiveKit — le shell attend que le serveur réponde vraiment avant de continuer. Démarrer la suite trop tôt donnerait des scènes incapables de se connecter.
5. Caddy — le point d’entrée HTTPS est lancé s’il ne tourne pas déjà. Voir Caddy & HTTPS.
6. Serveur applicatif — Node démarre, et le shell interroge son point de santé jusqu’à obtenir une réponse.
7. Ouverture de la fenêtre — l’interface s’affiche seulement une fois la chaîne complète prête.

Les versions sont figées

Aucune image n’est en version « dernière disponible ». Chacune est épinglée à un numéro précis, et les mises à jour sont faites délibérément, après test.

Dans Docker Desktop (onglet Images), c’est visible directement dans la colonne Tag : livekit/livekit-server:v1.12.0, livekit/egress:v1.13.0, redis:7.4.7-alpine3.21 — un numéro précis, jamais latest. C’est aussi l’endroit où confirmer que Docker a bien tiré les images de Studio Local, ou pour libérer de l’espace disque si nécessaire.

Quand Docker pose problème

Ce que cette architecture implique pour vous