Remote Runner: installer en tant que service SystemD

Hello,

Je viens d’installer un Remote Runner pour tester. Je me rend compte que la documentation d’installation est un peu light.
Elle n’explique notamment pas comment faire pour l’avoir qui tourne en tant que service sur la machine (et donc, pour que ça démarre automatiquement au boot).

Je vous propose ici la procédure que j’ai appliquée, pour avoir des avis extérieurs. Et si ça semble ok, on pourra proposer de mettre à jour la documentation en ligne.

Pré-requis

Note: les commandes ci-dessous sont valable pour installer les paquets sur des systèmes type Debian (Debian, Ubuntu, …). Adapter en fonction de votre OS.

Installer ffmpeg, et vérifier les versions de ffmpeg et ffprobe:

sudo apt update
sudo apt install ffmpeg
ffprobe -version # Should be >= 4.3
ffmpeg -version # Should be >= 4.3

Installer NodeJS, version >= 16.
Attention, il faut également que npm soit installé. Ce qui n’est pas le cas avec le paquet nodejs fourni par Debian (npm est dans un autre paquet, dont le nom m’échappe).
On pourra passer par les méthodes d’installation documentées ici: GitHub - nodesource/distributions: NodeSource Node.js Binary Distributions

Ce qui donne par exemple (valable sur Debian, Ubuntu, et autres Linux compatibles):

# D'abord il faut importer la clé GPG de nodesource, qui permettra de vérifier les signatures GPG des paquets
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

# Ensuite on ajoute le dépot qui fourni les paquets
NODE_MAJOR=18 # Vous pouvez ici changer la version de Node que vous voulez.
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list

# Puis on instance nodejs
sudo apt-get update
sudo apt-get install nodejs -y

On peut maintenant installer le runner:

sudo npm install -g @peertube/peertube-runner

Préparation du user système

La documentation d’installation de peertube-runner indique juste comment lancer la commande. Mais pas comment le faire proprement au démarrage du système.

Nous allons donc créer un user spécifique, avec un dossier de travail dédié:

useradd -m -d /srv/prunner -s /bin/bash -p prunner prunner

J’ai choisi ici de :

  • l’appeler prunner
  • mettre son dossier de travail dans /srv/prunner

Vous pouvez bien sûr adapter cela comme bon vous semble.

Attention, si vous mettez son dossier dans /home/, il faudra adapter la config systemd plus bas (qui isole /home).

Configuration de SystemD

Nous allons maintenant configurer SystemD pour créer un service associé au runner.
Cela permettra de le lancer automatiquement au démarrage.

Créer le fichier /etc/systemd/system/prunner.service suivant (adaptez le user/group et le dossier le cas échéant):

[Unit]
Description=PeerTube runner daemon
After=network.target

[Service]
Type=simple
Environment=NODE_ENV=production
User=prunner
Group=prunner
ExecStart=peertube-runner server
WorkingDirectory=/srv/prunner
SyslogIdentifier=prunner
Restart=always

; Some security directives.
; Mount /usr, /boot, and /etc as read-only for processes invoked by this service.
ProtectSystem=full
; Sets up a new /dev mount for the process and only adds API pseudo devices
; like /dev/null, /dev/zero or /dev/random but not physical devices. Disabled
; by default because it may not work on devices like the Raspberry Pi.
PrivateDevices=false
; Ensures that the service process and all its children can never gain new
; privileges through execve().
NoNewPrivileges=true
; This makes /home, /root, and /run/user inaccessible and empty for processes invoked
; by this unit. Make sure that you do not depend on data inside these folders.
ProtectHome=true
; Drops the sys admin capability from the daemon.
CapabilityBoundingSet=~CAP_SYS_ADMIN

[Install]
WantedBy=multi-user.target

Note: si vous voulez avoir plusieurs instances nommées, ajoutez le paramètre --id instance-1 sur la ligne ExecStart, et créez un fichier par instance.

Ensuite, pour prendre en compte le fichier:

systemctl daemon-reload
systemctl enable prunner.service
systemctl restart prunner.service

Voilà, votre runner doit tourner !

Exécuter les commandes

Pour exécuter les différentes commandes (register, unregister, list-registered), il faut bien penser à le faire en temps que user prunner:

sudo -u prunner peertube-runner list-registered
# ou si vous avez ajouté un --id:
sudo -u prunner peertube-runner --id instance-1 list-registered

Changer la configuration du runner

# Nb: si vous aviez mis un --id, il faut adapter le chemin du fichier ci dessous
vi /srv/prunner/.config/peertube-runner-nodejs/default/config.toml
# éditer les valeurs, puis redémarrer le service:
systemctl restart prunner

Mettre à jour le package du runner

On peut vérifier s’il y a une version à jour disponible:

sudo npm outdated -g @peertube/peertube-runner
Package                    Current  Wanted  Latest  Location                                Depended by
@peertube/peertube-runner    0.0.6   0.0.7   0.0.7  node_modules/@peertube/peertube-runner  lib

Ici, j’ai actuellement la version 0.0.6, et une version 0.0.7 est disponible.

Pour mettre à jour:

# Mise à jour:
sudo npm update -g @peertube/peertube-runner
# Vérifier que la version installée a bien changé (optionnel):
sudo npm list -g @peertube/peertube-runner
#Redémarrer le service:
sudo systemctl restart prunner.service
3 « J'aime »

