Container-Images, Packages und Releases

Container-Images, Packages und Releases

0:00 Wir haben eine geprüfte Anwendung. Jetzt machen wir daraus etwas, das man ausliefern kann. Das Artefakt ist das Bindeglied zwischen Prüfung und Produktion — und der Ort, an dem sich entscheidet, ob Ihre ganze Prüfkette überhaupt etwas wert ist. In diesem Modul bauen wir ein Container-Image, veröffentlichen es in der Registry, die direkt neben dem Repository liegt, und leiten aussagekräftige Tags daraus ab.

0:24 Und wir behandeln das Prinzip, das den Rest des Seminars trägt: einmal bauen, überall ausrollen. Es klingt banal und wird trotzdem ständig verletzt.

Container-Images, Packages und Releases

0:33 Drittes Modul des zweiten Tages. Erst das Handwerk — anmelden, bauen, veröffentlichen. Dann die Frage der Benennung, die überraschend viel mit Nachvollziehbarkeit zu tun hat. Und zum Schluss das Prinzip dahinter. Am Ende liegt ein Image der Beetkarte in der Registry, dessen Herkunft Sie jederzeit bestimmen können — die Grundlage für die Attestationen am dritten Tag.

Images bauen und veröffentlichen

0:56 Fangen wir mit dem einfachsten Teil an. Die Registry liegt direkt neben Ihrem Repository, und die Anmeldung braucht kein einziges zusätzliches Geheimnis. Die GitHub Container Registry nimmt Images desselben Repositories auf, und das Bequeme daran: Sie melden sich mit dem Token an, das jeder Job ohnehin bekommt. Kein zusätzliches Geheimnis, kein Zugangsschlüssel, der irgendwo abläuft. Voraussetzung ist eine einzige Berechtigung — der Job braucht Schreibrecht auf Pakete.

1:25 Und hier ist die Falle: Ohne diese Berechtigung gelingt die Anmeldung noch, erst der Push scheitert. Sie merken den Fehler also am Ende eines möglicherweise langen Builds, nicht am Anfang. Das ist eine der Stellen, an denen sich Least Privilege unbequem anfühlt — zu Recht. Sechs Zeilen, und drei davon sind bemerkenswert. Der Benutzername kommt aus dem Kontext, also aus der Person oder dem Vorgang, der den Lauf ausgelöst hat.

1:51 Das Passwort ist das automatisch bereitgestellte Token — nichts, was Sie hinterlegen mussten, und nichts, was jemand stehlen und dauerhaft nutzen könnte, denn es lebt nur für die Dauer des Jobs. Und oben die Berechtigungen: Lesen für den Code, Schreiben für die Pakete. Genau so viel und nicht mehr. Wir vertiefen dieses Muster in Modul zwölf.

2:12 Zwei Schritte, die gut zusammenspielen. Der erste leitet aus dem auslösenden Ereignis passende Tags und Beschriftungen ab — bei einem Push auf den Hauptbranch andere als bei einem Versions-Tag. Das nimmt Ihnen genau die Fallunterscheidung ab, die man sonst mühsam von Hand baut. Der zweite baut und schiebt in einem Zug. Achten Sie auf die Kennung am zweiten Schritt: Er gibt den Digest des Images aus, also den kryptografischen Fingerabdruck.

2:38 Den brauchen wir am dritten Tag für den Herkunftsnachweis — merken Sie sich diese Stelle. Der erste Punkt ist der häufigste und der ärgerlichste: Ein Image mit dem Tag latest, und drei Wochen später weiß niemand mehr, welcher Commit darin steckt. Der zweite kostet Zeit — ein Image-Build ohne Cache dauert oft länger als alle Tests zusammen.

2:57 Der dritte betrifft Multi-Architecture-Builds, die schnell aktiviert und selten wirklich gebraucht werden; sie verdoppeln die Laufzeit. Und der vierte ist eine Frage der Hygiene: Wenn jeder Push ein Image veröffentlicht, füllt sich die Registry mit Ständen, die nie jemand ausrollt.

