Lokale Entwicklung mit Docker und Podman

Lokale Entwicklung mit Docker und Podman

0:00 Im ersten Modul haben wir gelernt, dass ein Image an ein offenes Format gebunden ist und nicht an ein Werkzeug. Das klang vielleicht wie eine Fußnote — in diesem Modul wird daraus eine praktische Entscheidung. Wir tauschen nämlich das Werkzeug aus. Podman macht dasselbe wie Docker, aber auf einem grundlegend anderen Weg: ohne zentralen Hintergrunddienst und ohne Administratorrechte.

0:22 Das klingt nach einer Detailfrage für Systemverwalter, ist aber eine, die Sie täglich betrifft — bei Rechten, beim Netzwerk, bei Compose, bei Ihrer Entwicklungsumgebung. Am Ende dieses Moduls sollen Sie nicht wissen, welche Engine besser ist, sondern welche für Ihr Team die richtige ist. Und das begründen können.

Zwei Architekturen, ein Standard

0:40 Beginnen wir mit dem, was man auf der Oberfläche kaum sieht. Sie tippen fast denselben Befehl, und Sie bekommen fast dasselbe Ergebnis — aber darunter entsteht ein völlig anderer Prozessbaum. Diese Unterscheidung ist der Schlüssel zu allem Weiteren in diesem Modul. Docker arbeitet nach einem Muster, das man aus der Systemwelt gut kennt: Ein Client nimmt Ihren Befehl an und schickt ihn an einen Hintergrunddienst, der die Arbeit tatsächlich erledigt — herkömmlich mit Administratorrechten.

1:09 Alle Container sind Kinder dieses einen Dienstes. Podman kehrt das um: Es gibt keinen solchen Dienst. Jeder Container wird direkt aus Ihrem Aufruf gestartet und bleibt ein Kindprozess Ihrer eigenen Sitzung. Denken Sie an ein zentrales Kraftwerk gegenüber einer Solaranlage auf jedem Dach. Und das Entscheidende: Beide erzeugen und betreiben Images nach demselben OCI-Standard.

1:31 Das Ergebnis ist identisch, nur der Weg dorthin ist ein anderer. Diese sechs Zeilen sind eigentlich eine einzige Konsequenz, sechsmal durchdekliniert: Es gibt keinen zentralen Dienst mehr. Daraus folgt alles Weitere fast von selbst. Wenn der Aufruf selbst ausführt, dann läuft es mit Ihren Rechten. Wenn Container Kinder Ihrer Sitzung sind, dann kann kein Dienst-Neustart sie mitnehmen — es gibt nichts, was neu starten könnte.

1:56 Und wenn alles an Ihrer Kennung hängt, dann sieht jede Person nur ihre eigenen Container. Das ist auf einem gemeinsam genutzten Bau-Server ein echter Gewinn und auf dem eigenen Notebook zunächst kaum spürbar. Einen Dienst kennt Podman übrigens auch — aber nur als optionale Zugabe für Werkzeuge, die einen erwarten. Der erste Punkt ist der, mit dem man in Sicherheitsgesprächen gewinnt: Die Mitgliedschaft in der Docker-Rechtegruppe ist faktisch Administratorzugriff auf die Maschine — jeder, der sie hat, kann das ganze Dateisystem einbinden.

2:28 Diese unangenehme Wahrheit fällt einfach weg. Der zweite Punkt ist Betriebsruhe: Was nicht existiert, kann nicht abstürzen und dabei alle Container mitnehmen. Der dritte ist der, den Systemverwalter schätzen — Container lassen sich wie normale Sitzungsdienste starten, überwachen und protokollieren, mit den vorhandenen Werkzeugen.

2:46 Und der vierte betrifft geteilte Maschinen: Zwei Personen arbeiten nebeneinander, ohne einander zu sehen oder zu stören. Diese Deckungsgleichheit ist keine Nachlässigkeit, sondern ausdrückliche Absicht: Podman ist bewusst so gebaut, dass die Befehle passen. Viele Teams gehen den letzten Schritt und richten sich das eine als das andere ein — ein Alias, und das Muskelgedächtnis darf bleiben.

