Exploitation

Lancer le web, le temps réel et les tâches dans un seul processus

Démarrez un site avec la commande python -m frappe.runner, qui exécute le serveur web, le temps réel (Socket.IO), les tâches de fond et le planificateur dans un seul processus. Utile pour un petit site ou un site d'essai.

Lancer le web, le temps réel et les tâches dans un seul processus

S'applique à : auto-hébergé, Dokos v5.

Le mode « processus unique » démarre un seul processus qui sert :

l'application web ;
le temps réel (notifications en direct, Socket.IO) ;
les tâches de fond et le planificateur.

Il n'y a ni Gunicorn, ni processus Node.js, ni worker séparé à superviser. Ce mode convient à un petit site ou à un site d'essai. Le code ne l'interdit pas en production, mais l'outil bench ne génère pas de configuration Supervisor ni Nginx pour ce mode (bench setup production configure toujours Gunicorn, le serveur Node.js et des workers séparés) : en production, vous écrivez et maintenez vous-même le service qui lance ce processus. Il est facultatif : un bench existant n'est pas modifié tant que vous ne lancez pas cette commande.

Prérequis

Un bench installé avec un site fonctionnel, et les services Redis du bench démarrés (le temps réel et les tâches de fond s'appuient sur redis_queue).
Le serveur web est démarré par uvicorn, avec la dépendance a2wsgi, toutes deux installées avec Dodock.
Pour l'option --dev : le paquet watchdog, installé avec pip install 'frappe[dev]'.

N'exécutez pas en même temps bench start, Gunicorn ou des workers sur le même bench : ils feraient double emploi avec ce processus.

Démarrer le processus

Depuis le dossier sites du bench :

cd sites
../env/bin/python -m frappe.runner --port 8000

Le processus écoute par défaut sur 127.0.0.1:8000. Pour le rendre accessible depuis un reverse proxy sur une autre machine, ajoutez --host 0.0.0.0 et protégez le port.

Exemple fictif : un site d'essai doit tourner sur un petit serveur, avec deux tâches de fond en parallèle et un reverse proxy local qui sert déjà /assets et /files.

cd sites
../env/bin/python -m frappe.runner --port 8000 --job-threads 2

Le site répond sur le port 8000, les notifications en direct passent par le même port (chemin /socket.io) et deux tâches de fond peuvent s'exécuter en même temps.

Options

Option	Valeur par défaut	Effet
`--host`	`127.0.0.1`	Adresse d'écoute
`--port`	`8000`	Port d'écoute
`--queue`	toutes les files	Files d'attente à traiter, séparées par des virgules
`--job-threads`	`1`	Nombre de tâches de fond exécutées en même temps
`--web-threads`	`0` (valeur de `FRAPPE_WEB_THREADS`, soit 8 sans variable)	Nombre de requêtes web simultanées
`--dev`	désactivé	Recharge le processus quand un fichier Python d'une application change, et sert aussi `/assets` et `/files`
`--verbose`	désactivé	Journalise chaque tâche et chaque paquet temps réel
`--restart-after-requests`	`5000`	Redémarrage après ce nombre de requêtes web réussies (`0` : jamais)
`--restart-after-jobs`	`500`	Redémarrage après ce nombre de tâches (`0` : jamais)
`--restart-idle-seconds`	`300`	Redémarrage après ce délai sans requête web, une fois du travail effectué (`0` : jamais)
`--request-drain-seconds`	`60`	Temps d'attente des requêtes en cours à l'arrêt
`--job-drain-seconds`	`600`	Temps d'attente d'une tâche en cours à l'arrêt

Un processus qui n'a encore rien traité ne redémarre pas pour cause d'inactivité. Le redémarrage n'a lieu que lorsqu'aucune requête ni tâche n'est en cours.

Variables d'environnement

Variable	Effet
`FRAPPE_WEB_THREADS`	Nombre de requêtes web simultanées (8 par défaut). L'option `--web-threads` la remplace.
`FRAPPE_SERVE_ASSETS`	Si elle est vraie, le processus sert aussi `/assets` et `/files`, comme lorsqu'aucun reverse proxy ne s'en charge. L'option `--dev` l'active. La route `/files` ne sert que les fichiers publics du site (`sites/<site>/public/files`). Les fichiers privés restent servis par l'application sous `/private/files`, avec contrôle des droits.
`FRAPPE_PRELOAD_MODULES`	À `0` ou `false`, désactive l'import anticipé des modules courants au démarrage, pour économiser de la mémoire. Cette variable s'applique aussi au serveur web Gunicorn habituel.

Sans reverse proxy et sans FRAPPE_SERVE_ASSETS, les feuilles de style, scripts et fichiers ne sont pas servis. Pour un usage derrière Nginx, laissez Nginx servir /assets et /files.

Arrêter, redémarrer, recharger

Le processus réagit à trois signaux :

Signal	Effet
`SIGTERM` ou `SIGINT`	Arrêt propre : les nouvelles requêtes sont refusées, les requêtes et les tâches en cours vont à leur terme (dans la limite des délais `--request-drain-seconds` et `--job-drain-seconds`), puis le processus s'arrête
`SIGHUP`	Redémarrage propre : même arrêt, puis le processus se relance avec la même commande et le même numéro de processus (PID)
Second signal d'arrêt	Arrêt immédiat

Les clients du temps réel sont déconnectés à l'arrêt, puis se reconnectent automatiquement quand le processus est reparti. Un SIGHUP reçu pendant un arrêt ne relance pas le processus.

Avec systemd, le processus peut reprendre le port d'écoute que systemd lui transmet (activation par socket, un seul descripteur) : les connexions attendent dans la file du socket pendant un redémarrage.

Planificateur et tâches

Le planificateur tourne dans un fil du processus. Il utilise le même verrou que le planificateur habituel du bench : si un autre planificateur est déjà actif sur le bench, celui du processus s'arrête aussitôt. Ne cumulez donc pas ce mode avec un planificateur lancé ailleurs sur le même bench.

Les tâches de fond s'exécutent dans des fils du processus et non dans des processus séparés. Une tâche en cours n'est pas interrompue de force par une demande d'arrêt.

Mode développement

Avec --dev, le processus surveille les fichiers .py des applications installées et se recharge environ une seconde après le dernier enregistrement. Les fichiers JavaScript ne déclenchent pas de rechargement. Sans watchdog, la commande s'arrête avec un message d'erreur.

N'utilisez pas --dev en production.

À savoir

La configuration du temps réel vient de common_site_config.json, comme pour le serveur temps réel séparé. Dans ce mode, les vérifications d'autorisation du temps réel appellent l'application web directement, sans passer par une requête HTTP vers le port.
La clé socketio_backend de la configuration (node ou python) indique seulement quel serveur temps réel séparé le bench utilise. Dodock la copie dans frappe.boot au démarrage de la session, mais aucun code de Dodock v5 ne la lit côté navigateur. Elle n'active pas ce mode processus unique : seule la commande frappe.runner le fait.
Un seul processus partage la mémoire et le processeur entre le web, le temps réel et les tâches : une tâche longue peut ralentir les requêtes. Pour un site à fort trafic, utilisez l'architecture habituelle décrite dans Architecture technique.
Pour surveiller le planificateur et les files de tâches, voir Diagnostiquer un site auto-hébergé.