Aufgabencontainer: Aufgaben, die bis zum Abschluss auf der Upsun Cloud ausgeführt werden

Das meiste, was auf einer modernen Plattform läuft, ist darauf ausgelegt, ständig verfügbar zu sein. Anwendungen bearbeiten Anfragen, Worker verarbeiten queues und Managed Services sorgen dafür, dass Datenbanken und Caches rund um die Uhr verfügbar sind. Doch ein nicht unerheblicher Teil der eigentlichen Arbeit passt nicht in dieses „Always-on“-Modell. 

Ein Massenimport, der ausgelöst wird, wenn ein Nutzer eine Datei hochlädt, eine einmalige Datenkorrektur, die über ein Admin-Tool angestoßen wird, ein KI-Agent, der einen Stapel Pull-Requests sortiert, ein Webhook-Handler, der auf ein einzelnes Stripe-Ereignis reagiert: Jedes dieser Beispiele hat einen Start, eine Aufgabe und ein Ziel – und sie in einen lang laufenden Prozess zu zwingen, ist nur eine Notlösung.

Der Task-Container ist die Infrastruktur-Grundkomponente von Upsun Cloud, die für Aufgaben entwickelt wurde, die bis zum Abschluss ausgeführt werden müssen.

Was ist ein Task-Container?

Eine Aufgabe ist eine bedarfsgesteuerte, bis zum Abschluss ausgeführte Arbeitslast, die parallel zu deinen Anwendungen und Diensten definiert wird. Drei Dinge unterscheiden sie von einer App oder einem Worker:

• Kurzlebig. Sie wird bei Auslösung erstellt und entfernt, sobald ihr Befehl beendet ist. Zwischen den Aufrufen läuft nichts weiter.
• On-Demand. Du startest eine Aufgabe über die Konsole, die CLI (upsun task:run) oder die API: aus der CI heraus, über einen Cron-Job, von einem anderen Dienst aus oder aus einer deiner Apps heraus.
• Wird bis zum Abschluss ausgeführt. Der Container hat eine klar definierte Aufgabe und ein klares Ende. Timeouts, Ressourcenbeschränkungen und Aktivitätsprotokollierung sind integriert.

Aufgaben werden in derselben Datei wie der Rest deines Projekts konfiguriert. Sie verfügen über ein eigenes Container-Image und einen eigenen Build-Schritt, unabhängig von deiner Anwendung. Über das Standard-Beziehungsmodell der Upsun Cloud greifen sie auf den Rest der Umgebung zu, einschließlich Datenbanken, Caches und aller anderen Dienste.

Wie Aufgaben in ein Projekt passen

Ein Upsun-cloud-Projekt besteht seit langem aus zwei Grundbausteinen: Anwendungen, die Anfragen bedienen und Hintergrundprozesse enthalten können, sowie Dienste, also die verwalteten Komponenten wie Datenbanken und Caches.

tasks: „joins“ applications: und services: auf der obersten Ebene von .upsun/config.yaml:

applications:
  api:
    # your long-running API
    
services:
  postgres:
    type: postgresql:18

tasks:
  myagent:
    type: nodejs:24
    run:
      command: node agent.js

Siehe die Konfigurationsreferenz in der Dokumentation zu den Task-Containern.

Was du darauf ausführen kannst

KI-Agenten

Agenten-Workloads haben eine bestimmte Struktur. Sie benötigen eine Umgebung mit Zugriff auf Code und Daten. Sie benötigen Isolation, da sie modellgenerierte Befehle ausführen. Sie benötigen bereichsbezogene Berechtigungen, da du nicht möchtest, dass ein Agent auf der Plattform beliebig auf Ressourcen zugreifen kann. Und sie müssen ihre Ausführung beenden, sobald die Arbeit erledigt ist, damit du zwischen den Läufen nicht für einen im Leerlauf befindlichen Container bezahlst.

Dieser letzte Punkt ist die Lücke, die der Task-Container für KI auf Upsun schließt. Der Rest war bereits vorhanden:

