Déploiement Docker et Kubernetes pour Vajra Cast

Déployez Vajra Cast avec Docker, Docker Compose et Kubernetes. Images, manifests, Terraform, scaling et health checks.

Pourquoi conteneuriser votre infrastructure de streaming ?

Les logiciels de streaming live ont traditionnellement été installés directement sur des serveurs bare-metal ou des VM — configurés manuellement, mis à jour manuellement, et difficiles à reproduire. La conteneurisation change la donne en packant Vajra Cast avec toutes ses dépendances dans une image portable et versionnée qui s’exécute à l’identique partout.

Avantages pour les charges de travail streaming :

  • Déploiements reproductibles. La même image s’exécute en développement, staging et production.
  • Rollbacks rapides. Mauvaise mise à jour ? Revenez au tag d’image précédent en quelques secondes.
  • Infrastructure as code. Toute votre configuration de streaming est définie dans des manifests versionnés.
  • Scaling. Lancez des instances supplémentaires pour gérer plus de flux.
  • Isolation. Chaque instance Vajra Cast s’exécute dans son propre conteneur avec des limites de ressources définies.

Image Docker

Vajra Cast est distribué sous forme d’image Docker via un registry privé. Après inscription à l’essai gratuit, vous recevez vos identifiants pour accéder au registry :

docker login registry.vajracast.com
docker pull registry.vajracast.com/vajracast:latest

L’image est basée sur un système Linux minimal et inclut toutes les dépendances requises : bibliothèques FFmpeg, bibliothèque SRT, client PostgreSQL et le binaire Vajra Cast.

Tags d’images

TagDescription
latestVersion stable la plus récente
x.y.zVersion spécifique (ex. 1.5.0)
x.yDernier patch pour une version mineure (ex. 1.5)

Pour la production, fixez toujours un tag de version spécifique. Utiliser latest en production risque des mises à jour non souhaitées.

Docker Compose

Pour les déploiements sur un seul serveur, Docker Compose est le moyen le plus simple d’exécuter Vajra Cast avec PostgreSQL :

# docker-compose.yml
version: "3.8"

services:
  vajracast:
    image: registry.vajracast.com/vajracast:1.5.0
    ports:
      - "8080:8080"       # Interface web et API
      - "9000-9010:9000-9010/udp"  # Ports SRT
      - "1935:1935"       # RTMP
    devices:
      - /dev/dri:/dev/dri  # GPU pour le transcodage matériel
    group_add:
      - video
      - render
    environment:
      DATABASE_URL: postgres://vajracast:changeme@postgres:5432/vajracast
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://localhost:8080/api/health"]
      interval: 10s
      timeout: 5s
      retries: 3

  postgres:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: vajracast
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: vajracast
    healthcheck:
      test: ["CMD-ARGS", "pg_isready", "-U", "vajracast"]
      interval: 5s
      timeout: 3s
      retries: 5
    restart: unless-stopped

volumes:
  pgdata:

Démarrez tout avec :

docker compose up -d

Plages de ports

SRT utilise des ports UDP, et vous avez besoin d’un port par listener SRT. L’exemple ci-dessus expose les ports 9000-9010, vous donnant 11 ports listener SRT. Ajustez la plage en fonction du nombre d’ingests SRT simultanés dont vous avez besoin.

RTMP utilise le port TCP 1935 par défaut. Si vous n’utilisez que SRT, vous pouvez omettre ce port.

Accès GPU

Les sections devices et group_add passent le GPU Intel au conteneur pour le transcodage matériel. Si vous n’utilisez pas le transcodage matériel, vous pouvez omettre ces lignes.

Sur les systèmes sans processeur graphique intégré Intel, supprimez le mapping du périphérique /dev/dri pour éviter les erreurs.

Déploiement Kubernetes

Pour les déploiements multi-serveurs en haute disponibilité, Kubernetes fournit l’orchestration, le scaling et l’auto-réparation.

Manifest de déploiement

# vajracast-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vajracast
  labels:
    app: vajracast
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vajracast
  template:
    metadata:
      labels:
        app: vajracast
    spec:
      containers:
        - name: vajracast
          image: registry.vajracast.com/vajracast:1.5.0
          ports:
            - containerPort: 8080
              name: http
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: vajracast-secrets
                  key: database-url
          resources:
            requests:
              cpu: "1"
              memory: "2Gi"
            limits:
              cpu: "4"
              memory: "8Gi"
              gpu.intel.com/i915: "1"  # Plugin GPU Intel
          livenessProbe:
            httpGet:
              path: /api/health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /api/ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Service pour SRT (UDP)

