Pipelines in echtem Code mit Dagger

Hier ist eine Schleife, die jeder DevOps-Ingenieur kennt. Wechseln Sie die Pipeline YAML. - Verpflichten. - Schiebt. Warten Sie auf den Informanten. Es ist ein Tippfehler. - Ich repariere. Ich habe das "fix ci" versprochen. - Schiebt. - Ich weiß. Versagen. "Wieder auf die Beine stellen". Zwanzig Commits später funktioniert es, und der Git-Verlauf sieht aus wie ein Hilferuf.

Das Hauptproblem ist, dass die meisten Pipelines nur innerhalb des CI-Systems laufen können. Sie können sie nicht auf Ihrem Laptop ausführen, sie ordnungsgemäß debuggen oder Logik wiederverwenden, ohne YAML zu kopieren. Dagger versucht, das zu beheben.

Das YAML-Problem

CI YAML ist zu einer Programmiersprache geworden, die niemand als solche entwickelt hat. Bedingungen, Schleifen, Variablen, Vorlagen, Ausdrücke innerhalb von Zeichenfolgen. Aber ohne Debugger, Tests, Typprüfung oder einen anständigen Weg, Code zu teilen.

Und jedes CI-System hat seinen eigenen Dialekt. Eine Pipeline, die für GitHub Actions geschrieben wurde, läuft nicht auf GitLab, Jenkins oder Ihrem Laptop.

Was der Dolch tut

Dagger, erstellt von einigen der ursprünglichen Docker-Team, lässt Sie Pipelines schreiben als Code in einer echten Programmiersprache: Go, Python, TypeScript und andere. Jeder Schritt läuft in einem Container, mit einer BuildKit-basierten Engine. Die gleiche Pipeline läuft auf Ihrem Laptop und in jedem CI-System identisch.

Ihre Informantenkonfiguration schrumpft auf "Installieren Sie Dagger, führen Sie diese Funktion aus".

Meine erste Dolch-Pipeline

Ein kleines Beispiel in Go: eine App erstellen und testen, dann ein Container-Image erstellen.

package main

import (
    "context"
    "dagger/shop/internal/dagger"
)

type Shop struct{}

// Run the tests
func (m *Shop) Test(ctx context.Context, source *dagger.Directory) (string, error) {
    return dag.Container().
        From("golang:1.25").
        WithMountedCache("/go/pkg/mod", dag.CacheVolume("go-mod")).
        WithDirectory("/src", source).
        WithWorkdir("/src").
        WithExec([]string{"go", "test", "./..."}).
        Stdout(ctx)
}

// Build the production image
func (m *Shop) Build(source *dagger.Directory) *dagger.Container {
    binary := dag.Container().
        From("golang:1.25").
        WithDirectory("/src", source).
        WithWorkdir("/src").
        WithEnvVariable("CGO_ENABLED", "0").
        WithExec([]string{"go", "build", "-o", "/app", "./cmd/server"}).
        File("/app")

    return dag.Container().
        From("gcr.io/distroless/static-debian12:nonroot").
        WithFile("/app", binary).
        WithEntrypoint([]string{"/app"})
}

Dann, von Ihrem Terminal:

dagger call test --source=.
dagger call build --source=. publish --address=ghcr.io/my-org/shop-api:dev

Das ist ein normaler Go-Code. Sie erhalten automatische Ausfüllung, Typen, Funktionen, Schleifen, Fehlerbearbeitung, und Sie können Ihre Pipeline-Logik wie jeder andere Code testen.

Die beste CI-Pipeline ist eine, die man auf seiner eigenen Maschine ausführen, debuggen und reparieren kann, bevor es jemand anderes sieht.

Dieselbe Pipeline vor Ort und in CI

In GitHub Actions wird der Workflow winzig:

- uses: dagger/dagger-for-github@<sha>
  with:
    verb: call
    args: test --source=.

Geh morgen ins GitLab oder Jenkins, und nur diese paar Zeilen ändern sich. Die Pipeline selbst bleibt gleich.

Caching ist eingebaut: Jeder Schritt wird von seinen Eingaben zwischengespeichert, so dass unveränderte Schritte lokal und in CI übersprungen werden (wenn der CI-Läufer den Cache behält oder Daggers Cloud-Caching verwendet).

Module zur Wiederverwendung

Dagger hat ein Modulsystem. Sie können Module aufrufen, die andere geschrieben haben (z. B. für Linting, Scannen oder Bereitstellen) oder Ihre eigenen in Ihrer Organisation teilen. Das ist eine viel schönere Art, Pipeline-Logik zu teilen, als YAML-Snippets zwischen Repositories zu kopieren.

Wenn es zu viel ist

Dagger ist nicht für jedes Projekt:

• Einfache Rohrleitungen: wenn Ihre Pipeline "Tests durchführen, Bilder erstellen, pushen" ist, ist einfaches CI YAML in Ordnung und für alle einfacher zu verstehen.
• Teamfähigkeit: jeder, der die Pipeline berührt, muss sich mit der gewählten Sprache vertraut fühlen.
• Ein weiteres Werkzeug zum Lernen und LaufenDie Dagger-Maschine muss überall dort verfügbar sein, wo Pipelines laufen, und sie entwickelt sich noch.
• Einheimische Merkmale Wie Matrix-Builds, Umgebungen und Genehmigungen kommen immer noch von Ihrem CI-System, also werden Sie beides verwenden.

Die wichtigsten Punkte sind: komplexe Pipelines, Monorepos mit vielen Komponenten, Teams, die es leid sind, sich "fix ci" zu verpflichten, und Organisationen, die mehr als ein CI-System verwenden.

Also, lohnt es sich zu versuchen?

Wenn Ihre Pipelines zu Hunderten von Linien von YAML gewachsen sind, die niemand anfassen will, ja. Beginnen Sie mit dem Umschalten einer komplexen Aufgabe in eine Dolchfunktion und führen Sie sie lokal aus. Wenn die Schleife "Schub und bete" verschwindet, wirst du es wissen.

Meine Meinung: Pipelines sind Software. Mit Dagger kannst du sie endlich so behandeln, mit den Tools, die wir für jedes andere Stück Code verwenden.

Desly