• Der Agent läuft in einer echten Umgebung, mit Zugriff auf das Repository, die Datenbank und alle Dienste, die der Rest deines Projekts nutzt.
• Die Isolation auf Containerebene sorgt dafür, dass jeder Agent in seinem eigenen isolierten Container läuft. Für einen LLM-Agenten, der vom Modell generierte Befehle ausführt, kombiniere dies mit einer containerinternen Sandbox wie „bubblewrap“, um das für den Agentenprozess sichtbare Dateisystem und die Systemaufrufe weiter einzuschränken.
• Die Aktivitätsprotokollierung erfasst, was der Agent getan hat, sodass ein Nachweispfad vorhanden ist.
• Workload-Autorisierungen, auf die weiter unten eingegangen wird, geben dem Agenten kurzlebige, eng begrenzte Tokens, um die Upsun Cloud API aufzurufen.

Ein paar konkrete Agent-Typen, die gut dazu passen:

• Ein Support-Agent, der bei Eingang eines neuen Tickets ausgelöst wird, dieses klassifiziert und eine erste Antwort entwirft.
• Ein Performance-Agent, der aktiv wird, wenn eine Metrik einen Schwellenwert überschreitet.

Dies ist bewusst als einfache Ausführungsprimitive konzipiert. Du bringst deinen eigenen Agenten-Code, deinen eigenen LLM-Anbieter und deine Schlüssel sowie dein eigenes Framework oder SDK mit, sodass du niemals an ein bestimmtes Modell, eine bestimmte Sprache oder ein bestimmtes Agentenmuster gebunden bist. Wir bieten dir eine flexible Ausführungsumgebung; du nutzt sie ganz nach den Anforderungen deiner Anwendung.

Batch-Jobs und Datenverarbeitung

Batch-Verarbeitung ist der umfassendste Anwendungsfall auf der Plattform und derjenige, auf den die meisten Upsun-Cloud-Kunden als Erstes zurückgreifen werden.

Beispiele:

• Ein CSV-Import, der ausgelöst wird, wenn ein Nutzer eine Datei hochlädt.
• Ein Export von Kundendaten, der generiert wird, wenn ein Kontoinhaber seine Historie anfordert.
• Ein Reindexierungsdurchlauf, der nach einer Schemaänderung den Suchindex neu aufbaut.
• Eine Bildverarbeitungs-Pipeline, die nach einem Content-Upload läuft.

Jeder dieser Vorgänge verläuft nach dem gleichen Muster: ausgelöst, ausgeführt, abgeschlossen. Die Frage ist, wo dieser Vorgang ausgeführt wird.

Standardmäßig wird sie im App-Container selbst ausgeführt, und das ist in Ordnung, solange der Job nicht zu ressourcenintensiv ist. Da sie sich jedoch die Ressourcen mit dem Datenverkehr deiner App teilt, konkurriert alles, was ressourcenintensiv ist, mit Live-Anfragen und kann die performance beeinträchtigen.

Die herkömmliche Lösung bestand darin, diese Aufgabe auf einen Worker zu verlagern. Das löst zwar das Problem der Ressourcenkonkurrenz, schafft aber ein neues: Ein Worker steht zwischen den Ausführungen im Leerlauf, sodass du für diese Leerlaufzeit bezahlst, unabhängig davon, wie oft die Aufgabe tatsächlich ausgeführt wird.

Cron-Jobs stehen vor dem gleichen Dilemma. Auch sie werden im App-Container ausgeführt, sodass ein ressourcenintensiver Cron-Job genauso mit dem Live-Traffic konkurriert wie ein Ad-hoc-Job. Die Planung mitten in der Nacht umgeht dieses Problem oft, da es dann keinen Datenverkehr gibt, mit dem man konkurrieren muss. Wenn deine App jedoch einen gleichmäßigeren, internationalen Datenverkehr verzeichnet oder der Job öfter als einmal am Tag laufen muss, gibt es dieses ruhige Zeitfenster möglicherweise gar nicht. Ein Cron-Job kann stattdessen eine Aufgabe auslösen, sodass die rechenintensive Arbeit in einem eigenen Container stattfindet, anstatt die Ressourcen deiner App zu beanspruchen.

Rechenintensive Datenoperationen

Routinemäßige Schemamigrationen, die mit einer Codeänderung verbunden sind, gehören in deinen Deploy-Hook – das ist der natürliche Ort dafür, und ein Task-Container ändert daran nichts.

