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 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 et planificateur 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 :
* * * * * 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 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 ; 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 :
- Cliquez sur Ajouter un worker.
- Renseignez les réglages ci-dessous.
- 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 :
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, 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 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.
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 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 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.
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 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, 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. 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 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, ajoutez-les à nouveau.