Container- und Image-Grundlagen

Container- und Image-Grundlagen

0:00 Container sind längst nicht mehr die Kür, sondern die Grundausstattung. Wer heute eine Anwendung ausliefert, liefert in aller Regel ein Image aus — und damit nicht nur den eigenen Code, sondern die komplette Umgebung, in der er laufen soll. Das ist ein enormer Gewinn an Verlässlichkeit, und es verschiebt Verantwortung: Was früher der Betrieb auf dem Server einrichtete, entscheidet heute eine Datei im Repository.

0:23 In diesem ersten Modul geht es genau um diese Datei und um das, was sie erzeugt. Wir bauen Images, wir machen sie klein, und wir lernen, sie so zu benennen, dass später niemand rätseln muss, was eigentlich läuft.

Dockerfile-Anatomie

0:36 Fangen wir an der Stelle an, an der alles beginnt: bei einer schlichten Textdatei mit einer Handvoll Anweisungen. Sie sieht unspektakulär aus, und gerade das ist ihre Stärke. Wer diese Datei versteht, versteht den Rest des Seminars — jedes weitere Thema hängt an ihr. Stellen Sie sich ein Dockerfile wie ein Kochrezept vor, das nicht nur die Zubereitung beschreibt, sondern auch die Küche.

0:59 Es beginnt mit einem Basis-Image, also einer vorbereiteten Grundausstattung, und legt dann Schritt für Schritt fest, was hinzukommt. Die Reihenfolge ist verbindlich, und die meisten Anweisungen hinterlassen eine eigene Schicht im Ergebnis. Das Entscheidende daran ist weniger technisch als organisatorisch: Diese Datei ist die Dokumentation der Laufzeitumgebung.

1:19 Sie liegt versioniert im Repository und nicht im Erfahrungswissen einzelner Kolleginnen und Kollegen. Wer wissen will, mit welcher Java- oder Node-Version ein Dienst läuft, liest nach, statt zu fragen. Das hier ist ein vollständiges, alltagstaugliches Dockerfile für unseren Beispieldienst — die Kartenwerk-API, die uns durch das ganze Seminar begleitet.

1:40 Lesen Sie es nicht als Syntax, sondern als Abfolge von Absichten: erst die Grundausstattung wählen, dann ein Arbeitsverzeichnis festlegen, dann Abhängigkeiten installieren, dann den eigenen Code hineinlegen, und am Schluss festlegen, wer den Prozess startet und wie. Interessant ist vor allem eine scheinbare Kleinigkeit: Die Paketdateien und der Quellcode werden getrennt kopiert, in zwei Schritten.

2:02 Das ist kein Ordnungssinn, sondern der Grund dafür, dass der nächste Build Sekunden statt Minuten dauert. Darauf kommen wir im zweiten Kapitel zurück. Diese Übersicht müssen Sie nicht auswendig lernen, aber ein Muster darin lohnt sich: Die Anweisungen lassen sich in zwei Gruppen sortieren. Die eine Gruppe verändert tatsächlich das Image — sie kopiert Dateien hinein oder führt Befehle aus und friert das Ergebnis ein.

2:26 Die andere Gruppe verändert gar nichts, sie notiert nur eine Absicht für später: unter welcher Kennung der Prozess laufen soll, welcher Port gemeint ist, welches Programm starten soll. Genau diese zweite Gruppe wird am häufigsten missverstanden. Und eine Empfehlung aus der Praxis: Nehmen Sie COPY, wo Sie nicht ausdrücklich ein Archiv entpacken wollen.

2:46 Weniger Magie bedeutet weniger Überraschungen. Diese beiden Anweisungen sind der klassische Stolperstein, und das Bild dazu ist ein Werkzeug mit Voreinstellung. ENTRYPOINT ist das Werkzeug selbst — es bleibt, was es ist. CMD ist die Voreinstellung, die jeder beim Aufruf überschreiben darf. Zusammen ergibt das etwas Praktisches: einen Dienst, der ohne Argumente sinnvoll startet und sich trotzdem gezielt umsteuern lässt, etwa für einen Wartungsbefehl.