Ein Task-Container hilft jedoch bei den aufwendigeren, weniger routinemäßigen Aufgaben: einer einmaligen Datenmigration, einer umfangreichen Datentransformation oder einem Massenimport, der zu ressourcenintensiv ist, um inline ausgeführt zu werden. Mit einem Task-Container ist dieser Schritt ein vollwertiger Bestandteil der Projektkonfiguration und kein Slack-Thread, in dem beschrieben wird, was jemand manuell erledigt hat.

Ereignisgesteuerte Webhooks

Externe Webhooks erreichen Task-Container in der Regel indirekt. Stripe sendet ein Zahlungsereignis. GitHub sendet ein Push-Ereignis. Slack sendet eine Interaktion. Meistens treffen diese bei einer ständig aktiven Anwendung ein, die die Nutzdaten validiert und dann die Upsun cloud-API aufruft, um eine Aufgabe auszulösen. Die App bleibt schlank und reaktionsschnell; die Aufgabe erledigt die lang andauernde Arbeit und wird beendet, sobald sie fertig ist.

Wenn die Webhook-Quelle selbst über ein authentifiziertes Token verfügt, kann sie die API direkt aufrufen, um die Aufgabe auszulösen – ganz ohne zwischengeschaltete App.

Was du sofort nutzen kannst

Jede Aufgabe verfügt über:

• Ein eigenes Container-Image und einen eigenen Build-Schritt, unabhängig vom Rest des Projekts.
• Sekundengenaue Abrechnung für die Dauer jedes Laufs – eine inaktive Aufgabe kostet also nichts.
• Timeouts und Ressourcenbeschränkungen, um außer Kontrolle geratene Aufgaben zu stoppen. Das Standard-Timeout beträgt eine Stunde; das Maximum liegt bei einem Tag.
• Aktivitätsprotokollierung, damit du sehen kannst, was wann gelaufen ist und was dabei passiert ist.
• Container-Isolation mit denselben Namespace- und Netzwerksteuerungen wie bei Anwendungen.
• Zugriff auf die von dir verknüpften Projektdienste über das Standard-Beziehungsmodell.
• Workload-Berechtigungen: der unten beschriebene Mechanismus mit kurzlebigen Tokens.

Workload-Autorisierungen: Kurzlebige Token für API-Aufrufe zur Laufzeit

Workload-Autorisierungen werden zusammen mit dem Task-Container bereitgestellt und ermöglichen es einer Anwendung oder einem Task, die Upsun Cloud-API zur Laufzeit mithilfe von kurzlebigen, eng begrenzten Token aufzurufen. Es müssen keine langlebigen Anmeldedaten gespeichert und keine Rotationen verwaltet werden.

Das ist weit über Agenten hinaus nützlich. Jede Workload, die mit der Plattform-API kommunizieren muss, profitiert davon: eine App, die eine datenintensive Importaufgabe auslöst, wenn ein Nutzer eine Datei hochlädt; ein internes Admin-Dashboard, das aktive Umgebungen und deren Status auflistet; oder eine Aufgabe, die Umgebungsmetadaten ausliest, um ihre Ausgaben mit dem Zweignamen zu kennzeichnen. Das Muster ist immer dasselbe: die Plattform um ein Token bitten, es verwenden, es ablaufen lassen.

Der Abschnitt zu den Workload-Berechtigungen enthält weitere Details.

Wichtige Überlegungen

• Deploys unterbrechen laufende Aufgaben. Die Plattform sendet zunächst ein Stopp-Signal und erzwingt nach einer kurzen Karenzzeit die Beendigung. Gestalte Aufgaben so, dass sie den Fortschritt fortlaufend speichern und sicher erneut ausgeführt werden können.
• Drei Aufgaben gleichzeitig pro Projekt. Das ist die Standardobergrenze. Alles, was darüber hinaus ausgelöst wird, wird in die Queue gestellt und wartet auf einen freien Platz.
• Aufgaben sind nicht direkt miteinander verbunden. Wenn zwei Teile deines Projekts Daten austauschen müssen, leite diese über einen Dienst (eine Datenbank, einen Cache oder einen gemeinsamen Speicher) weiter, auf den beide zugreifen können.
• Jeder Aufgabenlauf beginnt mit einem leeren Dateisystem. Die Standard-Arbeitsverzeichnisse werden zwischen den Läufen gelöscht. Um Dateien über mehrere Läufe hinweg beizubehalten, binde ein Speicher- oder Dienstvolume ein.
• Jedes Projekt benötigt mindestens eine Anwendung. Aufgaben können nicht eigenständig laufen. Ein Projekt, das nur aus Aufgaben und Diensten besteht, ist ungültig.
• Aufgaben werden in einer „Aufgaben“-Karte unter „Apps & Dienste“ in deiner Projekt- und Umgebungsübersicht angezeigt, zusammen mit Status, letzter Ausführung, Zuweisung und Beziehungen.
• Aufgaben bedienen kein HTTP. Sie können nicht als Upstream-Route verwendet werden. Wenn du die Verarbeitung von Anfragen und Antworten benötigst, ist das weiterhin die Aufgabe einer Anwendung.