3:09 Das ist bequem und für den Einstieg genau richtig. Nur sollten Sie wissen, wo diese Deckungsgleichheit endet, denn sie endet nicht bei den Befehlsnamen. Sie endet bei Rechten, beim Hintergrunddienst und beim Netzwerk. Genau diese drei Stellen arbeiten wir in den nächsten Kapiteln durch — und sie sind der Grund, warum ein Umstieg nicht allein mit einem Alias erledigt ist.

3:31 Alle vier Punkte entstehen aus derselben Verwechslung: Man hält gleiche Befehle für gleiches Verhalten. Die Rechtefrage ist dabei die wichtigste — dazu kommen wir gleich ausführlich. Der zweite Punkt ist einfach zu vermeiden und wird trotzdem übersehen: Schreiben Sie den Engine-Namen nicht in Skripte, sondern lesen Sie ihn aus einer Variable.

3:50 Dann kostet ein Wechsel eine Zeile statt eines Nachmittags. Der dritte überrascht auf Bau-Servern: Ihre Kollegin sieht Ihre Container nicht, und das ist kein Fehler, sondern das Feature. Und der vierte begleitet uns durchs ganze Modul — manche Werkzeuge wollen zwingend einen Hintergrunddienst ansprechen.

Rootless-Container

4:08 Jetzt kommen wir zum Kern dieses Moduls. Es ist gleichzeitig das stärkste Argument, das Sie im Team-Gespräch haben werden — und der Punkt, an dem der Groschen bei den meisten fällt. Im Container Verwalter sein, auf dem Rechner niemand Besonderes. Der Trick heißt Namensraum für Benutzer, und das Bild dazu ist ein Hotel mit eigener Zimmernummerierung.

4:29 Im Container gibt es eine Kennung Null, also den Verwalter — und Programme im Container glauben das auch. Auf dem Rechner wird diese Null aber auf eine hohe, völlig unprivilegierte Kennung abgebildet, etwa die Hunderttausend. Zimmer eins im Hotel ist also Zimmer hunderttausendeins im Stadtplan. Welche Bereiche dafür zur Verfügung stehen, steht in zwei Systemdateien.

4:50 Und hier liegt der praktische Unterschied: Podman arbeitet so von Haus aus, ohne dass jemand etwas tun muss. Docker kann das auch — muss dafür aber ausdrücklich eingerichtet werden. Diese Befehle macht man einmal je Kennung, und danach denkt man nie wieder darüber nach. Sie teilen einen Bereich zusätzlicher Kennungen zu — hier fünfundsechzigtausendfünfhundertsechsunddreißig davon, und das ist kein willkürlicher Wert, sondern die Größe eines vollständigen Kennungsraums.

5:18 Genau diese Nummern bilden nachher die Innenwelt Ihrer Container. Die dritte Zeile ist die eigentlich nützliche: Sie prüft nach, ob wirklich angekommen ist, was Sie gemeint haben. Und ein Hinweis, der schon viele Stunden gekostet hat: Ein Leerzeichen am Zeilenende dieser Dateien lässt den Eintrag stillschweigend ausfallen.

5:36 Kein Fehler, keine Meldung — es funktioniert einfach nicht. Der rote Faden dieser fünf Schritte: Wir bauen aus einem Systemdienst einen Sitzungsdienst. Zuerst die Hilfsprogramme für die Kennungsabbildung, dann die zusätzlichen Kennungen aus der vorigen Folie. Danach übernimmt das mitgelieferte Einrichtungsskript den unbequemen Teil.

5:55 Schritt vier ist der, den man am leichtesten vergisst und der am meisten Verwirrung stiftet: Ein Sitzungsdienst endet normalerweise mit der Abmeldung — und mit ihm alle Container. Deshalb muss die Sitzung ausdrücklich verweilen dürfen. Und Schritt fünf, die Socket-Adresse in der Umgebung, ist die Stelle, auf die wir in diesem Modul noch mehrfach zurückkommen. Sie ist die Brücke für alle fremden Werkzeuge.