Je me demande aussi: quelqu’un aurait des idées sur comment monitorer les runners ?
En d’autres termes: être prévenu s’ils plantent ou n’arrivent pas à se connecter.

On peut imaginer du monitoring « local »: alertes mail si le service plante, etc.
Mais aussi du monitoring distant, avec des outils type nagios, alertmanager, …

Et un autre point. Je me demande si on ne pourrait pas utiliser un tmpfs en RAM pour le dossier de travail du runner.
Les données de vidéos n’ont pas vocation à rester sur le disque. Des quelques essais que j’ai fait, l’usage disque ne dépasse pas quelques dizaines de Mo, les chuncks étant supprimés dès qu’ils ont été envoyé au serveur Peertube.

Ça permettrait de gagner en vitesse si on a des HDD, et d’économiser leur durée de vie si on a des SSD.

Bon, ça demanderait peut-être à revoir un peu le code des runners, pour que le dossier de travail soit clairement identifié (et pas planqué dans .cache).

Hello, merci pour ce tuto, je vais tester. Je suis justement entrain de faire des essais.

Je me pose encore une question: comment être prévenu des nouvelles versions ?

Je ne crois pas qu’il y ai d’option sur npm pour recevoir des notifs mails (en tout cas, pas pour les comptes gratuits).
Le code source est dans un sous-dossier du projet Peertube principal, donc les notifs sur les releases Peertube ne sont adéquates.

:thinking:

Encore une question (je regroupe tout ici): je constate qu’en utilisant les runners, il y a un premier transcodage vers un fichier «classique» appelé «max-quality». Ensuite, c’est réencodé en HLS partout (et de manière parallèle sur plusieurs runners), et ce premier fichier transcodé est supprimé.

Je me demande à quoi sert cette première étape. N’est-ce pas une perte de temps, et un risque de perdre en qualité ? Pourquoi n’utilise-t-on pas le fichier original comme base pour tous les transcodages ?

On a eu des soucis en générant des playlists HLS via un fichier en entrée non optimisé. Il faudrait aussi faire des mesures réelles mais si tu gardes le fichier original en entrée de chaque transcodage, ça crée sans doute un overhead dans ffmpeg si le fichier original est lourd et/ou utilisant un codec complexe.

1 « J'aime »

Ok, merci pour les éclaircissements. J’imaginais que c’était un truc du genre.

En tout cas, bravo pour le travail réalisé. C’est impressionnant de voir ça fonctionner :slight_smile:

1 « J'aime »

Je viens d’avoir une idée: on pourrait créer un plugin « runner », qui permettrait d’installer et gérer un runner automatiquement.

Basiquement, voilà ce que ça ferait :

  • le plugin dépend du paquet @peertube/peertube-runner
  • une page de settings où on peut régler le nombre de jobs concurrents et le nombre de threads
  • ça écrit un fichier de conf pour le runner, avec ces infos (dans le dossier data du plugin)
  • au register du plugin, on lance le runner (en lui spécifiant le fichier de conf qui va bien). Si jamais il plante, on le relance.
  • au unregister, on le coupe
  • une page d’administration du plugin qui appelle peertube-runner list-registered, et affiche le résultat (accessible uniquement aux admins de l’instance)
  • un formulaire d’ajout: on configure l’url de l’instance, le token d’authentification, et hop ça appelle peertube-runner register. Il faudra prévoir de contrôler les saisies, pour éviter les attaques par injection.
  • dans la page qui affiche peertube-runner list-registered, on a un bouton qui permet de supprimer une ligne (via un appel à la commande unregister, avec une confirmation avant de faire la suppression)
  • penser à mettre à jour le plugin quand une nouvelle version du runner sort

Et la cerise sur le gateau: voir si on est capable de l’enregistrer automatiquement pour l’instance courante (à voir si les API où helpers adéquates existent, sinon ouvrir une feature request coté Peertube).

Ça semble assez simple à faire (de l’ordre de 1 ou 2j de boulot).
Perso je n’ai pas le temps de faire ça en ce moment, donc si quelqu’un est motivé⋅e: go go go ! :slight_smile:

1 « J'aime »

Zut, je ne peux plus éditer le premier message. Si un⋅e modo passe par là, je veux bien qu’iel ajoute cette section à la fin du premier message:

Mettre à jour le package du runner

On peut vérifier s’il y a une version à jour disponible:

sudo npm outdated -g @peertube/peertube-runner
Package                    Current  Wanted  Latest  Location                                Depended by
@peertube/peertube-runner    0.0.6   0.0.7   0.0.7  node_modules/@peertube/peertube-runner  lib

Ici, j’ai actuellement la version 0.0.6, et une version 0.0.7 est disponible.

Pour mettre à jour:

# Mise à jour:
sudo npm update -g @peertube/peertube-runner
# Vérifier que la version installée a bien changé (optionnel):
sudo npm list -g @peertube/peertube-runner
#Redémarrer le service:
sudo systemctl restart prunner.service

Tu ne veux pas ajouter une section dans CLI tools guide | PeerTube documentation (tant pour l’upgrade que pour le service systemd) ?

1 « J'aime »

À la base je ne l’avais pas fait, j’attendais d’éventuels retours.
Mais vu que ça tourne chez moi depuis un moment sans soucis, je vais faire ça, je vais mettre à jour la doc (dès que je trouve un peu de temps).

Et voilà !

J’espère ne pas avoir fait d’erreur.