3:12 Der zweite Punkt ist noch wichtiger und betrifft den Betrieb: Schreibt man die Anweisung mit Klammern, startet der Prozess direkt und bekommt Stopp-Signale mit. Ohne Klammern hängt eine Shell davor, die das Signal verschluckt — und der Container stirbt nicht, er wird nach Ablauf einer Frist erschlagen. Alle vier Punkte haben denselben Ursprung: Man hält eine Anweisung für stärker, als sie ist — oder für harmloser.

3:36 EXPOSE klingt nach einer Freigabe, ist aber nur ein Vermerk; veröffentlicht wird ein Port erst beim Start. Viele einzelne RUN-Zeilen wirken übersichtlich, erzeugen aber unnötige Schichten. Und der teuerste Irrtum betrifft Zugangsdaten: Ein Image ist ein Stapel von Schichten, und wer ein Passwort hineinkopiert und später löscht, hat es nicht entfernt, sondern nur verdeckt — es bleibt in der Schicht darunter nachlesbar.

4:00 Der letzte Punkt ist reine Gewohnheitssache: Ohne USER läuft Ihr Dienst als Administrator, und dafür gibt es selten einen guten Grund.

Schichten, Build-Kontext und Caching

4:08 Jetzt wird es praktisch spürbar. Derselbe Build kann drei Sekunden dauern oder drei Minuten — und der Unterschied liegt nicht an der Maschine, sondern an der Reihenfolge Ihrer Anweisungen. Hier entscheidet sich, ob Ihre Pipeline später angenehm oder zäh ist. Ein Image ist ein Stapel unveränderlicher Schichten, ungefähr wie Folien auf einem Overheadprojektor: Jede legt etwas oben drauf, keine verändert die darunter.

4:33 Beim Bauen fragt die Maschine für jede Anweisung, ob sie eine passende Schicht schon kennt — und übernimmt sie dann einfach. Passt eine Schicht nicht mehr, wird sie neu gebaut, und mit ihr alles, was darauf liegt. Das ist die ganze Mechanik, und sie erklärt beide Beobachtungen aus dem Alltag: den blitzschnellen Build und den, der plötzlich alles neu macht.

4:53 Dazu kommt der Build-Kontext — das Verzeichnis, das Sie beim Bauen übergeben. Nur daraus kann kopiert werden. Hinter dieser Tabelle steht eine einzige Regel: Der Cache greift bis zur ersten Abweichung und ab dort nicht mehr. Alles darüber bleibt erhalten, alles darunter wird neu gebaut. Deshalb hat auch das Vertauschen zweier Anweisungen Folgen, die zunächst unlogisch wirken.

5:16 Bemerkenswert ist die letzte Zeile, und sie ist mehr als eine Randnotiz: Es zählt der Inhalt einer Datei, nicht ihr Zeitstempel. Wer eine Datei speichert, ohne sie zu ändern, löst nichts aus. Das klingt nach einer Kleinigkeit, ist aber die Voraussetzung dafür, dass Builds reproduzierbar sind — zweimal dasselbe hinein ergibt zweimal dasselbe heraus.

5:37 Diese wenigen Zeilen sind eine der wirksamsten Optimierungen im ganzen Modul, und sie kostet nichts außer Aufmerksamkeit. Das Prinzip: Was sich selten ändert, liegt vorn. Was sich oft ändert, liegt hinten. Abhängigkeiten wandern also mit den Paketdateien nach oben, und die Installation gleich dahinter — beides bleibt im Cache, solange niemand ein Paket hinzufügt.

5:59 Der eigene Quellcode kommt zuletzt, denn er ändert sich zwanzigmal am Tag. Drehen Sie die Reihenfolge um, und jede Änderung an einer Zeile Ihres Codes installiert wieder alle Pakete neu. Behalten Sie das Bild im Kopf: selten unten, oft oben. Der rote Faden dieser fünf Schritte ist eine schlichte Einsicht: Der gesamte Build-Kontext wandert zur Bau-Maschine, bevor die erste Anweisung überhaupt läuft.

6:23 Alles, was dort nichts zu suchen hat, kostet also bei jedem Build Zeit. Deshalb beginnen wir mit einer Messung — der Build meldet die Kontextgröße von selbst, man muss nur hinsehen. Dann schließen wir das Offensichtliche aus: Versionsverwaltung, installierte Abhängigkeiten, Build-Artefakte, Protokolle, lokale Konfiguration.

