Cloud Native Buildpacks und bootBuildImage

1. Der zweite Verpackungsweg: Buildpacks

Wenn Sie bereits ein ordentliches Dockerfile haben, entsteht das Gefühl: „Na gut, ich habe die Container besiegt, ich kann jetzt Tee trinken gehen.“ Und dieses Gefühl ist teilweise berechtigt: Dockerfile ist ein transparentes und kontrollierbares Werkzeug. Aber es hat eine Kehrseite: Es zwingt den Entwickler, selbstständig viele Entscheidungen zu treffen, von denen einige eigentlich Standard‑Routine sind. Und Routine, wie bekannt, wird gerne zu einem „Copy‑Paste aus einem Artikel von 2018“ und lebt für immer im Projekt, wie dieser eine TODO, den man „später erledigt“.

Stellen Sie sich vor, Sie sind neu im Team (oder Sie selbst in Ihrem eigenen Team in einem Monat). Sie öffnen das Dockerfile und sehen: Basis‑Image, irgendwelche RUN, einige seltsame JVM‑Argumente, knifflige Layer, separater Stage, noch ein Stage… All das ist erklärbar – genau das haben wir getan. Aber die Industrie hat längst bemerkt: Für Standardanwendungen kann man einen standardisierten, standardmäßig korrekten Weg bieten, damit nicht jeder Entwickler jedes Mal die Verpackung neu erfinden muss.

Hier kommen Cloud Native Buildpacks ins Spiel: Sie sind kein „Docker‑Ersatz“ und kein „magischer Knopf anstelle von Verständnis“, sondern ein Versuch, den Packaging‑Weg für bekannte Anwendungstypen (inklusive Spring Boot) verwaltbarer und wiederholbarer zu machen – ohne die Notwendigkeit, für jedes Projekt manuell ein Dockerfile zu schreiben.

2. Begriffe der Buildpacks

Das Wort buildpacks klingt so, als ob gleich Schamanismus der Stufe „Beschwöre den Geist des DevOps“ beginnt. In Wirklichkeit ist die Idee ziemlich bodenständig: Buildpacks sind eine standardisierte Pipeline, die Ihr Anwendung anhand einer Reihe von Regeln in ein Container‑Image verwandeln kann. Das Ergebnis bleibt also dasselbe, vertraute und überprüfbare: ein OCI/Docker‑kompatibles Image, das Sie wie gewohnt mit docker run starten.

Es ist wichtig, die Entitäten richtig zu trennen, sonst fängt das Gehirn an, alles durcheinander zu bringen. Dockerfile ist ein Dokument, in dem Sie die Build‑Schritte beschreiben. Buildpacks sind eine Sammlung von Modulen (Regeln), die die Build‑Schritte automatisch auswählen und anwenden, basierend darauf, was in Ihrem Projekt liegt. Und das Image ist das endgültige Artefakt. Buildpacks sind weder ein Image noch ein Container und „leben nicht neben Docker“ als separate Einheit zur Laufzeit. Sie existieren zum Zeitpunkt des Builds.

Um das zu festigen, sagen wir es fast wie eine Schulformel:

Buildpacks sind eine Möglichkeit, ein Image zu ERSTELLEN,
und keine Alternative zum Image selbst.

Für Spring Boot ist das besonders reizvoll, weil das Spring‑Boot‑Ökosystem diese Sprache direkt spricht: Das Spring‑Boot‑Plugin für Gradle bietet eine Aufgabe, die den Buildpacks‑Build startet. Hier ist uns zunächst die Idee und das Modell wichtig: Buildpacks werden in den gewohnten Gradle‑Pfad des Projekts integriert, anstatt ein separates Build‑Universum zu schaffen.

3. Phasen: Detection → Build → Export

Wenn Dockerfile so ist, wie Sie selbst ein Rezept schreiben („nimm ein Basis‑Image, kopiere die Jar, starte Java“), dann sind Buildpacks wie die Küchenlinie in einem guten Restaurant. Sie bringen die Zutaten (Projekt/Artefakt), das System schaut, was es ist, wählt das passende „Zubereitungsprogramm“ und liefert am Ende das Gericht (Image) aus. Man kann streiten, dass „die heimische Küche besser schmeckt“, aber im Team ist oft wichtiger, dass das Gericht stabil gleich ist und ohne Überraschungen zubereitet wird.