SRT utilise UDP, ce qui nécessite un service NodePort ou LoadBalancer :

# vajracast-srt-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: vajracast-srt
spec:
  type: NodePort
  selector:
    app: vajracast
  ports:
    - name: srt-9000
      protocol: UDP
      port: 9000
      targetPort: 9000
      nodePort: 30900

Pour les déploiements cloud, utilisez un load balancer compatible UDP (AWS NLB, GCP Network LB) plutôt que NodePort.

Service pour HTTP (interface web, API, métriques)

# vajracast-http-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: vajracast-http
spec:
  type: ClusterIP
  selector:
    app: vajracast
  ports:
    - name: http
      port: 8080
      targetPort: 8080

Exposez via un Ingress controller pour l’accès externe à l’interface web et à l’API.

Secrets

Stockez les identifiants de base de données dans un Secret Kubernetes :

kubectl create secret generic vajracast-secrets \
  --from-literal=database-url='postgres://vajracast:changeme@postgres-service:5432/vajracast'

PostgreSQL dans Kubernetes

Pour les déploiements Kubernetes en production, utilisez un service de base de données managé (AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL) plutôt que d’exécuter PostgreSQL dans le cluster. Cela vous offre des sauvegardes automatiques, la réplication et la maintenance.

Si vous devez exécuter PostgreSQL dans le cluster, utilisez un opérateur Kubernetes comme CloudNativePG ou l’opérateur postgres de Zalando pour une gestion correcte du cycle de vie.

Terraform

Pour les déploiements infrastructure-as-code sur les fournisseurs cloud, Terraform peut provisionner l’infrastructure sous-jacente (VM, réseaux, load balancers) puis déployer les conteneurs Vajra Cast.

Un exemple simplifié pour AWS :

resource "aws_ecs_task_definition" "vajracast" {
  family                   = "vajracast"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "2048"
  memory                   = "4096"

  container_definitions = jsonencode([
    {
      name  = "vajracast"
      image = "registry.vajracast.com/vajracast:1.5.0"
      portMappings = [
        { containerPort = 8080, protocol = "tcp" },
        { containerPort = 9000, protocol = "udp" }
      ]
      environment = [
        { name = "DATABASE_URL", value = var.database_url }
      ]
    }
  ])
}

Note : Pour le transcodage matériel sur infrastructure cloud, vous avez besoin d’instances avec GPU Intel (ex. instances AWS avec Intel Flex GPU, ou instances bare-metal avec graphiques intégrés). Les VM cloud standard n’ont généralement pas de processeur graphique intégré Intel disponible.

Health Checks

Vajra Cast expose deux endpoints de health check, chacun servant un objectif différent :

Liveness : /api/health

Retourne HTTP 200 si le processus applicatif fonctionne et peut atteindre la base de données. Utilisez-le pour :

  • Le healthcheck Docker
  • Le livenessProbe Kubernetes
  • Les health checks du load balancer

Si ce endpoint échoue, le processus est en mauvaise santé et doit être redémarré.

Readiness : /api/ready

Retourne HTTP 200 uniquement après que l’application est entièrement initialisée : migrations de base de données terminées, toutes les routes chargées, tous les listeners liés. Utilisez-le pour :

  • Le readinessProbe Kubernetes
  • La santé du backend du load balancer (pour éviter de router du trafic vers une instance en cours de démarrage)

Pendant le démarrage, /api/ready retourne HTTP 503 jusqu’à la fin de l’initialisation. Cela empêche le routage prématuré du trafic.

Considérations de scaling

Les charges de travail de streaming live sont stateful — chaque instance Vajra Cast gère son propre ensemble de routes et de connexions SRT. Le scaling n’est pas aussi simple qu’augmenter le nombre de réplicas. Considérez ces approches :

  • Scaling vertical : Donnez à chaque instance plus de CPU et de mémoire pour gérer plus de flux.
  • Scaling horizontal partitionné : Exécutez plusieurs instances, chacune gérant un sous-ensemble de routes, avec un load balancer routant le trafic SRT vers la bonne instance selon le port.
  • Actif/standby : Exécutez une instance secondaire avec la même configuration (pointant vers la même base de données) qui prend le relais si la primaire tombe.

Prochaines étapes

← Retour au guide principal