6:42 Danach messen wir erneut und vergleichen. Und der letzte Schritt ist der eigentlich wichtige: Das Ergebnis gehört ins Repository. Sonst ist es Ihre persönliche Optimierung und nicht die des Teams. Diese vier Fehler kosten selten Korrektheit, aber viel Zeit — und Zeitverluste werden erstaunlich lange hingenommen. Wer den Build im Wurzelverzeichnis eines großen Projekts startet, überträgt womöglich Hunderte Megabyte, ohne es zu merken.

7:08 Fehlt die Ausschlussliste, kippt schon eine lokal installierte Abhängigkeit dauernd den Cache. Der dritte Punkt ist heimtückischer: Wer Paketlisten und Installation auf zwei Anweisungen verteilt, friert einen alten Stand ein und installiert später Veraltetes aus dem Cache. Und der vierte trifft alle irgendwann — man verlässt sich auf den Cache, während darunter ein bewegliches Basis-Tag liegt, das sich jederzeit ändern darf.

7:32 Jetzt sind Sie dran, und das Ziel ist bewusst eine Einschätzung, nicht ein Rezept: Sie sollen vorher sagen können, welche Ihrer Anweisungen einen Neubau auslöst — und die Reihenfolge danach ausrichten. Geschafft ist die Aufgabe, wenn eine Änderung an einer einzigen Quelldatei nur noch die Schichten ab dem Quellcode-Schritt neu baut und die Paketinstallation unangetastet aus dem Cache kommt.

7:54 Wer schneller fertig ist, nimmt zusätzlich die Kontextgröße vor und nach der Ausschlussliste. Und ein Tipp: Schätzen Sie die Ersparnis, bevor Sie messen. Der Abstand zwischen Schätzung und Messung ist hier der eigentliche Lerneffekt.

Multi-Stage Builds

8:07 Kommen wir zum größten einzelnen Hebel dieses Moduls. Die Idee dahinter ist denkbar einfach und wird trotzdem oft nicht genutzt: Bauen und Ausliefern sind zwei verschiedene Aufgaben — und deshalb dürfen sie auch in zwei verschiedenen Umgebungen stattfinden. Denken Sie an eine Werkstatt und einen Lieferwagen. In der Werkstatt liegen Werkbank, Werkzeug, Sägespäne — alles, was zum Bauen nötig ist.

8:30 Im Lieferwagen liegt am Ende nur das fertige Möbelstück. Genau das erlaubt ein Dockerfile mit mehreren FROM-Anweisungen: Jede eröffnet eine eigene Etappe mit eigenem Basis-Image, und aus einer früheren Etappe holen Sie gezielt einzelne Dateien in die nächste. Alles andere bleibt zurück. Im ausgelieferten Image landet nur, was zur Laufzeit gebraucht wird.

8:51 Übersetzer, Testwerkzeuge, Zwischenstände und Quellcode bleiben draußen — nicht weil man sie löscht, sondern weil sie nie mitkommen. Hier sehen Sie das Muster in seiner Reinform. Die erste Etappe bekommt einen Namen und darf alles haben: das große Basis-Image, den vollständigen Quellcode, alle Entwicklungsabhängigkeiten. Sie baut, und dann ist sie fertig.

9:13 Die zweite Etappe startet vom schlanken Basis-Image und holt genau eine Sache herüber — das Ergebnis des Bauens. Achten Sie auf die Denkweise dahinter: Sie räumen nicht hinterher auf, Sie nehmen von Anfang an nur mit, was Sie brauchen. Aufräumen in einer späteren Schicht bringt nämlich nichts, die Dateien bleiben in der Schicht darunter liegen.

9:33 Die Werkstatt darf beliebig unordentlich sein — sie wird nie ausgeliefert. Der Größenvorteil ist der offensichtliche Gewinn, aber er ist nicht der größte. Interessanter sind die drei Nebenwirkungen. Erstens: Was nicht im Image ist, kann auch nicht als Schwachstelle gemeldet werden — Ihr wöchentlicher Scan-Bericht wird kürzer, und zwar dauerhaft.