Der Buildpacks-Ansatz bietet ein sehr praktisches mentales Modell aus drei grobPhasen, das auf Junior‑Ebene ausreicht:

1) Detection – erkennen, um welche Anwendung es sich handelt.
2) Build – die erforderlichen Build‑/Packaging‑Schritte ausführen.
3) Export – das endgültige geschichtete Image zusammenbauen.

Ich nenne das bewusst „grobe Phasen“, denn im Inneren gibt es einen Lifecycle, Build‑Phasen und weitere Details, aber heute ist es wichtiger, nicht in Begriffen zu ertrinken, sondern den kausalen Zusammenhang zu verstehen.

Hier ist ein einfaches Diagramm, das Sie sich im Kontext unseres Kurses (Spring Boot + Gradle + Docker) merken sollten:

flowchart TD
    A["Quellcode des Projekts Container-Ready Catalog Service"] --> B["Build-Artefakt bootJar"]
    B --> C["Buildpacks Detection + Build + Export"]
    C --> D["Fertiges OCI/Docker-Image"]
    D --> E["docker run / docker ps / docker logs"]

Beachten Sie einen wichtigen Punkt: Buildpacks zaubern das Image nicht aus dem Nichts. Sie benötigen eine Eingabe – entweder Quellcode, ein Artefakt oder eine verständliche Projektstruktur. Ihre Arbeit mit Gradle und das Verständnis, was bootJar ist, verschwinden also nicht. Es ändert sich lediglich, wer die Verpackungsschritte beschreibt: Sie im Dockerfile oder eine Reihe von Regeln (Buildpacks).

4. Mechanik der Buildpacks

Builder‑ und Run‑Image

Einer der ersten „seltsamen“ Begriffe der Buildpacks ist, dass es plötzlich zwei Images gibt: das Builder‑Image und das Run‑Image. Und hier scheitern viele Anfänger: „Moment, wir bauen doch ein Image, wozu noch andere Images?“

Eine gute Analogie ist auch hier die Küche. Das Builder‑Image ist die „Küche“: Es enthält Werkzeuge (z. B. JDK, Build‑Utilities, die Buildpacks selbst) und wird nur zum Zubereiten des Endprodukts verwendet. Das Run‑Image ist der „Teller und das Gericht“: eine minimale Umgebung, in der die fertige Anwendung später läuft. Dieses Modell ähnelt stark dem Multi‑Stage‑Dockerfile, das Sie bereits kennen: Build‑Stage vs. Runtime‑Stage. Nur ist das bei Buildpacks alles standardisiert und in einer fertigen Mechanik verpackt.

Halten wir das in einer Tabelle fest, um Verwirrung zu vermeiden:

Ganz wichtig: Das Run‑Image ist nicht „FROM“ aus Ihrem Dockerfile, aber vom Sinn her nahe daran. Und das Builder‑Image ist kein „überflüssiges Image“, sondern einfach ein standardisiertes Analogon Ihrer Build‑Stage, nur im Format einer „fertigen Fabrik“.

Detection für Spring Boot

Vom Gefühl her ist Detection der Moment, in dem die Buildpacks „Ihr Projekt anschauen“ und entscheiden: „Aha, das ist ein Java‑Projekt. Genauer gesagt eine JVM‑Anwendung. Noch genauer – sieht nach Spring Boot aus.“ Hier muss man nicht an künstliche Intelligenz, neuronale Netze oder Mystik denken. Es handelt sich um eine Reihe von Prüfungen, die bekannte Marker suchen: Projektstruktur, Build‑Dateien, Anzeichen dafür, dass eine Java‑Umgebung benötigt wird, und so weiter.

Warum ist diese Phase wichtig? Weil sie erklärt, warum Buildpacks nicht zu einem „einen riesigen Befehl für alles“ werden. Buildpacks sind modular: für Java eines, für Node.js ein anderes, für Go ein drittes. Für Spring Boot wird normalerweise ein Satz von Buildpacks verwendet, der genau weiß, wie ein typischer Boot‑Service aufgebaut ist, und ihn zu einem geschichteten Image bauen kann, das für die Docker‑Welt geeignet ist.

