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 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 und 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:
* * * * * 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 des Servers und klicke neben dem Job mit Über Scheduler auf Log.
Der Scheduler steht auch als Scheduler im Menü der 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:
- Klicke auf Worker hinzufügen.
- Fülle die Einstellungen unten aus.
- 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:
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 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 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.
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
.envgeändert hast, startet die Option Worker neu starten beim Speichern 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 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.
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 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, 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. 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 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 geändert hast, legst du sie neu an.