6:18 Vier Zeilen, und jede erledigt genau einen der Schritte von vorhin. Interessant ist die dritte: Sie erlaubt Ihrer Sitzung, im System zu verweilen, auch wenn Sie sich abmelden. Ohne diese Zeile sind auf einem Bau-Server nach dem Ende der Sitzung alle Container weg — ein Verhalten, das man ohne Vorwarnung nur schwer einordnet.

6:37 Und ein Hinweis zur letzten Zeile: Die Zahl im Pfad ist Ihre eigene Kennung, auf einem anderen Rechner also eine andere. Tippen Sie sie nicht in Skripte, sondern lesen Sie sie aus der Umgebung. Sonst funktioniert Ihr Einrichtungsskript genau bei einer Person — bei Ihnen. Die erste Zeile ist die ehrlichste Zusammenfassung dieses Kapitels: Bei Docker ist rootless ein Weg, bei Podman ist es der Weg.

7:01 Beides führt zum Ziel, nur ist das eine ein bewusster Umbau und das andere die Voreinstellung. Die dritte und vierte Zeile sind es, die im Alltag stolpern lassen — und deshalb der Hinweis darunter mit Nachdruck: Rootless und rootful teilen niemals eine Ablage. Nach dem Umstieg sind Ihre alten Images nicht verschwunden, sie liegen nur in einer anderen Ablage, die die neue Betriebsart gar nicht ansieht. Wer das nicht weiß, sucht lange.

7:25 Und die zusätzlichen Kennungen braucht am Ende jede der beiden Engines. Diese Übung ist kurz, und ihr Ergebnis bleibt hängen. Sie sollen nachweisen, mit welchen Rechten ein Container tatsächlich auf dem Rechner läuft — nicht in ihm. Der Weg dahin: ein Verzeichnis vom Rechner einbinden, im Container als Verwalter eine Datei anlegen, und dann draußen nachsehen, wem sie gehört.

7:48 Sie wird Ihrer eigenen Kennung gehören, obwohl sie drinnen von Wurzel erzeugt wurde. Wer schneller fertig ist, wiederholt die Probe rootful und vergleicht. Genau dieser Vergleich ist der Moment, in dem das ganze Kapitel einrastet: dieselbe Datei, zwei völlig verschiedene Eigentümer — und damit zwei völlig verschiedene Risiken.

8:07 Die erste Falle ist die, in die alle tappen: Fehlen die zusätzlichen Kennungen, scheitert der Start mit einer Meldung, die niemandem hilft. Wenn Sie das Muster einmal kennen, erkennen Sie es sofort wieder. Der zweite Punkt ist die Kehrseite des schönen Sicherheitsgewinns — die Kennungsabbildung wirkt auch auf eingebundene Verzeichnisse, und Dateirechte verhalten sich deshalb überraschend.

8:29 Der dritte trifft Firmenumgebungen mit Heimverzeichnissen im Netz, wo die Image-Ablage nicht zuverlässig funktioniert; das gehört vorher geklärt. Und der vierte ist der Punkt von der Tabelle vorhin: Die alten Images sind da, nur woanders. Rechnen Sie mit dieser Frage am ersten Umstiegstag.

Netzwerk im rootless Betrieb

8:45 Jetzt kommt der ehrlichste Teil dieses Vergleichs. Bisher klang rootless nach einem Gewinn ohne Preis — das ist es nicht. Beim Netzwerk kostet der Verzicht auf Rechte etwas Messbares. Sehen wir uns an, was genau, und ob es Sie tatsächlich betrifft. Die Ursache ist eine harte Regel des Betriebssystems: Ohne Administratorrechte darf kein Prozess Netzwerkgeräte anlegen.

9:08 Also gibt es keine echte Brücke, über die der Verkehr laufen könnte. Stattdessen übernimmt ein Hilfsprogramm im Benutzerraum — es spielt Netzwerk nach, mit normalen Rechten. Seit Podman 5.0 ist das pasta, und das ist ein echter Fortschritt: Es arbeitet ohne Adressumschreibung, unterstützt IPv6 von sich aus und behält die Absenderadresse bei der Weiterleitung.

