Task-Container verwandeln ungenutzte Rechenkapazitäten in On-Demand-Rechenleistung

In den meisten Produktivumgebungen gibt es irgendwo einen Container, der die ganze Woche über läuft, um am Freitag eine einzige Aufgabe zu erledigen.

Vielleicht indexiert er eine Datenbank neu. Vielleicht führt er einen Batch-Bericht aus oder eine Datenmigration, die nur am Monatsende wichtig ist. So oder so werden die Ressourcen für sieben Tage abgerechnet.

Task-Container schließen diese Lücke. Es handelt sich um kurzlebige, über eine API ausgelöste Container, die innerhalb einer Upsun-Cloud-Umgebung gestartet werden, genau einen Befehl ausführen und sich selbst entfernen, sobald dieser Befehl beendet ist. Zwischen den Ausführungsvorgängen bleibt nichts ungenutzt. Sie wurden am 12. August 2026 allgemein verfügbar, nachdem im Juni eine Vorabversion auf Upsun Flex gestartet worden war.

Corey Dockendorf, Senior Solutions Architect bei Upsun, hört immer wieder dieselbe Beschwerde. Ein Dienst wird für einen Job bereitgestellt, der einmal pro Woche läuft – und dann wartet er. Die Frage, die sich Kunden laut ihm stellen: „Warum bezahle ich die ganze Woche dafür, wenn er am Freitag nur eine einzige Sache erledigt?“

Was Task-Container eigentlich sind

Eine Aufgabe wird in „.upsun/config.yaml“ auf derselben Ebene wie deine Anwendungen und Dienste definiert. Zwei Felder sind erforderlich: ein Laufzeit-Image, das dieselbe Syntax verwendet wie Anwendungen, und der auszuführende Befehl. Wenn die Aufgabe ausgelöst wird, fügt Upsun Cloud einen Container in den Cluster der Umgebung ein, führt den Befehl bis zum Abschluss aus und entfernt den Container wieder.

„Im Grunde handelt es sich um eine kurzlebige, bedarfsgesteuerte Recheninstanz“, sagt Corey. „Sie werden gestartet, wenn sie direkt durch einen API-Aufruf ausgelöst werden. Sie führen genau einen Befehl aus und fahren dann automatisch herunter, sobald sie fertig sind.“

Die Funktionsweise ist bewusst eng gefasst. Du kannst eine Aufgabe auf drei Arten auslösen:

• Über die Konsole
• Über die CLI mit dem Befehl „upsun task:run“
• Mit einer POST-Anfrage an https://api.upsun.com/projects/{project}/environments/{env}/tasks/{taskname}/run, wobei optional Variablen im Anfragetext übergeben werden können

Jeder Aufruf erzeugt eine Aktivität mit eigener ID, Live-Status, gestreamten Protokollen und der Möglichkeit, sie abzubrechen. Das Standard-Timeout beträgt eine Stunde, das Maximum 24 Stunden. Die Abrechnung erfolgt pro Sekunde der jeweiligen Ausführung zu denselben CPU- und Speicherpreisen wie bei deinen Anwendungen.

Was Aufgaben nicht sind: Sie sind keine Daemons, sie werden nicht geplant und sie sind nicht routbar. Lang andauernde Hintergrundverarbeitung gehört nach wie vor in einen Worker, und alles, was nach einem festen Zeitplan ausgeführt werden muss, gehört nach wie vor in einen Cron. Es lohnt sich, den Unterschied zwischen Crons und Workern zu verstehen, bevor du zu einer Aufgabe greifst, denn Aufgaben lösen den dritten Fall: Arbeit, die jetzt, einmalig, erledigt werden muss und danach nicht mehr existiert. 

Der Zeitplan selbst liegt außerhalb der Aufgabe. Ein Cron, ein CI-Job oder deine eigene Anwendung führt den API-Aufruf durch, sodass der Zeitplan eingehalten wird, während die Rechenleistung bedarfsorientiert bleibt.

Die Jobs, die du bereits einmal pro Woche ausführst

Coreys Erfahrung ist, dass man das Konzept am schnellsten versteht, wenn man es mit etwas Alltäglichem in Verbindung bringt.

„Jeder indiziert die Datenbank neu“, sagt er. „Das ist einfach eine der Sachen, die man erledigen muss. Es ist die übliche Datenbankbereinigung.“

Es ist auch das Beispiel, das die Leute umstimmt. „Das ist das, was die Kunden wirklich überzeugt, denn sie denken sich: ‚Oh ja, das mache ich auch. Das habe ich auch. Das löse ich aus. Vielleicht einmal pro Woche, alle zwei Wochen, jeden Monat‘“, sagt Corey.

Er beobachtet das gleiche Muster bei KMU-, Mittelstands- und Großunternehmen, was Sinn ergibt, sobald man die Kandidaten aufzählt. Datenbankwartung. Datenexporte. Monatsabschlussberichte. Migrationen, die einmal pro Release laufen und dann nie wieder.

Aufgaben können während ihrer Ausführung auf den Rest der Umgebung zugreifen. Deklarierte Beziehungen gewähren einer Aufgabe Zugriff auf Dienste und Anwendungen, sodass eine Neuindizierung tatsächlich eine Datenbank hat, mit der sie kommunizieren kann, und die Anmeldedaten erscheinen in `PLATFORM_RELATIONSHIPS` innerhalb des Aufgabencontainers. Beziehungen laufen nur in eine Richtung. Weder Anwendungen noch andere Aufgaben können eine Beziehung zu einer Aufgabe deklarieren, da eine Aufgabe nur existiert, solange sie läuft. Wenn deine App das Ergebnis benötigt, übermittelt die Aufgabe es an einen bestimmten Ort.