9:53 Zweitens: Kleine Images werden schneller übertragen und starten im Cluster früher, was bei automatischer Skalierung plötzlich Geld und Reaktionszeit bedeutet. Drittens, und das wird oft unterschätzt: Ohne Übersetzer, Paketverwaltung und Shell wird ein Einbruch deutlich unbequemer, weil im Container nichts liegt, womit man weiterarbeiten könnte.

10:13 Und ganz nebenbei zeigt Ihr Bauplan jetzt schwarz auf weiß, was zur Laufzeit wirklich nötig ist. Diese Tabelle ist keine Rangliste, sondern eine Achse — und auf ihr tauschen Sie Bequemlichkeit gegen Angriffsfläche. Oben die vollständige Distribution: alles da, groß, komfortabel im Fehlerfall. Unten Scratch: leer, winzig, und nur für Programme geeignet, die wirklich nichts brauchen.

10:37 Dazwischen liegen die interessanten Kompromisse. Bei Alpine lohnt der Hinweis, dass dort eine andere Standardbibliothek arbeitet — meist unproblematisch, gelegentlich überraschend. Und Distroless verdient einen ehrlichen Satz: Es gibt dort keine Shell. Sie können sich also nicht mehr in den laufenden Container schalten und nachsehen.

10:57 Das ist Absicht, es ist ein Sicherheitsgewinn, und es ist ein Preis. Entscheiden Sie bewusst. Diese Übung ist bewusst mit einer Zahl versehen, damit sie nicht im Gefühl endet. Zerlegen Sie den Bauplan in eine Bau- und eine Laufzeit-Etappe und beschränken Sie die Übernahme auf das Nötige. Geschafft ist es, wenn der Dienst sich unverändert verhält und das Image messbar unter der Hälfte der Ausgangsgröße liegt.

11:21 Für unsere Beispiel-API ist die Zielmarke unter hundert Megabyte — das ist realistisch und nicht sportlich gemeint. Notieren Sie die Größe vorher und nachher. Ohne die beiden Zahlen bleibt die Verbesserung eine Behauptung, und genau solche Behauptungen halten sich später hartnäckig in Diskussionen. Der erste Fehler ist der häufigste und der bitterste: Man baut brav zwei Etappen und übernimmt dann aus Bequemlichkeit das ganze Arbeitsverzeichnis — und verschenkt damit exakt den Gewinn, für den man die Arbeit gemacht hat.

11:50 Der zweite ist ein klassischer Nachmittagsfehler: Die schlanke letzte Etappe hat womöglich keine Zeitzonendaten und keine Wurzelzertifikate, und dann scheitert plötzlich jede verschlüsselte Verbindung nach außen. Die letzten beiden Punkte sind zwei Seiten derselben Sache: Wer eine schlanke Basis wählt, muss ihre Eigenheiten testen — bei Alpine die abweichende Standardbibliothek, bei Distroless die fehlende Untersuchbarkeit.

12:12 Beides erfahren Sie sonst zum schlechtesten Zeitpunkt.

Der OCI-Standard

12:16 Ein kurzes, aber tragendes Kapitel. Wir haben bisher von Docker gesprochen, als wäre es die Technologie selbst. Ist es nicht — es ist ein Werkzeug für ein offenes Format. Diese Unterscheidung ist die Grundlage dafür, dass wir im nächsten Modul überhaupt eine Wahl haben. Die Open Container Initiative, kurz OCI, hat aufgeschrieben, was vorher Absprache war: wie ein Image aufgebaut ist, wie daraus ein laufender Prozess wird und wie Registries beides übertragen.

12:44 Der Vergleich, der hier gut trägt, ist der Schiffscontainer. Seine Maße sind genormt, und deshalb ist es gleichgültig, welcher Kran ihn hebt und welches Schiff ihn fährt. Genauso können Sie ein Image mit einem Werkzeug bauen und mit einem völlig anderen betreiben. Das ist keine akademische Feinheit — es ist der Grund, warum ein Wechsel der Werkzeugkette später eine Entscheidung ist und kein Bruch.

13:07 Drei Spezifikationen, und sie beschreiben genau die drei Momente im Leben eines Images. Erstens: wie es aussieht, wenn es herumliegt — Schichten, Konfiguration, Manifest. Zweitens: wie daraus ein laufender Prozess wird, also der Übergang von Datei zu Programm. Und drittens: wie es zwischen Maschinen reist, also das Gespräch mit der Registry.