9:30 Der Vorgänger slirp4netns bleibt wählbar, falls Sie ihn brauchen. Merken Sie sich vor allem den Punkt mit der Absenderadresse — der ist im Alltag mehr wert, als er klingt. Diese Tabelle ist die Abrechnung, und sie fällt gemischt aus. Zwei Zeilen sind schlicht besser: Keine Adressumschreibung und eine erhaltene Absenderadresse sind ein Gewinn, nicht nur ein Ersatz.

9:51 Zwei Zeilen sind schlechter, und ich verschweige sie nicht: Ports unter tausendvierundzwanzig brauchen eine Freigabe, und der Durchsatz liegt bei etwa der Hälfte. Zu den Zahlen aber ein Warnhinweis, der wichtiger ist als die Zahlen selbst: Sie stammen aus einer einzelnen Messreihe. Nehmen Sie sie als Größenordnung, nicht als Zusage, und messen Sie im eigenen Aufbau nach, bevor Sie daraus eine Entscheidung ableiten.

10:15 Zwei Zeilen in einer Konfigurationsdatei — mehr ist es nicht, und genau das ist die gute Nachricht. Diese Datei liegt in Ihrem Heimverzeichnis und gilt für alle Ihre Container, unabhängig davon, welcher Befehl sie startet. Wer den Vorgänger braucht, weil ein bestimmter Aufbau darauf angewiesen ist, trägt hier den anderen Namen ein.

10:34 Behalten Sie diesen Ort im Kopf, denn wir kommen im Compose-Kapitel wieder auf ihn zurück — dieselbe Datei, andere Einstellung. Solche zentralen Stellen sind in einem Werkzeugkasten wie diesem angenehm selten, und deshalb lohnt es, sie sich zu merken. Hier stehen zwei Wege zum gleichen Ziel, und sie sind unterschiedlich klug.

10:53 Weg eins senkt die Grenze auf dem Rechner: Alles darf plötzlich niedrige Ports belegen — jeder Prozess, nicht nur Ihr Container. Das löst Ihr Problem und schwächt eine Schutzmaßnahme, die seit Jahrzehnten aus einem Grund existiert. Weg zwei veröffentlicht auf einem hohen Port und löst den Rest davor auf, etwa über einen Reverse Proxy oder einfach über eine andere Adresse im Browser.

11:15 Meine Einschätzung ist deutlich: Nehmen Sie Weg zwei. Er verändert die Einstellungen des Rechners nicht, und im Cluster stellt sich diese Frage später ohnehin anders. Ordnen wir die Zahl aus der Tabelle ein. Auf einem Arbeitsplatz ist die Netzwerkschicht so gut wie nie der Engpass — es begrenzt Ihre Anwendung, Ihre Datenbank, Ihre Festplatte.

11:35 Zehn Gigabit pro Sekunde sind auf einem Notebook eine theoretische Größe. Der zweite Punkt ist sogar ein aktiver Vorteil: Erhaltene Absenderadressen ersparen Ihnen Fehlersuche bei Zugriffsprotokollen und Sperrlisten, wo plötzlich alle Anfragen von derselben Adresse zu kommen scheinen. Und der dritte relativiert alles: Produktiv läuft Ihr Dienst im Cluster, auf einem völlig anderen Netzweg.

11:58 Wo Durchsatz wirklich zählt, bleibt rootful eine bewusste, begründete Ausnahme — nicht der Standard. Der erste Punkt ist der wichtigste, weil er ein ganzes Argument zerstört: Ein Messwert vom Arbeitsplatz sagt nichts über die Produktion, dort gilt ein anderer Netzweg. Wer damit gegen rootless argumentiert, argumentiert an der Sache vorbei.

12:17 Der zweite ist Alltag und begleitet uns ins nächste Kapitel: Ein festgeschriebener Port 80 im Compose-Aufbau stoppt den rootless Lauf sofort. Der dritte ist subtil — Container sprechen sich untereinander an, und die Adressvergabe funktioniert hier anders als gewohnt. Und der vierte ist der aus der Code-Folie: Die Portgrenze systemweit zu senken ist der bequeme Weg und der schlechtere.

Compose mit beiden Engines

