Hostly

Beispiel: Hintergrund-Worker mit Queue ​

Dieses Beispiel lagert langsame Arbeit, etwa den Versand von E-Mails oder das Erzeugen von PDFs, aus einer Web-App in einen Hintergrund-Worker aus. Die App legt Aufgaben in eine Redis-Queue, der Worker holt sie dort ab und arbeitet sie ab.

text
Internet ──HTTPS──> app (app.example.hostly.ninja, Port 3000)
                     │
                     └──> queue:6379 (intern)
                            ^
                            │
                     worker (kein Port)

Die Beispiele verwenden das Workspace-Domainfragment example. Ersetze es und die Images von App und Worker durch deine eigenen.

Bezahlter Tarif

Dieses Beispiel betreibt drei Services in einem Workspace. Der Free Tier erlaubt einen Service pro Workspace, daher ist der bezahlte Tarif nötig.

1. Queue deployen ​

Erstelle einen neuen Service:

SchrittEinstellungWert
SubdomainNur intern erreichbaran
Name des Servicequeue
ImageImageredis:8
Container App Port6379

Nach dem Deployment zeigt die Service-Detailseite Intern erreichbar unter queue:6379.

Redis hält die Queue im Arbeitsspeicher. Noch wartende Aufgaben gehen bei einem Neustart der Queue verloren. Ist das nicht akzeptabel, füge ein Volume unter /data hinzu (bezahlter Tarif) und aktiviere die Redis-Persistenz in deinem Image, oder speichere die Aufgaben stattdessen in einer Datenbank.

2. Web-App deployen ​

Erstelle einen öffentlichen Service für die App:

SchrittEinstellungWert
SubdomainNur intern erreichbaraus
Subdomainapp
SSLan
ImageImageregistry.hostly.ninja/example/app:1.0.0
Container App Port3000
KonfigurationEnvironment VariablesREDIS_URL=redis://queue:6379

3. Worker deployen ​

Der Worker baut nur selbst eine Verbindung zur Queue auf. Niemand verbindet sich mit ihm, er braucht also weder eine Domain noch einen Port:

SchrittEinstellungWert
SubdomainNur intern erreichbaran
Name des Serviceworker
ImageImageregistry.hostly.ninja/example/worker:1.0.0
Dieser Service hat keinen Portausgewählt
KonfigurationEnvironment VariablesREDIS_URL=redis://queue:6379

Viele Frameworks starten App und Worker aus demselben Image mit einem anderen Startbefehl. Hostly verwendet den Startbefehl des Images. Baue für den Worker also ein eigenes Image bzw. einen eigenen Tag, oder lass das Image seinen Modus über eine Environment Variable wählen, z. B. MODE=worker.

Gut zu wissen ​

  • Health des Workers: Hostly kann an einen Service ohne Port keine Anfragen senden. Der Worker gilt als gesund, solange sein Container läuft. Ob Aufgaben abgearbeitet werden, siehst du in seinen Logs.
  • Mehr Durchsatz: Aktiviere High Availability für den Worker, um drei Instanzen zu starten, die Aufgaben parallel abarbeiten. Das funktioniert nur, wenn der Worker keinen lokalen Zustand hält.
  • Geplante Aufgaben: Ein Worker kann auch zeitgesteuerte Aufgaben ausführen, z. B. eine nächtliche Bereinigung, mit einer Scheduler-Bibliothek im Container.
  • Andere Broker funktionieren genauso, z. B. RabbitMQ auf 5672 oder NATS auf 4222.

Verwandte Seiten ​