Tags, Versionen und Releases

3:14 Jetzt zur Benennung. Das klingt nach einem Nebenthema und ist in Wahrheit die Frage, ob Sie im Ernstfall wissen, was gerade läuft. Ein Tag ist ein Name, ein Digest ist eine Identität. Dieser Unterschied ist der Kern des Kapitels. Tags lassen sich verschieben — dasselbe Wort kann morgen auf ein anderes Image zeigen. Der Digest nicht, er ist der Fingerabdruck des Inhalts.

3:36 Für den Menschen sind Tags gedacht, für die Maschine der Digest. Ein Release wiederum bündelt einen Git-Tag mit Notizen und Dateien zum Herunterladen, und semantische Versionierung macht aus der Nummer eine Aussage: Was ändert sich, und muss ich beim Aktualisieren aufpassen? Vier Tags, vier Zwecke — und Sie brauchen tatsächlich mehrere gleichzeitig. Der erste ist bequem zum Ausprobieren und für alles andere ungeeignet.

4:02 Der zweite ist der, den Sie in Produktion referenzieren. Der dritte, aus Branch und Commit, ist Ihr bester Freund bei der Fehlersuche: Er sagt Ihnen ohne Umweg, welcher Stand da läuft. Der vierte ermöglicht Vorschauumgebungen je Pull Request. Und die Fußzeile enthält die Regel, die Sie sich merken sollten: Für ein Deployment zählt am Ende der Digest.

4:24 Ein Release ist nicht die Ablage von Dateien, sondern eine Nachricht an die Nutzenden. Die Versionsnummer sagt, wie riskant die Aktualisierung ist. Die Notizen beschreiben Änderungen aus deren Sicht — nicht aus Ihrer. Das ist der Punkt, an dem viele Releases scheitern: Eine Liste von Commit-Nachrichten ist kein Changelog, sondern ein Protokoll Ihrer Arbeit.

4:45 Die Artefakte sollten installierbar sein, ohne dass jemand nachbaut. Und der Verweis auf das Image schließt den Kreis, damit klar ist, welcher Container zu welcher Version gehört. Der erste Punkt begegnet einem oft: dieselbe Version an drei Stellen, dreimal verschieden. Genau deshalb haben wir in Modul vier gelernt, sie einmal zu ermitteln und weiterzureichen.

5:07 Der zweite verletzt die Reproduzierbarkeit — ein Release aus einem Branch beschreibt keinen festen Stand. Der dritte ist der Changelog-Punkt von eben. Und der vierte ist der gefährlichste: Ein verschobener Tag ändert rückwirkend, was ein ausgelieferter Stand bedeutet. Wenn Ihre Produktion auf einen Tag zeigt, haben Sie damit unbemerkt die Software getauscht.

Build once, deploy many

5:28 Zum Abschluss das Prinzip, auf dem alles aufbaut, was am dritten Tag folgt. Es ist einfach zu formulieren und im Alltag erstaunlich schwer durchzuhalten. Ein Artefakt entsteht genau einmal und wandert unverändert durch alle Stufen. Der Unterschied zwischen Staging und Produktion steckt in der Konfiguration, die zur Laufzeit dazukommt — nicht im Paket.

5:49 Stellen Sie sich einen Neuwagen vor: Es wird nicht für jede Testfahrt ein neuer gebaut, sondern derselbe fährt weiter. Wird in jeder Stufe neu gebaut, ziehen Sie womöglich andere Abhängigkeitsstände, und das Paket, das Sie geprüft haben, ist nicht mehr das, das ausgeliefert wird. Alle Testergebnisse gelten dann für etwas, das niemand je erhält.