Im Spring‑Boot‑Ökosystem taucht häufig der Name Paketo auf. Sie müssen jetzt nicht die Interna der Paketo‑Buildpacks auswendig lernen, aber es ist nützlich, die Rolle zu verstehen: Es ist ein „Lieferant“ einer Reihe von Buildpacks, die für Java und Spring Boot „standardmäßig die richtigen Dinge tun“. Das Ergebnis ist das Gefühl, auf einen Knopf gedrückt zu haben – während intern ein ganz konkretes, standardisiertes Szenario abgelaufen ist.

Und hier kommt eine subtile, aber wichtige methodische Schlussfolgerung: Buildpacks reduzieren den Umfang manueller Boilerplate, aber sie machen den Prozess nicht unerklärlich. Wenn Sie verstehen, was ein Image, Layer und die grundlegende Verpackung einer Boot‑Anwendung sind, dann sind Buildpacks einfach ein anderer Weg, zum selben Artefakt zu gelangen.

Rebase der Basislayer

Das Wort Rebase könnte an Git erinnern und leichte Unruhe auslösen. Im Buildpacks‑Kontext ist die Idee einfacher: Ein Image besteht aus Layern, und ein Teil dieser Layer ist die „Basis“ (Betriebssystem, Runtime), ein Teil ist „Ihre Anwendung“. Manchmal möchten Sie die Basis aktualisieren (z. B. wegen Sicherheitsupdates), aber nicht die ganze Welt neu bauen und riskieren, versehentlich den Anwendungs‑Layer zu ändern.

Der Buildpacks-Ansatz unterstützt konzeptionell den Gedanken: Basislayer und Anwendungs‑Layer können kontrollierter aktualisiert werden. Stellen Sie sich vor, Sie haben ein Image mit einem Boot‑Service, und es erscheint ein Update des Basis‑Runtime‑Layers (z. B. ein Sicherheitspatch im System oder ein Update der JVM‑Layer). Rebase ist ein mentales Modell, bei dem Sie die Basislayer aktualisieren, ohne Ihren Code anzutasten, und ein neues Image mit derselben Anwendung, aber einer frischeren „Unterlage“ erhalten.

Das ist keine „Magie ohne Folgen“: Wenn sich die Basisumgebung ändert, kann sich das Verhalten ändern (wie auch bei einem Wechsel von FROM im Dockerfile). Aber hier geht es um Disziplin: Der Prozess wird weniger manuell und standardisierter. Im Rahmen des Kurses reicht es zu verstehen, dass Buildpacks versuchen, das Aktualisieren der Basis weniger schmerzhaft zu machen als „das Dockerfile umschreiben / FROM ändern / alles neu bauen / hoffen, dass nichts kaputt geht“.

Was Buildpacks nicht ersetzen

An dieser Stelle möchte ich vor der schädlichsten Illusion warnen: „Wenn es Buildpacks gibt, braucht man kein Dockerfile mehr, und Docker kann man ignorieren.“ Das ist ungefähr so, als würde man sagen: „Wenn es Spring Boot gibt, kann man Java ignorieren.“ Man kann es natürlich versuchen … aber nur einmal, und danach wird man ein sehr philosophischer Mensch.

Selbst wenn Sie Ihr Image über Buildpacks bauen, müssen Sie trotzdem das Endergebnis im Kopf haben. Sie müssen weiterhin einen Container starten, Logs ansehen, Ports verstehen, wissen, was ein Image‑Tag ist, und die einfache Frage beantworten können: „Was haben wir da eigentlich gebaut und wie wird es gestartet?“ In diesem Kurs kehren wir immer wieder zu der Regel zurück: Die Container‑Welt liebt Beobachtbarkeit. Wenn der Build „verwaltet“ war, heißt das nicht, dass die Runtime „selbsterklärend“ ist.

Die gute Nachricht: Ein Buildpacks-Image ist keine „besondere Image‑Art“. Es ist ein gewöhnliches Docker/OCI‑Image. Das bedeutet, die gewohnten Werkzeuge funktionieren: docker images, docker run, docker ps, docker logs, docker image inspect. Und das ist psychologisch sehr wichtig: Sie lernen nicht „einen zweiten Docker“, sondern „einen zweiten Weg, denselben Docker zu bauen“.