Bist du bereit, eine zu erstellen? Schau dir die Dokumentation zu Task-Containern an, um loszulegen.

Häufig gestellte Fragen (FAQ)

Ist ein Task-Container dasselbe wie eine serverlose Funktion?
Das Ausführungsmodell ist ähnlich: ausgelöst, ausgeführt, beendet. Der Unterschied besteht darin, dass ein Task innerhalb deiner Upsun-Umgebung läuft und über Beziehungen direkten Zugriff auf deine Dienste und Daten hat. Du musst keinen Netzwerk-Hop zu einer separaten Plattform durchführen, um deine Datenbank zu erreichen.

Kann ich geplante Aufgaben ausführen?
Eine Aufgabe wird auf Abruf ausgelöst – über die Konsole, die CLI oder die API. Die Planung stellst du zusätzlich selbst ein, etwa mit einer Cron-App, einem CI-Job oder einem externen Scheduler.

Was passiert, wenn eine Aufgabe fehlschlägt oder ihr Timeout erreicht?
Der Lauf wird im Aktivitätsprotokoll als fehlgeschlagen protokolliert. Es gibt keinen automatischen Wiederholungsversuch; wer auch immer die Aufgabe ausgelöst hat, ist dafür verantwortlich, sie bei Bedarf erneut auszuführen. Das Standard-Timeout beträgt eine Stunde, maximal einen Tag. Gestalte Aufgaben so, dass sie idempotent sind, damit ein Wiederholungsversuch sicher ist.

Welche Laufzeiten kann ich für eine Aufgabe verwenden?
Die gleichen Laufzeit-Images wie für Anwendungen. Aufgaben deklarieren in „.upsun/config.yaml“ eine „type:“, genau wie Apps: Node.js, Python, PHP, Ruby, Go, Java, .NET. Bei KI-Agenten wählst du das, was dein Framework oder SDK benötigt.

Wie unterscheidet sich eine Aufgabe von einem Worker?
Ein Worker ist ein lang laufender Prozess, der beim Deployment gestartet wird und aktiv bleibt, um eine queue abzufragen oder Hintergrundarbeit zu erledigen. Eine Aufgabe läuft auf Abruf: Sie startet bei Auslösung, wird einmal ausgeführt und wird dann beendet. Wenn ständig Arbeit eintrifft, verwende einen Worker. Wenn Arbeit in Schüben eintrifft oder von einzelnen Ereignissen ausgelöst wird, verwende eine Aufgabe.

Teilen sich Aufgaben den Speicher mit meiner Anwendung?
Aufgaben verfügen bei jedem Durchlauf über ein eigenes Container-Image und ein neues Dateisystem. Sie teilen den persistenten Zustand mit Anwendungen auf dieselbe Weise, wie Anwendungen ihn untereinander teilen: über Dienste (Datenbanken, Objektspeicher, Caches) unter Verwendung des Standard-Beziehungsmodells. Um Dateien über mehrere Aufgabenläufe hinweg zu speichern, binde ein Speicher- oder Dienstvolume ein. Die Standard-Instanz- und tmp-Einbindungen werden zwischen den Läufen zurückgesetzt.

Kann eine Aufgabe die Upsun Cloud-API aufrufen?
Ja. Dafür sind Workload-Autorisierungen da: Eine Aufgabe fordert von der Plattform ein kurzlebiges, eng begrenzte Token an und nutzt es, um die API aufzurufen.