12:40 Kommen wir zu dem Punkt, an dem die meisten Umstiege im Alltag tatsächlich hängen. Nicht an der Architektur, nicht am Netzwerk — an Compose. Denn kaum jemand startet einzelne Container; man startet einen Aufbau. Eine Datei, zwei Engines, und dazwischen ein Socket. Hier lohnt eine Klarstellung, die überrascht: Podman bringt keine eigene Compose-Umsetzung mit.

13:03 Der Befehl podman compose ist eine dünne Hülle — er richtet die Umgebung so ein, dass ein fremdes Compose-Werkzeug unbemerkt mit dem Podman-Socket spricht, und ruft es dann auf. Das ist eine bemerkenswert bescheidene Entscheidung: Statt eine zweite Umsetzung zu bauen, macht man die vorhandene benutzbar. Als Anbieter kommen zwei Programme in Frage, und docker-compose hat Vorrang, weil es die ursprüngliche Umsetzung ist und den größten Sprachumfang abdeckt.

13:28 Wenn Sie das verstanden haben, verstehen Sie auch die Fehlermeldungen, die Sie sonst ratlos lassen. Das hier sind die vier Zeilen, um die es in diesem Kapitel wirklich geht. Wir bitten Podman um seinen Dienst — jenen optionalen, den es eigentlich nicht braucht — und teilen der Umgebung mit, wo er zu erreichen ist. Und plötzlich funktioniert das originale Docker-Compose gegen Podman, ohne dass es etwas davon merkt.

13:53 Das Prinzip lohnt sich zu verinnerlichen: Jedes Werkzeug, das einen Docker-Hintergrunddienst erwartet, wird über genau diese eine Variable zufriedengestellt. Testcontainers greift darauf zu, lokale Cluster-Werkzeuge ebenso — die sehen wir am Ende dieses Moduls. Eine Adresse, viele Werkzeuge. Drei Wege, und das Sortierkriterium ist der Sprachumfang. Das originale docker-compose deckt am meisten ab, weil es die Referenz ist — hier entstehen neue Schlüssel zuerst.

14:21 Der zweite Weg ist die Hülle von vorhin, und er landet letztlich beim ersten. Der dritte ist eine eigenständige Umsetzung in Python, schlank und praktisch, aber sie deckt weniger Schlüssel ab. Wenn Ihr Aufbau exotische Optionen nutzt, merken Sie das dort zuerst. Ein Praxishinweis zur Hülle: Sie warnt bei jedem einzelnen Lauf, dass sie ein fremdes Programm aufruft.

14:43 Das ist korrekt und wird nach dem zwanzigsten Mal lästig — die nächste Folie stellt es ab. Zwei Zeilen, dieselbe Konfigurationsdatei wie im Netzwerk-Kapitel. Die erste nimmt Podman das Suchen ab: Statt selbst nach einem Anbieter zu forschen und den ersten zu nehmen, den es findet, bekommt es einen Pfad vorgegeben. Das ist mehr als Bequemlichkeit — es macht das Verhalten auf allen Rechnern im Team gleich, und genau das wollen Sie. Die zweite Zeile schaltet die Warnung ab.

15:11 Tun Sie das erst, wenn Sie sie verstanden haben; sie hat einen Zweck. Aber wenn Sie wissen, dass hier ein fremdes Programm aufgerufen wird und das genau die Absicht ist, darf sie schweigen. Der rote Faden: Schreiben Sie den Aufbau so, dass er keine Engine kennt. Schritt eins ist der entscheidende, und er ist reine Disziplin — keine Engine-Namen, keine festgeschriebenen Standardports.

15:34 Wir haben vorhin gesehen, warum: Ein Port 80 stoppt den rootless Lauf sofort, und dann diskutieren Sie über die Engine, wo Sie über eine Zeile diskutieren müssten. Danach der Socket, dann derselbe Aufbau zweimal gefahren. Schritt vier ist die eigentliche Arbeit: Notieren Sie die Abweichungen bei Rechten, eingebundenen Verzeichnissen und Namensauflösung — die kommen sonst einzeln und unerwartet.

