Dagger: CI/CD as Code und Enabler für agentische KI

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Die Grundidee: eine Pipeline, überall

Im Kern will Dagger lokale, skriptbasierte CI/CD-Abläufe und ihre entfernten Gegenstücke zu einer einzigen, konsistenten und reproduzierbaren Pipeline vereinen.

Derselbe Workflow:

• läuft auf dem Laptop eines Entwicklers,

• läuft in der Cloud (etwa in GitHub Actions),

• verhält sich gleich,

• erzeugt dieselben Artefakte.

Keine Skripte nötig und keine doppelte Build-and-Push-Logik. Dieser Wechsel von maßgeschneiderten zu portablen Workflows hebt Dagger aus der Landschaft moderner CI/CD-Werkzeuge heraus.

Unternehmen profitieren von diesem Prinzip erheblich – kurzfristig, weil Dagger-Pipelines in der Regel einfacher und schneller zu schreiben sind, und langfristig, weil Daggers hervorragende Modularität und Wartbarkeit die Lieferzeit neuer Anwendungen verkürzen können.

Mehr als CI/CD

Interessanterweise ist Dagger, auch wenn CI/CD der häufigste Anwendungsfall ist, als „general-purpose composition engine for containerized workflows” konzipiert [1]. Weitere typische Einsatzgebiete sind:

• Agentische KI-Workflows

• ETL- und Datenverarbeitungs-Pipelines

• Release-Automatisierung

Um Daggers Mission zusammenzufassen, hier ein Zitat von der offiziellen Dokumentationsseite: „We’re building the devops operating system, an integrated platform to orchestrate the delivery of applications to the cloud from start to finish” [2]. Durchaus ambitioniert!

Wie Dagger unter der Haube funktioniert: die Dagger-API

Dagger stellt seine API über die Dagger Engine bereit, die in einem Container läuft. Um Dagger auf Ihrem System zu betreiben, benötigen Sie also lediglich eine OCI-kompatible Runtime wie Docker.

Das bedeutet auch: Egal, wo ein Dagger-Workflow ausgeführt wird – er verhält sich exakt gleich. Wer mit Containern vertraut ist, dürfte längst bemerkt haben, dass Dagger die Vorzüge der Containerisierung in die CI/CD-Welt trägt.

Intern nutzt Dagger GraphQL als sprachunabhängige Low-Level-API. Normalerweise schreiben Sie jedoch keine GraphQL-Abfragen selbst. Stattdessen verwenden Sie eines von Daggers SDKs (Go, Python, TypeScript usw.), die native Bindings erzeugen – mit:

• starker Typisierung,

• IDE-Autovervollständigung,

• Validierung zur Kompilierzeit.

Das ist einer der größten Gewinne für die Developer Experience!

Eine weitere zentrale Funktion der Dagger-API ist das Caching. Dagger überführt jeden API-Aufruf in einen DAG (Directed Acyclic Graph – daher der Name DAGger!) aus Low-Level-Operationen.

Wo möglich, wird jede dieser Operationen im Arbeitsspeicher zwischengespeichert, sodass ein Workflow nach dem ersten Lauf deutlich schneller ausgeführt wird.

Workflows as Code: Funktionen, Typen und Module

Bevor wir in die Praxis einsteigen, klären wir einige Grundbegriffe, die helfen, Daggers Stärken zu nutzen.

Funktionen als Bausteine

In Dagger ist ein Workflow nichts anderes als eine Komposition von Funktionen – entscheidend ist also zu verstehen, was eine Dagger-Funktion ist.

Eine Funktion ist, wie in den meisten Programmiersprachen, ein Stück Code, das eine Eingabe entgegennimmt und eine Ausgabe erzeugt und dabei einen Teil der Anwendungslogik kapselt.

Daggers Ansatz lehnt sich an das Paradigma der funktionalen Programmierung an, bei dem Programme durch das Verketten von Funktionsaufrufen entstehen.

Beim Schreiben Ihrer Funktionen greifen Sie über das SDK auf die Dagger-API zu. Damit können Sie die Core-API von Dagger sowie alle Dagger-Module aufrufen, von denen Sie abhängen. Ebenso stehen Ihnen die Standardbibliothek der Sprache und sämtliche benötigten Drittanbieter-Bibliotheken zur Verfügung!

Daggers Typsystem

Dagger bringt eingebaute Typen mit, etwa:

• Container

• Directory

• File

• Service

