# Laravel Queue Worker, Scheduler und Node.js-Prozesse

> Laravel Queue Worker unter Supervisor betreiben, den Scheduler mit schedule:run jede Minute aktivieren und eine Node.js-App dauerhaft laufen lassen.

Die Seite **Queues und Scheduler** einer Laravel-Site betreibt die Prozesse, die deine App neben der Beantwortung von Webanfragen braucht: Queue Worker, die Jobs im Hintergrund abarbeiten, und den Laravel Scheduler. Bei einer Next.js- oder Nuxt-Site heißt dieselbe Seite **Prozesse** und hält deine Node.js-App am Laufen.

Jeder Worker und jeder Prozess läuft auf dem Server unter Supervisor. Supervisor startet ihn beim Booten und startet ihn neu, wenn er stoppt. Vimonto Deploy startet sie nach jedem Deployment neu, damit sie immer deinen neuesten Code ausführen.

![Die Seite Queues und Scheduler mit aktiviertem Scheduler und zwei laufenden Queue Workern](https://ops.vimonto.com/docs-media/de/site-queues.webp?v=161e760d "Queue Worker und Scheduler einer Laravel-Site")

Die Seite wird für Laravel-, Statamic-, Next.js- und Nuxt-Sites angezeigt. Für Prozesse, die nicht zu einer Site gehören, nutzt du die Seiten [Prozesse](https://ops.vimonto.com/docs/de/servers/processes) und [Scheduler](https://ops.vimonto.com/docs/de/servers/scheduler) des Servers.

## Den Laravel Scheduler aktivieren

Der Laravel Scheduler führt die Aufgaben aus, die du in deiner App definierst (`routes/console.php` oder der Console Kernel). Er braucht einen Cron-Eintrag, der jede Minute läuft:

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

Klicke unter **Scheduler** auf **Aktivieren**. Vimonto Deploy legt den Cron-Eintrag für die Site an; er läuft als Benutzer der Site im Live-Release. Sobald er eingerichtet ist, wechselt der Status auf **An**. Mit **Deaktivieren** entfernst du ihn wieder. Die Ausgabe jedes Laufs landet in einem Log: Öffne die Seite [Scheduler](https://ops.vimonto.com/docs/de/servers/scheduler#das-log-lesen) des Servers und klicke neben dem Job mit **Über Scheduler** auf **Log**.

Der Scheduler steht auch als **Scheduler** im Menü der [Site-Features](https://ops.vimonto.com/docs/de/sites/site-features); beide schalten dasselbe.

## Einen Queue Worker hinzufügen

Ein Queue Worker führt `php artisan queue:work` aus und verarbeitet die Jobs, die deine App dispatcht. So fügst du einen hinzu:

1. Klicke auf **Worker hinzufügen**.
2. Fülle die Einstellungen unten aus.
3. Klicke auf **Hinzufügen**.

| Einstellung | Standard | Was sie bewirkt |
|---|---|---|
| **Verbindung** | `redis` (oder `database` auf einem Server ohne Redis) | Die Queue-Verbindung aus `config/queue.php`. |
| **Queue** | `default` | Die abzuarbeitenden Queues, durch Kommas getrennt und nach Priorität geordnet, etwa `high,default`. |
| **Prozesse** | 1 | Wie viele Kopien des Workers parallel laufen (bis zu 50). |
| **Timeout (Sekunden)** | 60 | Wie lange ein Job laufen darf, bevor er gestoppt wird (`--timeout`). |
| **Versuche** | 3 | Wie oft ein fehlschlagender Job versucht wird (`--tries`). |
| **Warten, wenn leer (Sekunden)** | 3 | Wie lange gewartet wird, wenn die Queue leer ist (`--sleep`). |
| **Neustart nach (Sekunden)** | 3600 | Nach dieser Zeit beendet sich der Worker und wird neu gestartet (`--max-time`). |
| **Arbeitsspeicher (MB)** | 256 | Der Worker startet neu, wenn er mehr Speicher belegt (`--memory`). |

Der Worker läuft als Benutzer der Site im Live-Release der Site, mit der PHP-Version der 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
```

Bei einem [Monorepo](https://ops.vimonto.com/docs/de/sites/create-a-site#ein-monorepo-deployen) läuft der Worker im Stammverzeichnis der Site innerhalb des Release, zum Beispiel `/home/vimonto/shop.example.com/current/backend/artisan` mit dem Stammverzeichnis `/backend`. Dasselbe gilt für den Scheduler und die Prozesse von [Site-Features](https://ops.vimonto.com/docs/de/sites/site-features) wie Horizon.

Wird ein Worker gestoppt, gibt Supervisor einem laufenden Job seinen Timeout plus fünf Sekunden, um fertig zu werden, bevor er ihn beendet.

> [!TIP]
> Achte darauf, dass `QUEUE_CONNECTION` in der [.env](https://ops.vimonto.com/docs/de/sites/environment) zu der Verbindung passt, auf der deine Worker lauschen. Eine neue Laravel-Site nutzt auf Servern mit Redis `redis`.

### Worker starten nach jedem Deployment neu

Wenn ein Deployment live geht, führt Vimonto Deploy `php artisan queue:restart` aus. Jeder Worker beendet seinen aktuellen Job und stoppt, und Supervisor startet ihn auf dem neuen Release wieder. Du musst das nicht in dein Deploy-Skript aufnehmen.

## Prüfen, ob Worker laufen

Jeder Worker zeigt seinen Namen, seinen Befehl, die Anzahl der Prozesse und den aktuellen Zustand aus Supervisor: **Läuft**, **Startet**, **Wird gestoppt**, **Gestoppt** oder **Fehlgeschlagen**. Klicke auf **Status aktualisieren**, um den Zustand erneut abzurufen.

Für jeden laufenden Worker kannst du:

- ihn **Neu starten**. Nachdem du die `.env` geändert hast, startet die Option **Worker neu starten** beim [Speichern](https://ops.vimonto.com/docs/de/sites/environment#beim-speichern-den-config-cache-erneuern-und-die-worker-neu-starten) alle Worker der Site für dich neu.
- ihn **Stoppen** und später wieder **Starten**. Ein gestoppter Worker bleibt gestoppt, bis du ihn startest oder der Server neu bootet.
- **Log ansehen**: Das öffnet die Prozess-Seite des Servers mit der Ausgabe des Workers.
- ihn **Löschen**. Seine Prozesse stoppen und werden nicht wieder gestartet.

## Worker aus Site-Features

Einige [Site-Features](https://ops.vimonto.com/docs/de/sites/site-features) betreiben eigene Prozesse, etwa **Horizon**, **Reverb**, **Pulse**, **Inertia SSR** und **Nightwatch**. Sie erscheinen in der Liste mit einem Badge **Über …**, zum Beispiel **Über Horizon**. Hier siehst du ihren Zustand und kannst sie neu starten; ändern oder entfernen kannst du sie aber nur über das Feature im Site-Header.

> [!WARNING]
> Horizon betreibt alle Queue Worker, die deine `config/horizon.php` beschreibt. Wenn du Horizon aktivierst, entferne die selbst hinzugefügten Queue Worker, damit Jobs nicht doppelt abgearbeitet werden.

## Eine Node.js-App betreiben

Bei Next.js- und Nuxt-Sites heißt die Seite **Prozesse**. Nginx leitet Anfragen an die App auf dem Port der Site weiter (zu sehen in der Übersicht der Site und einstellbar in den [Site-Einstellungen](https://ops.vimonto.com/docs/de/sites/site-settings) als **Port deiner App**). Deine App muss also laufen und auf diesem Port lauschen.

Das musst du nicht selbst einrichten: Beim Erstellen der Site fügt Vimonto Deploy einen Prozess hinzu, der deine App mit `PORT` auf dem Port der Site startet. Er läuft im Live-Release der Site (im Stammverzeichnis eines Monorepos) als Benutzer der Site.

| Framework | Prozess | Befehl, für Port 3000 |
|---|---|---|
| Next.js | **Next.js-App** | `env PORT=3000 npm run start` (mit deinem Paketmanager) |
| Nuxt | **Nuxt-App** | `env PORT=3000 node .output/server/index.mjs` |

Bis zum ersten Deployment gibt es noch keinen Code zum Starten. Der Prozess steht dann auf **Wartet**, mit *Startet mit dem ersten Deploy.* Das erste Deployment legt ihn auf dem Server an und startet ihn; ein Prozess, der nicht starten konnte, wird beim nächsten Deploy erneut versucht. Änderst du den Port in den [Site-Einstellungen](https://ops.vimonto.com/docs/de/sites/site-settings#den-port-einer-nodejs-app-ändern), zieht der Prozess mit auf den neuen Port um.

Supervisor startet die App neu, wenn sie abstürzt, und Vimonto Deploy startet sie nach jedem Deployment neu, damit sie den neuen Build ausführt.

Willst du noch etwas anderes betreiben oder deine App auf deine eigene Art starten? Klicke auf **Prozess hinzufügen**, gib den **Befehl** ein (er läuft im Live-Release der Site, im Stammverzeichnis eines Monorepos, als Benutzer der Site), lege die Anzahl der **Prozesse** fest und klicke auf **Hinzufügen**. Ersetzt du den eigenen Prozess der App, lösche ihn, damit nicht zwei Kopien um denselben Port konkurrieren.

## Häufig gestellte Fragen

### Brauche ich Supervisor für Laravel Queues?

Ja. Ein Queue Worker ist ein langlebiger Prozess, der neu gestartet werden muss, wenn er stoppt. Vimonto Deploy richtet Supervisor für dich ein; jeder Worker, den du hinzufügst, ist ein Supervisor-Programm auf dem Server.

### Soll ich Horizon oder Queue Worker verwenden?

Nimm Horizon, wenn deine App Redis-Queues nutzt und du sein Dashboard, seine Metriken und das automatische Balancing möchtest. Du aktivierst es im Menü der [Site-Features](https://ops.vimonto.com/docs/de/sites/site-features#horizon). Einfache Queue Worker nimmst du für den `database`-Treiber oder wenn du Horizon nicht brauchst. Betreibe nicht beides auf denselben Queues.

### Warum läuft meine geplante Aufgabe nicht?

Prüfe, ob der Scheduler auf **An** steht und die Aufgabe in deiner App definiert ist. Geplante Aufgaben laufen im Live-Release; eine Site, die noch nicht deployt wurde, führt also nichts aus. Das **Log** auf der Seite [Scheduler](https://ops.vimonto.com/docs/de/servers/scheduler#das-log-lesen) des Servers zeigt, was `schedule:run` bei den letzten Läufen ausgegeben hat.

### Behalten Worker die alte PHP-Version, wenn ich wechsle?

Ja. Worker und der Scheduler behalten die PHP-Version, mit der sie angelegt wurden. Nachdem du die PHP-Version der Site in den [Site-Einstellungen](https://ops.vimonto.com/docs/de/sites/site-settings) geändert hast, legst du sie neu an.