15:57 Und Schritt fünf: Die Variable gehört in die Projektdokumentation, nicht in Ihr Gedächtnis. Diese Übung bringt das ganze Kapitel zusammen. Schreiben Sie einen mehrteiligen Aufbau aus unserer Beispiel-API und einer Datenbank so, dass er unter beiden Engines unverändert läuft. Geschafft ist es, wenn derselbe Aufbau mit docker compose und mit podman compose startet und die API in beiden Fällen tatsächlich aus der Datenbank antwortet.

16:22 Wer schneller fertig ist, misst die Zeit vom Start bis zur ersten Antwort für beide Läufe. Ein Hinweis, wo es spannend wird: Die Datenbank ist der interessante Teil. Sie braucht ein eingebundenes Verzeichnis, und genau daran scheitert es zuerst — Rechte, Kennungsabbildung, Kennzeichnung. Der erste Punkt ist das Missverständnis aus der Definition: Wer glaubt, podman compose bringe eine eigene Umsetzung mit, versteht die Meldung über den fehlenden Anbieter nicht.

16:49 Der zweite ist ein Klassiker bei Sitzungsdiensten — wird der Socket nicht dauerhaft aktiviert, greifen fremde Werkzeuge nach dem Abmelden ins Leere, und der Fehler wirkt zufällig. Der dritte betrifft Systeme mit erweiterten Sicherheitsmodulen: Ohne die passende Kennzeichnung schlägt das Einbinden von Verzeichnissen dort fehl.

17:06 Und der vierte ist eine Organisationsfalle, die ich häufig sehe: Zwei Compose-Dateien zu pflegen, scheint pragmatisch — bis die Unterschiede schleichend auseinanderlaufen und niemand mehr weiß, welche stimmt.

Devcontainers und Podman Desktop

17:18 Bis hierhin haben wir über Ihren eigenen Rechner geredet. Jetzt geht es um das Team — und um die Frage, wie ein Umstieg so ablaufen kann, dass die meisten Kolleginnen und Kollegen ihn gar nicht bemerken. Die Antwort liegt im Repository. Die Idee ist eine der besten der letzten Jahre: Die Entwicklungsumgebung ist selbst ein Container, und sie liegt neben dem Quellcode. Der Editor startet sie und arbeitet darin.

17:42 Kein „bei mir läuft es" mehr, kein halber Tag Einrichtung für neue Kollegen. Und welche Engine der Editor dafür aufruft, ist bloß eine Einstellung — der Pfad zum Kommando ist frei wählbar. Bei der Bewertung sollten wir aber genau bleiben: Die Dokumentation nennt Podman ab Fassung 5 als weitgehend deckungsgleich mit dem Docker-Client.

18:02 Offiziell unterstützt ist nur Docker selbst. Das funktioniert also gut, aber es steht Ihnen niemand dafür ein. Zwei Zeilen für den Umstieg — das ist tatsächlich alles, was der Editor braucht. Er ruft nicht Docker auf, sondern ein Kommando an einem konfigurierbaren Pfad, und den zeigen wir jetzt auf Podman. Wichtig ist der Hinweis darunter, und er ist eine Team-Regel, keine technische: Diese Einstellung gehört in Ihre persönliche Konfiguration und nicht ins geteilte Repository.

18:31 Denn sonst zwingen Sie Ihre gesamte Mannschaft auf Ihre Engine-Wahl — und sperren jeden aus, der noch bei Docker ist. Ins Repository gehört, wie die Umgebung aussieht. Womit sie gestartet wird, ist Sache jedes Einzelnen. Hier geht es nicht mehr um Engines, sondern um etwas Grundsätzlicheres. Der erste Punkt ist der spürbarste: Ein neues Teammitglied ist nach einem Klonen und einem Start arbeitsfähig — nicht nach einer halben Woche Einrichtung.

18:58 Der zweite macht Versionen überprüfbar statt mündlich überliefert. Der dritte ist der, der mich am meisten überzeugt und der am seltensten genannt wird: Die Umgebung wandert mit dem Zweig. Ein alter Stand baut mit seinen alten Werkzeugen, ganz von selbst. Wer je einen zwei Jahre alten Fehlerzweig wiederbeleben musste, weiß, was das wert ist.

