# Queue workers, planificateur Laravel et processus Node.js

> Faites tourner les queue workers Laravel sous Supervisor, activez le planificateur avec schedule:run chaque minute et gardez une application Node.js en marche.

La page **Files d'attente et planificateur** d'un site Laravel fait tourner les processus dont votre application a besoin en plus de répondre aux requêtes web : des queue workers qui traitent les jobs en arrière-plan, et le planificateur Laravel. Pour un site Next.js ou Nuxt, la même page s'appelle **Processus** et maintient votre application Node.js en marche.

Chaque worker et processus tourne sous Supervisor sur le serveur, qui le démarre au boot et le relance quand il s'arrête. Vimonto Deploy les redémarre après chaque déploiement, pour qu'ils exécutent toujours votre code le plus récent.

![La page Files d'attente et planificateur avec le planificateur activé et deux queue workers en cours](https://ops.vimonto.com/docs-media/fr/site-queues.webp?v=161e760d "Queue workers et planificateur d'un site Laravel")

La page est affichée pour les sites Laravel, Statamic, Next.js et Nuxt. Pour les processus qui n'appartiennent pas à un site, utilisez les pages [processus](https://ops.vimonto.com/docs/fr/servers/processes) et [planificateur](https://ops.vimonto.com/docs/fr/servers/scheduler) du serveur.

## Activer le planificateur Laravel

Le planificateur de Laravel exécute les tâches que vous définissez dans votre application (`routes/console.php` ou le kernel console). Il a besoin d'une entrée cron qui s'exécute chaque minute :

```text
* * * * * php8.4 artisan schedule:run
```

Sous **Planificateur**, cliquez sur **Activer**. Vimonto Deploy ajoute l'entrée cron pour le site, exécutée sous l'utilisateur du site dans la release en ligne. Le statut passe à **Activé** une fois l'entrée en place. Cliquez sur **Désactiver** pour la supprimer. La sortie de chaque exécution est conservée dans un log : ouvrez la page [planificateur](https://ops.vimonto.com/docs/fr/servers/scheduler#lire-le-log) du serveur et cliquez sur **Log** à côté de la tâche marquée **Via Planificateur**.

Le planificateur figure aussi sous **Planificateur** dans le menu des [fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features) ; les deux pilotent la même chose.

## Ajouter un queue worker

Un queue worker exécute `php artisan queue:work` et traite les jobs que votre application dispatche. Pour en ajouter un :

1. Cliquez sur **Ajouter un worker**.
2. Renseignez les réglages ci-dessous.
3. Cliquez sur **Ajouter**.

| Réglage | Défaut | Effet |
|---|---|---|
| **Connexion** | `redis` (ou `database` sur un serveur sans Redis) | La connexion de file d'attente définie dans `config/queue.php`. |
| **File d'attente** | `default` | Les files à traiter, séparées par des virgules, par ordre de priorité, comme `high,default`. |
| **Processus** | 1 | Le nombre de copies du worker qui tournent côte à côte (jusqu'à 50). |
| **Timeout (secondes)** | 60 | La durée maximale d'un job avant son arrêt (`--timeout`). |
| **Tentatives** | 3 | Le nombre de tentatives pour un job qui échoue (`--tries`). |
| **Pause si vide (secondes)** | 3 | Le temps d'attente quand la file est vide (`--sleep`). |
| **Redémarrer après (secondes)** | 3600 | Le worker se termine et redémarre à neuf après cette durée (`--max-time`). |
| **Mémoire (Mo)** | 256 | Le worker redémarre quand il utilise plus de mémoire (`--memory`). |

Le worker tourne sous l'utilisateur du site dans la release en ligne du site, avec la version de PHP du site :

```text
php8.4 /home/vimonto/shop.example.com/current/artisan queue:work redis --queue=default --sleep=3 --tries=3 --timeout=60 --max-time=3600 --memory=256
```

Pour un [monorepo](https://ops.vimonto.com/docs/fr/sites/create-a-site#déployer-un-monorepo), le worker tourne dans le répertoire racine du site au sein de la release, par exemple `/home/vimonto/shop.example.com/current/backend/artisan` avec un répertoire racine `/backend`. Il en va de même pour le planificateur et pour les processus des [fonctionnalités du site](https://ops.vimonto.com/docs/fr/sites/site-features) comme Horizon.

Quand un worker est arrêté, Supervisor laisse à un job en cours son timeout plus cinq secondes pour se terminer avant de l'arrêter.

> [!TIP]
> Vérifiez que `QUEUE_CONNECTION` dans le [.env](https://ops.vimonto.com/docs/fr/sites/environment) correspond à la connexion sur laquelle vos workers écoutent. Un nouveau site Laravel utilise `redis` sur les serveurs avec Redis.

### Les workers redémarrent après chaque déploiement

Quand un déploiement passe en ligne, Vimonto Deploy exécute `php artisan queue:restart`. Chaque worker termine son job en cours et se termine, et Supervisor le relance sur la nouvelle release. Vous n'avez pas besoin d'ajouter cela à votre script de déploiement.

## Vérifier que les workers tournent

Chaque worker affiche son nom, sa commande, son nombre de processus et son état en direct depuis Supervisor : **En cours**, **Démarrage**, **Arrêt en cours**, **Arrêté** ou **Échoué**. Cliquez sur **Actualiser le statut** pour récupérer à nouveau l'état.

Pour chaque worker en cours, vous pouvez :

- le **Redémarrer**. Après une modification du `.env`, l'option **Redémarrer les workers** lors de son [enregistrement](https://ops.vimonto.com/docs/fr/sites/environment#rafraîchir-le-cache-de-configuration-et-redémarrer-les-workers-à-lenregistrement) redémarre pour vous tous les workers du site ;
- l'**Arrêter**, puis le **Démarrer** plus tard. Un worker arrêté reste arrêté jusqu'à ce que vous le démarriez ou que le serveur redémarre ;
- **Voir le log**, qui ouvre la page des processus du serveur avec la sortie du worker ;
- le **Supprimer**. Ses processus s'arrêtent et ne sont plus relancés.

## Workers créés par les fonctionnalités de site

Certaines [fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features) font tourner leurs propres processus, comme **Horizon**, **Reverb**, **Pulse**, **Inertia SSR** et **Nightwatch**. Ils apparaissent dans la liste avec un badge **Via …**, par exemple **Via Horizon**. Vous pouvez voir leur état et les redémarrer ici, mais vous ne les modifiez ou ne les supprimez que via la fonctionnalité dans l'en-tête du site.

> [!WARNING]
> Horizon fait tourner tous les queue workers décrits dans votre `config/horizon.php`. Si vous activez Horizon, supprimez les queue workers que vous avez ajoutés vous-même, pour que les jobs ne soient pas traités deux fois.

## Faire tourner une application Node.js

Pour les sites Next.js et Nuxt, la page s'appelle **Processus**. Nginx transmet les requêtes à l'application sur le port du site (affiché dans la vue d'ensemble du site et défini dans les [paramètres du site](https://ops.vimonto.com/docs/fr/sites/site-settings) sous **Port de votre application**) : votre application doit donc tourner et écouter sur ce port.

Vous n'avez rien à configurer : à la création du site, Vimonto Deploy ajoute un processus qui démarre votre application avec `PORT` réglé sur le port du site. Il s'exécute dans la release en ligne du site (dans le répertoire racine d'un monorepo), sous l'utilisateur du site.

| Framework | Processus | Commande, pour le port 3000 |
|---|---|---|
| Next.js | **Application Next.js** | `env PORT=3000 npm run start` (avec votre gestionnaire de paquets) |
| Nuxt | **Application Nuxt** | `env PORT=3000 node .output/server/index.mjs` |

Avant le premier déploiement, il n'y a pas encore de code à démarrer : le processus affiche **En attente**, avec *Démarre au premier déploiement.* Le premier déploiement l'installe sur le serveur et le démarre ; un processus qui n'a pas pu démarrer est relancé au déploiement suivant. Si vous changez le port dans les [paramètres du site](https://ops.vimonto.com/docs/fr/sites/site-settings#changer-le-port-dune-application-nodejs), le processus passe lui aussi sur le nouveau port.

Supervisor relance l'application si elle plante, et Vimonto Deploy la redémarre après chaque déploiement pour qu'elle exécute le nouveau build.

Pour faire tourner autre chose, ou démarrer votre application à votre façon, cliquez sur **Ajouter un processus**, saisissez la **Commande** (elle s'exécute dans la release en ligne du site, dans le répertoire racine d'un monorepo, sous l'utilisateur du site), définissez le nombre de **Processus** et cliquez sur **Ajouter**. Si vous remplacez le processus de l'application, supprimez-le pour que deux copies ne se disputent pas le même port.

## Questions fréquentes

### Ai-je besoin de Supervisor pour les files d'attente Laravel ?

Oui : un queue worker est un processus de longue durée qui doit être relancé quand il s'arrête. Vimonto Deploy configure Supervisor pour vous ; chaque worker que vous ajoutez est un programme Supervisor sur le serveur.

### Faut-il utiliser Horizon ou des queue workers ?

Utilisez Horizon si votre application utilise des files Redis et que vous voulez son tableau de bord, ses métriques et son équilibrage automatique. Activez-le dans le menu des [fonctionnalités de site](https://ops.vimonto.com/docs/fr/sites/site-features#horizon). Utilisez de simples queue workers pour le driver `database` ou si vous n'avez pas besoin d'Horizon. Ne faites pas tourner les deux sur les mêmes files.

### Pourquoi ma tâche planifiée ne s'exécute-t-elle pas ?

Vérifiez que le planificateur est **Activé** et que la tâche est définie dans votre application. Les tâches planifiées s'exécutent dans la release en ligne : un site qui n'a pas encore été déployé n'exécute donc rien. Son **Log** sur la page [planificateur](https://ops.vimonto.com/docs/fr/servers/scheduler#lire-le-log) du serveur montre ce que `schedule:run` a affiché lors de ses dernières exécutions.

### Les workers gardent-ils l'ancienne version de PHP quand j'en change ?

Oui. Les workers et le planificateur conservent la version de PHP avec laquelle ils ont été créés. Après avoir changé la version de PHP du site dans les [paramètres du site](https://ops.vimonto.com/docs/fr/sites/site-settings), ajoutez-les à nouveau.