# Queue worker Laravel, scheduler e processi Node.js

> Esegui i queue worker di Laravel con Supervisor, attiva lo scheduler con schedule:run ogni minuto e mantieni in esecuzione un'app Node.js con Vimonto Deploy.

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 Queue e scheduler con lo scheduler attivo e due queue worker in esecuzione](https://ops.vimonto.com/docs-media/it/site-queues.webp?v=161e760d "Queue worker e scheduler di un sito Laravel")

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](https://ops.vimonto.com/docs/it/servers/processes) e [scheduler](https://ops.vimonto.com/docs/it/servers/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:

```text
* * * * * 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](https://ops.vimonto.com/docs/it/servers/scheduler#leggere-il-log) 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](https://ops.vimonto.com/docs/it/sites/site-features); 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:

1. Fai clic su **Aggiungi worker**.
2. Compila le impostazioni qui sotto.
3. 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:

```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
```

Per un [monorepo](https://ops.vimonto.com/docs/it/sites/create-a-site#deploy-di-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](https://ops.vimonto.com/docs/it/sites/site-features) 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.

> [!TIP]
> Assicurati che `QUEUE_CONNECTION` nel [.env](https://ops.vimonto.com/docs/it/sites/environment) corrisponda alla connessione su cui ascoltano i tuoi worker. Un nuovo sito Laravel usa `redis` sui server con Redis.

### 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:

- **Riavvia**rlo. Dopo aver modificato il `.env`, l'opzione **Riavvia i worker** quando lo [salvi](https://ops.vimonto.com/docs/it/sites/environment#aggiorna-la-cache-della-configurazione-e-riavvia-i-worker-quando-salvi) riavvia per te tutti i worker del sito.
- **Ferma**rlo e **Avvia**rlo 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.
- **Elimina**rlo. I suoi processi si fermano e non vengono più avviati.

## Worker creati dalle funzionalità del sito

Alcune [funzionalità del sito](https://ops.vimonto.com/docs/it/sites/site-features) 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.

> [!WARNING]
> Horizon esegue tutti i queue worker descritti nel tuo `config/horizon.php`. Se attivi Horizon, rimuovi i queue worker che hai aggiunto tu, così i job non vengono presi in carico due volte.

## 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](https://ops.vimonto.com/docs/it/sites/site-settings) 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](https://ops.vimonto.com/docs/it/sites/site-settings#cambiare-la-porta-di-unapp-nodejs), 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](https://ops.vimonto.com/docs/it/sites/site-features#horizon). 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](https://ops.vimonto.com/docs/it/servers/scheduler#leggere-il-log) 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](https://ops.vimonto.com/docs/it/sites/site-settings), aggiungili di nuovo.