19:17 Und insgesamt schrumpft der Abstand zwischen Arbeitsplatz und Bau-Maschine auf das Nötige. Die Lizenzzeile ist der Grund, warum viele Firmen dieses Thema überhaupt anfassen — Docker Desktop ist für größere Unternehmen kostenpflichtig, und das ist oft der Auslöser, nicht die Sicherheit. Podman Desktop steht unter Apache 2.0 und kann auch andere Engines bedienen, was es zu einem Werkzeug für gemischte Landschaften macht.

19:42 Interessant ist für uns die letzte Zeile: Ein laufender Aufbau lässt sich direkt als Kubernetes-Manifest ausgeben — dazu gleich mehr. Und ein nüchterner Satz zum Schluss: Beide Oberflächen ändern nichts an Ihren Images. Sie bedienen nur, was ohnehin da ist. Verwechseln Sie die Bedienung nicht mit der Sache. Das ist ein kleiner Vorgriff auf Modul 5 und eine der charmantesten Fähigkeiten von Podman: Sie beschreiben Ihren Aufbau lokal — und lassen ihn sich als Kubernetes-Manifest ausgeben.

20:11 Derselbe Aufbau, andere Sprache. Der zweite Befehl geht sogar den Weg zurück und spielt ein Manifest lokal wieder ab. Für den Einstieg in Kubernetes ist das eine wunderbare Brücke, weil Sie Vertrautes in der neuen Notation wiedererkennen. Aber lesen Sie den Hinweis darunter ernst: Das Ergebnis ist ein Anfang, kein fertiges Manifest.

20:31 Was zu einem produktiven Deployment gehört — Probes, Grenzwerte, Rechte — arbeitet Modul 5 aus. Der erste Punkt ist die Team-Regel von vorhin, und ich wiederhole sie, weil sie im Alltag ständig verletzt wird: Der Pfad zur Engine gehört nicht ins geteilte Repository. Der zweite ist eine Erwartungsfrage — die Zusatzfunktionen der Devcontainer sind eine große, lose Sammlung, und nicht jede wurde unter der anderen Engine getestet.

20:56 Rechnen Sie mit einzelnen Ausfällen, nicht mit einem Bruch. Der dritte ist die Warnung von der letzten Folie: Ein erzeugtes Manifest ist nicht produktionsreif. Und der vierte ist eine hübsche Verwechslung: Die Oberfläche ist nicht die Engine. Wer nur klickt, steht beim Umstieg vor einer Kommandozeile, die er nicht kennt.

Lokale Kubernetes-Cluster

21:15 Zum Abschluss dieses Moduls machen wir den Übergang in die zweite Hälfte des Seminars. Ab Modul 5 wird Kubernetes unser Alltag — und wer bis dahin einen Cluster auf dem eigenen Rechner hat, lernt deutlich schneller. Der Cluster als Container, auf Ihrem Notebook. Der Gedanke hat etwas angenehm Verschachteltes: Ein Cluster besteht aus Knoten, also aus Maschinen — und diese Maschinen sind hier selbst Container.

21:39 Kubernetes im Container, verwaltet von Ihrer Engine. Das ist der Trick, der einen Mehrknoten-Cluster in dreißig Sekunden auf einem Notebook möglich macht. Und jetzt schließt sich der Kreis zu allem, was wir heute besprochen haben: Diese Werkzeuge sprechen die Docker-Schnittstelle an. Sie sprechen damit auch den Podman-Socket, sobald dessen Adresse in der Umgebung steht — dieselbe Variable wie bei Compose, dieselbe Brücke.

22:04 Genau deshalb haben wir sie uns so gut angesehen. Vier Werkzeuge, und Sie brauchen nicht alle — aber die Unterschiede lohnen einen Blick. kind ist die naheliegende Wahl für mehrere Knoten und für Pipelines, weil es genau dafür gedacht ist. minikube ist der Veteran mit vielen Treibern und einer reichen Sammlung an Zusatzmodulen.