• Env

• LLM

Diese Typen sind fester Bestandteil der API und funktionieren genau wie Klassen in einer objektorientierten Sprache (etwa Java). Dagger-Typen:

• halten Zustand,

• stellen Methoden bereit,

• können zwischen Funktionen übergeben werden.

Eigene Typen lassen sich leicht erstellen, indem Sie Klassen in der gewählten SDK-Sprache schreiben und mit der Annotation @object_type versehen. Instanzmethoden der Klasse, die mit @function annotiert sind, werden zu Dagger-Funktionen.

Module: Wiederverwendung ohne Copy-Paste

Eigene Funktionen und Typen lassen sich in Dagger-Module paketieren. Module können:

• im Team geteilt,

• öffentlich auf Daggerverse veröffentlicht,

• direkt von GitHub ohne lokale Installation genutzt werden.

Dagger-Module sorgen für Wiederverwendbarkeit von Code – ähnlich wie Composite Actions und Reusable Workflows bei GitHub Actions.

Wenn Sie ein Dagger-Modul in Ihrem Workflow einsetzen, erweitern Sie im Grunde die Dagger-API um die Typen und Funktionen dieses Moduls.

Wie man die Dagger-API aufruft

Nachdem wir Daggers Innenleben kennen, sehen wir uns an, wie man es nutzt.

Die interaktive Dagger-Shell

Vorausgesetzt, Dagger ist auf Ihrem System installiert (falls nicht, finden Sie die Installationsanleitung auf dieser Seite), starten Sie die interaktive Dagger-Shell einfach mit dagger im Bash-Terminal:

Die interaktive Shell liest Ihre Befehle als Funktionen mit Eingabeargumenten. Um eine Pipeline auszuführen, verketten Sie Funktionsaufrufe mit dem Pipe-Symbol (|), wie in diesem Beispiel aus der offiziellen Dokumentation:

container |

from cgr.dev/chainguard/wolfi-base |

with-exec apk add go |

with-directory /src https://github.com/golang/example#master |

with-workdir /src/hello |

with-exec -- go build -o hello . |

file ./hello |

export ./hello-from-dagger

Beachten Sie: container ist ein Funktionsname! Genauer gesagt ist es der Konstruktor der Klasse Container, mit dem sich ein Objekt vom Typ Container erzeugen lässt. Die nachfolgenden Aufrufe richten sich sämtlich an Funktionen (Methoden) der Klasse Container (from, with-exec, with-directory …).

Die Dagger-CLI

Alternativ zur interaktiven Shell können Sie Dagger auch über den Befehl dagger in Bash aufrufen. Dieser Befehl liefert exakt dasselbe Ergebnis wie oben:

dagger core container from --address="cgr.dev/chainguard/wolfi-base" \

with-exec --args="apk","add","go" \

with-directory --path="/src" --source="https://github.com/golang/example#master" \

with-workdir --path="/src/hello" \

with-exec --args="go","build","-o","hello","." \

file --path="./hello" \

export --path="./hello-from-dagger"

Unabhängig davon, wie er ausgeführt wird, öffnet ein Client stets eine neue Session innerhalb der Dagger Engine. Jede Session ist mit einer eigenen GraphQL-Server-Instanz verbunden, wodurch die Ausführungsumgebung der Pipeline faktisch gesandboxt wird.

Dagger Cloud

Dagger Cloud ist ein Webportal, über das Organisationen Logs und Ergebnisse ihrer Dagger-Workflow-Läufe einsehen können.

Um sich aus Ihrer lokalen Entwicklungsumgebung mit Dagger Cloud zu verbinden, führen Sie den Befehl dagger login aus und folgen den Anweisungen.

Für die Verbindung aus einer CI-Umgebung wie GitHub Actions benötigen Sie ein Dagger-Cloud-Token. Dagger Cloud erzeugt dieses Token automatisch bei der Registrierung – Sie müssen es lediglich kopieren, als Secret in Ihrer CI-Umgebung hinterlegen und in Ihren Workflows referenzieren.

Wie sich Dagger mit GitHub Actions verbinden lässt

Nachdem wir die wichtigsten Aspekte von Dagger behandelt haben, treten wir einen Schritt zurück und vergleichen es mit GitHub Actions anhand einiger grundlegender CI/CD-Eigenschaften:

Auf den ersten Blick scheinen Dagger und GitHub Actions Konkurrenten im selben Feld zu sein. Tatsächlich glänzen sie jedoch in unterschiedlichen Bereichen und ergänzen sich hervorragend.

Als Faustregel hilft dieser Entscheidungsbaum bei der Wahl zwischen Dagger und GitHub Actions:

Setzen Sie Dagger ein, wenn:

• Build- und Testlogik wiederverwendbar sein muss.

• Hohe Konsistenz zwischen lokaler und CI-Umgebung wichtig ist.

• Caching eine zentrale Anforderung ist.

• Infrastrukturabstraktion über Container gewünscht ist.

Setzen Sie GitHub Actions ein, wenn:

• Orchestrierung und Event-Verarbeitung gefragt sind.

• Secrets-Management benötigt wird.

• Enge Repository-Integrationen wichtig sind.

• Compliance und Policy-Durchsetzung im Vordergrund stehen.

Sie können auch einen gemischten Ansatz wählen, der die Vorteile beider verbindet – etwa GitHub Actions für die Orchestrierung und Dagger für die Ausführung:

• GitHub bietet ein umfassendes Entwicklungs-Ökosystem, das Quellcode, Zusammenarbeit, Projektmanagement, Issue-Tracking, Sicherheit und CI/CD vereint.

• Dagger liefert schnelle und reproduzierbare Workflows.

Um diesen Ansatz zu veranschaulichen, integrieren wir Dagger nun in den SDLC einer Webanwendung, die in einem GitHub-Repository versioniert ist.

Demo-Projekt: CI/CD für eine Webanwendung

Diese Demo überträgt das Dagger-Modell auf eine einfache Anwendung mit zwei Microservices:

• Vue-Frontend

• FastAPI-Backend

Hier das GitHub-Repository des Projekts: https://github.com/Liquid-Reply/dagger-demo.

Das wollen wir mit Dagger erreichen:

• Entwickler müssen beide Microservice-Images aus ihrem lokalen Terminal heraus testen, bauen und in die GitHub-Registry veröffentlichen können (vorausgesetzt, Dagger ist installiert).

• Wenn Entwickler Code in Remote-Branches pushen oder einen Tag anlegen, muss ein GitHub-Actions-Workflow ausgelöst werden, der beide Images mithilfe des Dagger-Moduls baut und in die Registry veröffentlicht.

• Umgebungsspezifische Konfigurationen müssen beim Bau des Frontend-Images korrekt berücksichtigt werden.

Hier liegt das Dagger-Modul, das diese Anforderungen im GitHub-Repository umsetzt: https://github.com/Liquid-Reply/dagger-demo/tree/main/.dagger. In der README des Moduls erfahren Sie, wie es funktioniert und wie es zu verwenden ist.

Extra: Unterstützung für agentische KI

Wie eingangs erwähnt, lässt sich Daggers Ausführungsmodell auf viele Anwendungsfälle übertragen, nicht nur auf CI/CD-Pipelines. Dagger ermöglicht agentische KI, indem es in seiner Core-API eigene Typen für die Arbeit mit LLMs bereitstellt.

Diese Erweiterung der vorigen Demo zielt darauf ab, einen KI-Agenten Codeänderungen umsetzen zu lassen, die Entwickler angefordert haben.

Konkret wollen wir folgendes Szenario umsetzen: Öffnet ein Entwickler ein Issue in GitHub und versieht es mit dem Label „agent”, wird ein GitHub-Actions-Workflow ausgelöst. Dieser führt wiederum einen Dagger-Workflow aus, der:

1. das Issue liest und ein Feature bzw. einen Fix gemäß dessen Beschreibung entwickelt.

2. die Änderungen nach GitHub pusht und einen Pull Request zum Merge in den Branch main eröffnet.

Die Umsetzung nutzt das Modul github-issue. Den Code finden Sie hier: dagger-demo/.dagger/src/dagger_workflow/agent.py at main · Liquid-Reply/dagger-demo.

Fazit

Dagger sollte nicht Ihre bestehende CI/CD-Plattform ersetzen. Nutzen Sie es vielmehr, um die fragilen, skriptbasierten Schritte in Ihren Pipelines abzulösen.

Indem es lokale und entfernte Automatisierung zu einem einzigen, codegetriebenen Workflow vereint, versetzt Dagger DevOps-Teams in die Lage, Pipelines zu bauen, die schneller, sicherer und verständlicher sind – sowohl für Software-Releases als auch für KI-gestützte Entwicklung.