13:28 Wenn Sie sich diese Dreiteilung merken, können Sie Werkzeuge viel leichter einordnen — jedes bedient eine oder zwei dieser Stellen. Alle drei Spezifikationen sind offen und werden von den gängigen Werkzeugen gemeinsam getragen, und genau diese Gemeinsamkeit ist das, was den Standard tatsächlich wirksam macht. Was heißt das nun konkret an einem Dienstagmorgen? Vor allem: Sie behalten die Beweglichkeit. Ein hier gebautes Image läuft ohne Umbau auf einem Cluster mit anderer Laufzeit.

13:58 Die Registry ist austauschbar, weil die Übertragung festgeschrieben ist — ein Umzug ist Arbeit, aber kein Umbau Ihrer Anwendungen. Und Werkzeuge lassen sich einzeln ersetzen statt als ganze Kette. Der Punkt, den ich am wichtigsten finde, ist der letzte: Ihr Bauplan bleibt eine Investition, auch wenn das Bauwerkzeug wechselt.

14:17 In einem Feld, das sich so schnell bewegt, ist das eine bemerkenswert beruhigende Eigenschaft. Der Standard schützt Sie nicht davor, ihn zu verlassen — und das passiert meist aus Bequemlichkeit. Wer eine praktische Herstellerbesonderheit im Bauplan nutzt, gibt die Austauschbarkeit stillschweigend auf, oft ohne es zu dokumentieren.

14:37 Der zweite Punkt ist ein häufiges Missverständnis: Gleiches Format bedeutet nicht gleiche Voreinstellungen. Rechte, Netzwerkverhalten und Standardnutzer können sich zwischen Laufzeiten unterscheiden, und genau das erleben wir im nächsten Modul praktisch. Und der dritte Punkt kostet inzwischen viele Teams einen Nachmittag: Ein Image trägt eine Prozessorarchitektur.

14:58 Wer auf einem ARM-Notebook baut und auf x86-Servern ausliefert, merkt es erst beim Start.

Registries, Tags und Digests

15:04 Jetzt zu einem Kapitel, das harmlos aussieht und überraschend viele Produktionsvorfälle erklärt. Es geht um Namen und um Prüfsummen — und um den Unterschied zwischen etwas, das sich ändern darf, und etwas, das sich nicht ändern kann. Eine Registry ist das Lager, und dort liegen Images unter einem Repositorienamen. Interessant sind die beiden Arten, sie anzusprechen.

15:26 Ein Tag ist ein Schild, das man umhängen kann: Heute zeigt es auf diese Fassung, morgen darf es auf eine andere zeigen. Ein Digest ist die Prüfsumme des Manifests — er benennt genau eine Fassung, und zwar für immer. Beides hat seinen Platz, nur nicht denselben. Das Schild ist zum Lesen und Veröffentlichen gedacht, die Prüfsumme zum verlässlichen Wiederfinden.

15:48 Wer sie verwechselt, bekommt ein System, das gestern noch funktionierte und heute etwas anderes startet. Lesen Sie diese Tabelle als eine einzige Abwägung: Lesbarkeit gegen Verbindlichkeit. Ein Tag ist bequem, weil ein Mensch ihn sich merken kann — und riskant, weil er beweglich ist. Ein Digest ist unhandlich, weil niemand vierundsechzig Hexadezimalzeichen im Kopf behält — und genau deshalb verlässlich.

16:12 Die letzte Zeile ist die technisch entscheidende: Nur beim Digest kann die Maschine beim Herunterladen nachrechnen, ob sie wirklich das bekommen hat, was gemeint war. Daraus ergibt sich die Faustregel, die Sie mitnehmen sollten und die in der Praxis fast immer trägt: mit Tags veröffentlichen, mit Digests deployen. Diese drei Befehle sind der praktische Kern der Faustregel.

16:34 Sie bauen unter einem lesbaren Versions-Tag, Sie veröffentlichen ihn — und dann fragen Sie nach, welche Prüfsumme dabei entstanden ist. Genau dieser letzte Schritt fehlt in den meisten Pipelines, und deshalb bleibt die gute Absicht dort eine Absicht. Denken Sie an den Digest wie an die Sendungsnummer eines Pakets: Der Empfängername steht auf dem Karton, aber nachvollziehbar wird die Lieferung erst über die Nummer.