6:10 Die Kette zeigt den Weg, und das Entscheidende sind die Pfeile: Zwischen ihnen wird nichts neu gebaut. Was in Staging läuft, ist bitweise dasselbe wie das, was danach in Produktion läuft. Das hat eine angenehme Konsequenz: Ein Rollback ist kein Bauvorgang mehr, sondern das Ausrollen eines vorhandenen Images — Sekunden statt Minuten, und ohne die Frage, ob die Abhängigkeiten von damals noch verfügbar sind.

6:33 Und es hat eine zweite: Der Herkunftsnachweis aus Modul vierzehn beschreibt genau ein Artefakt und begleitet es durch alle Stufen. Vier Konsequenzen, die alle aus derselben Ursache folgen. Der zweite Build zieht andere Stände — schon eine Patch-Version einer Abhängigkeit reicht. Die Prüfergebnisse gelten für ein Artefakt, das nie ausgeliefert wurde; damit ist die ganze Prüfkette Theater. Ein Rollback bräuchte einen erneuten Build, ausgerechnet im Notfall.

7:01 Und die Attestation hängt am Digest — ändert sich dieser, ist der Nachweis wertlos. Das ist der Grund, warum wir uns in Modul sechs die Mühe mit den Artefakten gemacht haben. Der erste Punkt ist der häufigste Verstoß und passiert aus Bequemlichkeit: Der Deployment-Workflow checkt aus und baut, weil das eben schon im Skript stand.

7:21 Der zweite ist ein Entwurfsfehler mit langen Folgen — Konfiguration im Image erzwingt je Umgebung ein eigenes Paket. Der dritte kostet Sie den Rückweg: Wird das Staging-Image nach dem Test überschrieben, gibt es nichts mehr, worauf man zurückgehen könnte. Und der vierte ist der subtilste: irgendein Schritt zwischen Prüfung und Deployment, der das Artefakt anfasst.

Übung

7:42 In der Übung veröffentlichen Sie ein Image der Beetkarte mit sprechenden Tags — und sichern den Digest, den wir am dritten Tag wieder brauchen. Das Ziel ist Nachvollziehbarkeit: Zu jedem Image in der Registry soll man sagen können, aus welchem Stand es gebaut wurde. Deshalb drei Tags — Branch, Commit-SHA und Version — statt einem. Ein Versions-Tag im Git erzeugt zusätzlich ein Release mit Notizen.

8:06 Und der Digest wird als Job-Ausgabe gesichert, genau wie die Versionsnummer in Modul vier. Zur Vertiefung können Sie eine Vorschauumgebung je Pull Request mit eigenem Tag versehen — das ist die Art von Komfort, die Reviews spürbar erleichtert. Die ersten drei Schritte sind das Handwerk aus dem ersten Kapitel. Schritt vier trennt Alltag und Release: Nur ein Tag im Git erzeugt einen Release, nicht jeder Push.

8:30 Und Schritt fünf ist ein Blick nach vorn — prüfen Sie, dass Ihr Deployment später wirklich dieses Image zieht und nicht doch irgendwo neu baut. Diese Kontrolle kostet zwei Minuten und ist der eigentliche Inhalt des Moduls. Alles andere ist Konfiguration; das hier ist die Entscheidung. Der erste Punkt untergräbt still die ganze Kette: Ohne gesicherten Digest referenziert das Deployment nur einen beweglichen Namen.

8:54 Der zweite ist der Release, der bei jedem Push entsteht und die Versionsliste unbrauchbar macht. Der dritte ist ein Aufräumthema, das nach ein paar Monaten sichtbar wird — Vorschau-Images summieren sich. Und der vierte ist ein Detail, das Sie garantiert einmal trifft: Image-Namen dürfen keine Großbuchstaben enthalten, und wenn Ihre Organisation welche im Namen hat, weist die Registry den Push ab.

9:17 Im nächsten Modul machen wir aus dieser Pipeline einen wiederverwendbaren Baustein.