22:24 k3d setzt auf eine abgespeckte Kubernetes-Variante und ist dadurch verblüffend schnell und schlank. Und Rancher Desktop verpackt dasselbe mit einer Oberfläche, für den Umstieg ohne Kommandozeile. Wichtig ist der Vermerk darunter: Für Podman gilt bei zwei dieser Werkzeuge ausdrücklich „in Erprobung". Das heißt nicht kaputt — es heißt, dass Sie im Fehlerfall alleine dastehen.

22:47 Drei Werkzeuge, drei Schalter — und die Unterschiede sind lehrreich. Das erste braucht eine ausdrückliche Umgebungsvariable, die es selbst als experimentell kennzeichnet. Das zweite kennt Podman als regulären Treiber und nimmt ihn einfach als Argument. Und das dritte weiß von Podman überhaupt nichts: Es spricht die Docker-Schnittstelle an und findet Podman ausschließlich über die Socket-Adresse in der Umgebung.

23:10 Diese dritte Variante ist die interessanteste, weil sie zeigt, wie weit die Deckungsgleichheit trägt. Ein Werkzeug, das nie für Podman gebaut wurde, arbeitet damit — weil es nur eine Schnittstelle kennt und nicht ein Produkt. Diese fünf Schritte sind der unangenehme Teil, und ich sage gleich dazu: Wenn Sie hier hängen, ist es fast immer Schritt eins.

23:31 Ein Cluster braucht Steuergruppen, um Speicher und Rechenzeit seiner Knoten zu begrenzen — und im rootless Betrieb müssen die an Ihre Sitzung übergeben werden. Fehlt das, kommen die Knoten schlicht nicht hoch, und die Meldungen führen in die Irre. Danach der Socket, dann der Start innerhalb eines eigenen Sitzungsbereichs.

23:49 Schritt vier ist ein konkreter Rat für einen konkreten Fehler: Bei Zeitüberschreibungen im Protokoll hilft der dateibasierte Protokolltreiber. Und Schritt fünf ist der freundlichste — halten Sie die drei Schritte im Projekt fest. Diese Übung ist bewusst keine technische. Messen Sie beide Engines an denselben Anforderungen und begründen Sie eine Wahl für ein Team — belastbar.

24:11 Geschafft ist es, wenn eine Empfehlung von einer Seite steht, die Rechte, Compose, Devcontainer, lokalen Cluster und Lizenz vergleicht und den Umstiegsaufwand ehrlich benennt. Wer schneller fertig ist, ergänzt die Gegenposition: Für welches Szenario wäre die andere Wahl richtig? Und der wichtigste Satz dazu: Bewertet wird die Begründung, nicht das Ergebnis.

24:32 Beide Antworten sind vertretbar — was nicht vertretbar ist, ist eine Vorliebe, die sich als Entscheidung verkleidet. Der erste Punkt kostet regelmäßig eine halbe Stunde: Ein lokaler Cluster hat seine eigene Image-Ablage. Ihr frisch gebautes Image ist für ihn nicht vorhanden, es muss ausdrücklich hineingeladen werden. Der zweite ist eine Erwartungsfalle mit Folgen — der lokale Cluster hat andere Voreinstellungen als die Produktion, gerade bei Netzwerk und Rechten.

24:59 Der dritte ist der Vermerk aus der Tabelle: Wer „in Erprobung" überliest, plant Fehlersuche in fremdem Neuland ein, ohne es zu wissen. Und der vierte ist banal und passiert trotzdem allen — mehrere Cluster gleichzeitig legen ein Notebook zuverlässig lahm. Räumen Sie auf, bevor Sie den nächsten starten.

Was ab hier trägt

25:18 Vier Sätze aus diesem Modul. Der offene Standard macht die Engine zu einer Entscheidung und nicht zu einem Bruch — das war die Zusage aus Modul 1, und sie hat gehalten. Rootless ist der Standardfall, und es kostet Durchsatz, nicht Funktion. Compose und Devcontainer laufen auf beiden Engines, und die Brücke dafür ist genau eine Socket-Adresse in der Umgebung. Und die Engine-Wahl braucht eine Begründung, keine Vorliebe.

25:42 Im nächsten Modul bleiben wir lokal, drehen aber die Perspektive: Wie wird aus Containern ein Entwicklungs-Workflow, der täglich trägt — mit Compose, mit Tests, mit einer Pipeline?