16:57 Der ausgegebene Wert ist es, der ins Deployment gehört — nicht der Tag, mit dem Sie gerade veröffentlicht haben. Der rote Faden hier ist Arbeitsteilung: Menschen brauchen Namen, Maschinen brauchen Prüfsummen — und beide sollen glücklich werden. Also vergeben wir je Veröffentlichung einen unveränderlichen Versions-Tag, und daneben einen beweglichen Zeiger auf die jeweils neueste Fassung, damit man bequem ausprobieren kann.

17:22 Dann hält die Pipeline den Digest fest, und das Deployment referenziert ausschließlich darüber. Schritt fünf ist die unromantische Hausarbeit: Aufräumregeln, denn eine Registry wächst sonst unbegrenzt. Und beachten Sie die Abhängigkeit zwischen den Schritten: Ohne Schritt drei ist Schritt vier von Hand nicht durchzuhalten. Genau daran scheitern die meisten guten Vorsätze.

17:43 Diese Übung hat einen kleinen dramaturgischen Kniff, deshalb verrate ich das Ergebnis nicht. Ihre Aufgabe: ein Image veröffentlichen und es anschließend so referenzieren, dass die Fassung eindeutig bleibt. Der Erfolg zeigt sich daran, dass der Dienst aus einer Digest-Referenz startet — und dass ein neu gesetzter gleichnamiger Tag daran nichts ändert.

18:03 Setzen Sie zur Probe genau das um: denselben Tag auf ein anderes Image zeigen lassen und neu starten. Was dann passiert, ist der Moment, an dem dieses Kapitel einrastet. Es ist genau der Effekt, den Sie in Produktion haben wollen — und den Sie sonst nie bekommen. Vier Fallen, und jede hat schon Nachtschichten verursacht.

18:23 Der bewegliche Standard-Tag in der Produktion ist der Klassiker: Alles läuft, bis irgendwer etwas Neues veröffentlicht und ein Neustart plötzlich eine andere Anwendung hochzieht. Der zweite ist schlimmer, weil er die Nachvollziehbarkeit zerstört — wer denselben Versions-Tag zweimal überschreibt, kann später nicht mehr sagen, welcher Quellstand eigentlich lief.

18:43 Der dritte ist Alltag geworden: Anonyme Zugriffe auf öffentliche Registries laufen in Ratenbegrenzungen, und zwar zuverlässig am Releasetag. Und der vierte trifft, wer bei knappem Plattenplatz aufräumt: Alte Schichten sind oft geteilt, und neue Images verweisen noch darauf.

BuildKit und Buildx

18:58 Zum Abschluss ein Kapitel mit einer angenehmen Pointe: Das meiste davon läuft bei Ihnen wahrscheinlich schon, ohne dass es jemand eingeschaltet hätte. Nur genutzt wird es selten bewusst — und genau dort liegen noch einige Sekunden und ein Stück Sicherheit. BuildKit ist das moderne Bau-Backend, und sein Trick ist eine Umstellung der Sichtweise. Der alte Weg arbeitete das Dockerfile wie eine Liste von oben nach unten ab.

19:22 Der neue betrachtet es als Abhängigkeitsgraph, erkennt also, welche Anweisungen einander gar nicht brauchen, und erledigt sie gleichzeitig. Dazu kommen zwei Fähigkeiten, die im Alltag viel wert sind: Zwischenspeicher, die einzelne Bauvorgänge überdauern, und Geheimnisse, die beim Bauen verfügbar sind, ohne im Ergebnis zu landen.

19:40 Buildx ist die Bedienoberfläche dazu und verwaltet mehrere Bau-Umgebungen — auf dem Notebook genauso wie auf einem entfernten Bau-Server. Drei dieser vier Punkte sind Tempo, einer ist Sicherheit — und die Reihenfolge sagt etwas über die Wahrnehmung. Nebenläufigkeit merkt man sofort, weil der Build kürzer wird. Zwischenspeicher, die den einzelnen Bauvorgang überleben, merkt man am zweiten Lauf, und in der Pipeline sind sie oft der größte Gewinn überhaupt.

