La pagina Queue e scheduler di un sito Laravel esegue i processi di cui la tua app ha bisogno oltre a rispondere alle richieste web: i queue worker che elaborano i job in background e lo scheduler di Laravel. Per un sito Next.js o Nuxt la stessa pagina si chiama Processi e mantiene in esecuzione la tua app Node.js.
Ogni worker e processo gira sotto Supervisor sul server, che lo avvia all'accensione e lo riavvia quando si ferma. Vimonto Deploy li riavvia dopo ogni deploy, così eseguono sempre il codice più recente.
La pagina è disponibile per i siti Laravel, Statamic, Next.js e Nuxt. Per i processi che non appartengono a un singolo sito, usa le pagine processi e scheduler del server.
Attivare lo scheduler di Laravel
Lo scheduler di Laravel esegue i task che definisci nella tua app (routes/console.php o il console kernel). Ha bisogno di una voce cron che venga eseguita ogni minuto:
* * * * * php8.4 artisan schedule:run
In Scheduler, fai clic su Attiva. Vimonto Deploy aggiunge la voce cron per il sito, eseguita con l'utente del sito nella release attiva. Lo stato passa a On quando è pronta. Fai clic su Disattiva per rimuoverla. L'output di ogni esecuzione resta in un log: apri la pagina scheduler del server e fai clic su Log accanto al job contrassegnato Tramite Scheduler.
Lo scheduler compare anche come Scheduler nel menu delle funzionalità del sito; entrambi controllano la stessa cosa.
Aggiungere un queue worker
Un queue worker esegue php artisan queue:work ed elabora i job che la tua app mette in coda. Per aggiungerne uno:
- Fai clic su Aggiungi worker.
- Compila le impostazioni qui sotto.
- Fai clic su Aggiungi.
| Impostazione | Default | Cosa fa |
|---|---|---|
| Connessione | redis (oppure database su un server senza Redis) |
La connessione della queue da config/queue.php. |
| Queue | default |
Le queue da elaborare, separate da virgole, in ordine di priorità, per esempio high,default. |
| Processi | 1 | Quante copie del worker girano in parallelo (fino a 50). |
| Timeout (secondi) | 60 | Per quanto tempo un job può girare prima di essere fermato (--timeout). |
| Tentativi | 3 | Quante volte viene tentato un job che fallisce (--tries). |
| Attesa se vuota (secondi) | 3 | Quanto attendere quando la queue è vuota (--sleep). |
| Riavvia dopo (secondi) | 3600 | Dopo questo tempo il worker termina e viene riavviato da zero (--max-time). |
| Memoria (MB) | 256 | Il worker si riavvia quando usa più memoria di così (--memory). |
Il worker gira con l'utente del sito nella release live del sito, con la versione di PHP del sito:
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
Per un monorepo, il worker gira nella directory radice del sito all'interno della release, per esempio /home/vimonto/shop.example.com/current/backend/artisan con una directory radice /backend. Lo stesso vale per lo scheduler e per i processi delle funzionalità del sito come Horizon.
Quando un worker viene fermato, Supervisor concede a un job in corso il suo timeout più cinque secondi per terminare prima di fermarlo.
I worker si riavviano dopo ogni deploy
Quando un deploy va online, Vimonto Deploy esegue php artisan queue:restart. Ogni worker termina il job in corso ed esce, e Supervisor lo riavvia sulla nuova release. Non devi aggiungere questo comando al tuo script di deploy.
Verificare se i worker sono in esecuzione
Ogni worker mostra il nome, il comando, il numero di processi e lo stato in tempo reale da Supervisor: In esecuzione, Avvio in corso, Arresto in corso, Fermato o Non riuscito. Fai clic su Aggiorna stato per recuperare di nuovo lo stato.
Per ogni worker in esecuzione puoi:
- Riavviarlo. Dopo aver modificato il
.env, l'opzione Riavvia i worker quando lo salvi riavvia per te tutti i worker del sito. - Fermarlo e Avviarlo di nuovo più tardi. Un worker fermato resta fermo finché non lo avvii o il server non si riavvia.
- Visualizza log, che apre la pagina dei processi del server con l'output del worker.
- Eliminarlo. I suoi processi si fermano e non vengono più avviati.
Worker creati dalle funzionalità del sito
Alcune funzionalità del sito eseguono processi propri, come Horizon, Reverb, Pulse, Inertia SSR e Nightwatch. Compaiono nell'elenco con un badge Tramite …, per esempio Tramite Horizon. Qui puoi vederne lo stato e riavviarli, ma li modifichi o rimuovi solo tramite la funzionalità nell'intestazione del sito.
Eseguire un'app Node.js
Per i siti Next.js e Nuxt, la pagina si chiama Processi. Nginx inoltra le richieste all'app sulla porta del sito (mostrata nella panoramica del sito e impostata nelle impostazioni del sito come Porta della tua app), quindi la tua app deve essere in esecuzione e in ascolto su quella porta.
Non devi configurare niente: quando crei il sito, Vimonto Deploy aggiunge un processo che avvia la tua app con PORT impostata sulla porta del sito. Viene eseguito nella release live del sito (nella directory radice di un monorepo) con l'utente del sito.
| Framework | Processo | Comando, per la porta 3000 |
|---|---|---|
| Next.js | App Next.js | env PORT=3000 npm run start (con il tuo package manager) |
| Nuxt | App Nuxt | env PORT=3000 node .output/server/index.mjs |
Fino al primo deploy non c'è ancora codice da avviare: il processo resta In attesa, con Parte con il primo deploy. Il primo deploy lo installa sul server e lo avvia; un processo che non è riuscito ad avviarsi viene riprovato al deploy successivo. Se cambi la porta nelle impostazioni del sito, anche il processo passa alla nuova porta.
Supervisor riavvia l'app se va in crash, e Vimonto Deploy la riavvia dopo ogni deploy così esegue la nuova build.
Per eseguire anche altro, o avviare la tua app a modo tuo, fai clic su Aggiungi processo, scrivi il Comando (viene eseguito nella release live del sito, nella directory radice di un monorepo, con l'utente del sito), imposta il numero di Processi e fai clic su Aggiungi. Se sostituisci il processo dell'app, eliminalo, così due copie non si contendono la stessa porta.
Domande frequenti
Mi serve Supervisor per le queue di Laravel?
Sì, un queue worker è un processo di lunga durata che va riavviato quando si ferma. Vimonto Deploy configura Supervisor per te; ogni worker che aggiungi è un programma Supervisor sul server.
Meglio Horizon o i queue worker?
Usa Horizon se la tua app usa queue Redis e vuoi la sua dashboard, le metriche e il bilanciamento automatico. Attivalo dal menu delle funzionalità del sito. Usa i queue worker semplici per il driver database o quando Horizon non ti serve. Non eseguire entrambi sulle stesse queue.
Perché il mio task pianificato non viene eseguito?
Controlla che lo scheduler sia On e che il task sia definito nella tua app. I task pianificati girano nella release attiva, quindi un sito che non ha ancora fatto un deploy non esegue nulla. Il Log nella pagina scheduler del server mostra cosa ha stampato schedule:run nelle ultime esecuzioni.
I worker mantengono la vecchia versione di PHP quando la cambio?
Sì. Worker e scheduler mantengono la versione di PHP con cui sono stati creati. Dopo aver cambiato la versione di PHP del sito nelle impostazioni del sito, aggiungili di nuovo.