Anwendungen können weiterhin Aufgaben starten. Gewähre der App eine Berechtigung zum Ausführen einer bestimmten Aufgabe, und sie fordert zur Laufzeit ein kurzlebiges Token vom lokalen Token-Endpunkt unter localhost:8200 an, anstatt eine langlebige Anmeldeinformation zu speichern. Diese Token verfallen standardmäßig nach 60 Sekunden, und du kannst ihre Gültigkeit mit dem x-token-ttl-Header auf 900 Sekunden verlängern, wenn du weniger Hin- und Rückläufe willst.

Agenten benötigen Produktionskontext, keinen Produktionszugriff

Der zweite Anwendungsfall ist neuer, und genau darauf geht Corey in der neuesten Folge von „Product Highlights“ ein.

Ein KI-Agent, der echte Arbeit verrichtet, „braucht tatsächlich Produktionskontext“, sagt er. „Protokolle, Metriken, Deployment-Verlauf.“ Was er nicht bekommen sollte, ist die Live-Anwendung. „Du willst einem Agenten auch wirklich keinen freien Lauf über die Live-App lassen“, sagt Corey. Ihm die Schlüssel zu übergeben und sich dann zurückzuziehen, ist in seinen Worten „ein erschreckender Gedanke“.

Das ist das Problem, auf das die meisten Teams an derselben Stelle stoßen. Ein Agent, der keinen Einblick in die Produktivumgebung hat, ist für den Betrieb völlig nutzlos. Ein Agent mit Zugangsdaten zur Produktivumgebung ist ein Risiko, das niemand eingehen will. Upsun hat bereits über die Zero-Trust-Variante dieses Arguments geschrieben: Es geht weniger darum, dem Modell zu vertrauen, sondern vielmehr darum, ob die Plattform drumherum die Grenzen aufrechterhalten kann.

Ein Task-Container ist ein Ort, an dem man diese Grenze setzen kann. Die Agent-Sitzung läuft in einem eigenen Container mit den Beziehungen und API-Berechtigungen, die du ihr gewährt hast – und sonst nichts. Aufgaben laufen in Linux-Containern mit derselben Isolation wie Anwendungen: eingeschränkte Capabilities, ein Seccomp-Profil, cgroup-Limits, Netzwerkisolierung. Für Programme, die du wirklich nicht vertraust, empfehlen die Dokumente, eine Aufgabe mit „Bubblewrap“ zu kombinieren, um den Zugriff auf das Dateisystem und auf Systemaufrufe weiter einzuschränken.

„Mit einem Aufgaben-Container kannst du diesem Agenten echten Kontext geben, aber auch eine ordentliche Isolation auf Container-Ebene“, sagt Corey. „Und dann kann dieser Agent eine Vorschau-Umgebung hochfahren und seine eigenen Änderungen validieren, bevor irgendetwas in der Produktivumgebung übernommen wird.“

Dieser letzte Schritt ist wichtiger als die Isolierung an sich. Ein Agent, der eine Änderung vorschlägt, ist kostengünstig. Ein Agent, dem die Berechtigung erteilt wurde, eine Umgebung zu verzweigen, kann zunächst anhand produktionsähnlicher Daten nachweisen, dass die Änderung funktioniert – wobei ein Mensch weiterhin die Kontrolle über die Zusammenführung behält –, und genau das ist der Teil, der das Ergebnis nutzbar macht.

Kostenkontrolle, die auch bei einer steigenden Anzahl von Agenten standhält

Die Abrechnung pro Sekunde wirkt wie ein bloßes Preisdetail – bis Agenten ins Spiel kommen. Die Arbeitslasten von Agenten sind von Natur aus sprunghaft, und das Risiko besteht nicht in einem einzigen teuren Lauf. Es sind Hunderte von günstigen Läufen, die niemand mitzählt.

Die Ressourcen für Aufgaben werden wie bei jedem anderen Container konfiguriert, sodass ein kleiner Job eine geringe Zuweisung erhält. Und parallele Läufe sind begrenzt – standardmäßig auf drei und während einer Testphase noch weniger –, wobei weitere Auslöser in die Queue gestellt und nicht ausgeführt werden. Diese Obergrenze dient ebenso als Kosten-Leitplanke wie als Planungsgrenze.

Was Upsun darauf aufbaut

Upsun hat auf derselben Grundlage eigene Agenten entwickelt. Wie Moderator Jack Creighton in der Folge sagte, wird der erste Agent, der auf den Markt kommt, ein performance-Agent sein, dem weitere folgen werden.

Das Muster ist die nützliche Erkenntnis, selbst wenn du nie einen Agenten ausführst. Rechenleistung, die nur existiert, solange sie arbeitet, beseitigt eine Kategorie von Entscheidungen, die du früher im Voraus treffen musstest: Wie viel sollst du für etwas bereitstellen, das meistens nichts tut? Du musst keine Kapazitäten mehr für Leerlauf einplanen.

Fang mit der Aufgaben-Dokumentation an und mit dem einen Job in deinem Stack, von dem du bereits weißt, dass du ihn einmal pro Woche ausführst.