Ein weiterer wichtiger Gedanke: Buildpacks widersprechen nicht unserer gestrigen Diskussion über Layer. Sie heben die Schichtung nicht auf. Vielmehr versuchen sie, einen typischen Spring‑Boot‑Service so zu verpacken, dass die Schichtung sinnvoll ist. Das Wissen über Layer bleibt weiterhin nützlich: Buildpacks heben sie nicht auf, sondern versuchen, einen typischen Spring‑Boot‑Service so zu bauen, dass die Schichtung sinnvoll ist. Jetzt reicht es, das Prinzip zu sehen: Einen Teil der Verpackungsarbeit geben Sie an ein standardisiertes Werkzeug ab, aber der ingenieurtechnische Sinn der Layer verschwindet nicht.

5. Demo: bootBuildImage

In der Praxis läuft die ganze Idee schnell auf einen geraden Gedanken hinaus: Statt des manuellen docker build bitten Sie Spring Boot, das Image über Buildpacks zu bauen.

./gradlew bootBuildImage

Nach dem Befehl erscheint in Ihrer lokalen Docker‑Umgebung ein normales Image. Es lebt dann nach denselben Regeln wie ein Image aus einem Dockerfile: Sie können es mit docker image ls sehen, mit docker run starten und mit einem bekannten Smoke‑Check überprüfen. Hier ist uns genau diese Tatsache wichtig: Der Packaging‑Pfad hat sich geändert, aber die Art des Ergebnisses nicht.

6. Typische Fehler bei Buildpacks

Fehler Nr. 1: Buildpacks mit einem Image verwechseln (und suchen, „wo das Buildpack im Container liegt“).
Buildpacks sind die Build‑Logik, die während des Packaging verwendet wird. Im Container läuft bereits das fertige Ergebnis – das Image mit Ihrer Anwendung. Wenn Sie sich dabei ertappen zu denken „Wie komme ich per docker exec in das Buildpack hinein?“, halten Sie inne und erinnern Sie sich: exec ist Runtime, Buildpacks sind Build‑Time.

Fehler Nr. 2: Glauben, dass Buildpacks „Docker ersetzen“ und man Images, Layer und Befehle vergessen kann.
Am Ende liefern Buildpacks immer noch ein OCI/Docker‑Image. Also bleiben Ports, Logs, Container‑Status, Tags, Image‑Inspektion und alle grundlegenden Diagnosepraktiken erhalten. Buildpacks nehmen einen Teil der Routine beim Packaging ab, entbinden aber nicht von der Verantwortung zu verstehen, was Sie ausführen.

Fehler Nr. 3: Denken, dass Buildpacks nur für „Cloud‑Plattformen“ geeignet sind und daher in der lokalen Entwicklung nutzlos sind.
Ja, Buildpacks lieben historisch Plattformen, aber für uns ist etwas anderes wichtig: Spring Boot kann diesen Pfad direkt von Gradle auf Ihrem Rechner aus starten. Das heißt, Buildpacks sind kein „irgendwo in der Cloud“, sondern ein durchaus lokales Werkzeug, das einfach ein Image auf standardisierte Weise baut.

Fehler Nr. 4: Buildpacks als Blackbox betrachten und sich prinzipiell nicht für deren Inneres interessieren.
Das Paradoxe ist: Je weniger Sie das Modell verstehen (Detection, Builder‑Image, Run‑Image), desto beängstigender wird jeder Fehler. Es reicht, ein einfaches Bild im Kopf zu haben: „Projekt erkannt → gebaut → geschichtetes Image exportiert“. Dann hören Buildpacks auf, Magie zu sein, und werden zu einem Werkzeug.

Fehler Nr. 5: Versuchen, Dockerfile und Buildpacks nur anhand eines Kriteriums zu vergleichen („wer hat das kleinere Image“).
Die Image‑Größe ist ein sichtbares, aber bei weitem nicht das einzige Kriterium. In der Praxis sind Wiederholbarkeit, Standardisierung, Transparenz der Schritte, Wartbarkeit, die Fähigkeit des Teams, die Funktionsweise zu erklären, und wie leicht Sie eingreifen können, wenn ungewöhnliches Verhalten erforderlich ist, ebenso wichtig. Wir werden die Ansätze ingenieurtechnisch vergleichen, nicht nach dem Prinzip „wer sieht im Lebenslauf cooler aus“.