20:07 Mehrere Prozessorfamilien in einem Durchgang lösen ein Problem, das mit ARM-Servern und ARM-Notebooks erst richtig entstanden ist. Der Punkt mit den Geheimnissen wird am wenigsten beachtet und ist der wichtigste: Er verändert nicht Ihre Bauzeit, sondern was Sie ausliefern. Zwei Zeilen, und dahinter steht ein hübscher Gedanke.

20:26 Bisher hatten wir die Wahl zwischen zwei unangenehmen Varianten: Entweder liegt der Paket-Cache im Image, dann bläht er es auf. Oder er liegt nicht im Image, dann wird bei jedem Build alles neu heruntergeladen. Ein Cache-Mount löst das, indem er den Speicher daneben legt statt darin — er ist beim Bauen verfügbar und wandert nicht ins Ergebnis.

20:46 Merken Sie sich das Muster: Was Sie beim Bauen brauchen, aber nicht ausliefern wollen, gehört an einen Mount. Genau dasselbe Prinzip gilt gleich für Geheimnisse. Hier steht die Antwort auf ein Problem, das vor wenigen Jahren kaum jemand hatte: Entwickelt wird zunehmend auf ARM-Notebooks, betrieben oft auf x86-Servern — und manchmal auch umgekehrt.

21:07 Ein einzelner Aufruf mit der Angabe beider Plattformen baut für beide und veröffentlicht das Ergebnis gemeinsam. Was dabei entsteht, ist der eigentlich interessante Teil: eine Manifest-Liste, also ein Verzeichnis, das auf mehrere Images zeigt. Beim Herunterladen sucht sich jede Maschine ihre Architektur selbst heraus. Für Sie heißt das: ein Tag, ein Digest, ein Deployment — und trotzdem passt es überall.

21:32 Diese fünf Schritte sind eine Reihenfolge mit Absicht. Wir beginnen mit einer Bestandsaufnahme, weil viele überrascht sind, welches Backend tatsächlich läuft. Dann legen wir eine eigene Bau-Umgebung an, die mehrere Architekturen bedienen kann. Danach kommen die Zwischenspeicher für wiederkehrende Downloads und die Überführung von Zugangsdaten in Geheimnisse.

21:53 Zuletzt messen wir die Bauzeit gegen den Ausgangswert, damit die Umstellung belegt ist und nicht nur behauptet. Und beachten Sie die Gewichtung: Nur Schritt vier verändert Ihre Sicherheitslage. Die anderen vier sind Tempo — angenehm, aber ersetzbar. Wenn Sie nur einen Schritt gehen, gehen Sie den vierten. Die neuen Möglichkeiten bringen neue Annahmen mit, und Annahmen sind das Problem.

22:15 Cache-Mounts sind wunderbar auf dem eigenen Rechner — auf einem frischen Bau-Container in der Pipeline sind sie leer, und wer damit rechnet, plant zu optimistisch. Der zweite Punkt ist ein echter Sicherheitsfehler und passiert trotzdem oft: Zugangsdaten als Bau-Argument zu übergeben, weil es einfacher ist. Sie bleiben in der Bau-Historie sichtbar — dafür gibt es Geheimnisse. Der dritte ist beinahe zwangsläufig: Man baut für zwei Architekturen und testet eine.

22:41 Und der vierte ist Betriebsalltag: Ein unbegrenzter Zwischenspeicher füllt irgendwann die Platte der Bau-Maschine.

Was ab hier trägt

22:49 Vier Sätze, die den Rest des Seminars vorbereiten. Der Bauplan ist versionierte Dokumentation Ihrer Laufzeitumgebung — nutzen Sie ihn so und lesen Sie ihn im Review mit. Die Reihenfolge der Anweisungen ist keine Stilfrage, sie ist Ihre Bau-Geschwindigkeit. Getrennte Bau- und Laufzeit-Etappen sind der größte Hebel auf Größe und Angriffsfläche zugleich.

23:10 Und die Faustregel für alles Weitere: veröffentlicht wird mit Tags, deployt wird mit Digests. Im nächsten Modul stellen wir das Werkzeug selbst zur Debatte. Wir haben gelernt, dass das Format offen ist — jetzt sehen wir uns an, welche Wahl daraus praktisch folgt: Docker, Podman, oder beides.