PeerTube, c’est techniquement un process node JS à lancer d’une manière bien spécifique. Et je n’avais jamais réussi à le faire lancer proprement comme un démon via rcctl.

Jusqu’à tout recemment.

Je suis donc de plus en plus proche d’avoir une instance PeerTube pleinement fonctionnelle (lire : sans anicroche) sur OpenBSD.

Aujourd’hui c’est surtout la mise à jour et les compilations qui posent problème. Et ces deux trucs là bouffent énormément d’espace disque.

Et l’instance crashe tous les six mois. J’essaye de solutionner ça aussi.

En fait, j’ai décidé de déléguer la gestion du démon PeerTube à un autre démon node, lequel est bien décrit et ne pose pas de problème : PM2.

Installation de pm2

J’installe Pm2 suivant les instructions fournies dans la doc. C’est pas bien compliqué.

doas npm install pm2 -g

Voila c’est tout. Normalement ça marche.

Configuration de Pm2 avec PeerTube

Je place un fichier ecosystem.config.js dans /etc/pm/. Et en fait, comme vous l’avez compris, c’est pm2 qui demarre. Pas PeerTube. Du moins pas encore.

module.exports = {
apps : [{
    name: 'peertube',
    instances : "3",
    exec_mode : "cluster",
    cwd:  '/var/www/peertube/peertube-latest/',
    "listen_timeout" : 3000,
    env: {
        "USER":         "_peertube",
        "NODE_ENV":     "production",
        "HOME":         "/var/www/peertube/",
        "NODE_CONFIG_DIR": "/var/www/peertube/config/",
    },
    script: '/var/www/peertube/peertube-latest/dist/server',

    }, ]

};

Si vous faîtes bien attention, vous pouvez voir que j’utilise le mode cluster de pm, et que je lance 3 process peertube en parallèle. C’est un test, pas vraiment quelque chose que je maîtrise bien pour l’instant ni ne sais s’il est utile.

Edit : non, le mode cluster est une mauvaise idée. Il provoque pleins d’erreurs dans les logs. À la date de la version 2.3, totalement déconseillé.

RC

Reste plus qu’à demarrer PM2 au boot via rcctl, comme n’importe quel autre démon.

Donc plaçons un fichier /etc/rc.d/peertube, et n’oublions pas de l’activer dans /etc/rc.conf.local :

#!/bin/ksh

daemon="/usr/local/bin/pm2"

daemon_user="_peertube"

. /etc/rc.d/rc.subr

pexp="node: PM2.*God Daemon.*"

rc_start() {
    ${rcexec} "${daemon} start /etc/pm/ecosystem.config.js"
}

rc_reload() {
    ${rcexec} "${daemon} reload /etc/pm/ecosystem.config.js"
}

rc_cmd $1

Je fais donc démarrer pm2 directement comme l’utilisateur système _peertube. On est bien tranquille.

Au passage, l’utilisateur _peertube peut retrouver un dossier $HOME classique, c’est à dire /var/www/peertube.

En production

Je peux désormais faire un rcctl check :

stephane@dina:/var/www/peertube rcctl check peertube
peertube(ok)

Et summum du luxe, pm2 est un vrai superviseur nodeJS :

    stephane@dina:/var/www/peertube doas -u _peertube pm2 list
id name namespace version mode pid uptime status cpu mem user watching
0 peertube default 2.2.0 cluster 84782 5s 0 online 0% 0b _pe… disabled
1 peertube default 2.2.0 cluster 15036 5s 0 online 0% 0b _pe… disabled
2 peertube default 2.2.0 cluster 47410 5s 0 online 0% 0b _pe… disabled

On peut gérer les applications JS via pm2 dès lors que celui-ci tourne en tâche de fond.

stephane@dina:/var/www/peertube doas -u _peertube pm2 restart peertube
Use --update-env to update environment variables
[PM2] Applying action restartProcessId on app [peertube](ids: [ 0, 1, 2 ])
[PM2] [peertube](0) ✓
[PM2] [peertube](1) ✓
[PM2] [peertube](2) ✓
id name namespace version mode pid uptime status cpu mem user watching
0 peertube default 2.2.0 cluster 70669 0s 1 online 0% 0b _pe… disabled
1 peertube default 2.2.0 cluster 36994 0s 1 online 0% 0b _pe… disabled
2 peertube default 2.2.0 cluster 93986 0s 1 online 0% 0b _pe… disabled