Wir schauen uns den Aufbau von OCI Images an und wie daraus leichtgewichtige Container werden.
Cool, unsere Software läuft 🥳. Bei uns 🤔. Mit genau dieser einen Bibliotheksversion und genau diesen Umgebungsparametern 😟. Damit das aber nicht nur bei uns, sondern auch bei anderen leicht reproduzierbar funktioniert: Stellen wir doch ein Image bereit und deployen das 🚀.
Durch die Einführung von OCI Containern wurde viel Reproduzierbarkeit gewonnen. Wir haben alle schon mit ihnen zu tun gehabt. Außerdem eignen sich Images, Hauptzutat für die Container, gut für iterative Weiterentwicklung.
Kleine Änderung? Einfach als neues Layer hinzufügen. 👍
Doch so entstehen viel zu oft Images mit unschönen Eigenschaften:
Sie werden zu groß.
Die daraus entstehenden Container gleichen eher einem resourcenfressenden Multitool statt dem geeigneteren Werkzeug.
Manchmal gibt es kleine Unachtsamkeiten und es werden unbeabsichtigt (Zugangs-)Daten mit der Welt geteilt.
Wie das mit den Updates laufen soll, ist auch nicht überall klar.
Veraltete Basisimages schleichen sich in deployte Container und plötzlich läuft auf unserem Server Software mit bekannten Sicherheitslücken.
In diesem Vortrag schauen wir, wie OCI Container in Speicherverbrauch und Laufzeit leichtgewichtig werden und so Ressourcen sparen: Multistage Builds, unbeabsichtigte Caches im Image, und Image Layer Squash.
Damit wir da nicht dauernd selbst dran denken müssen: wie sich das kombiniert mit einem Vulnerability Scanner für unsere CI/CD Pipeline automatisieren lässt.
Wenn du Software schreibst, die irgendwie mit diesem `Dockerfile` zu einem Image wird, dich aber (noch) nicht damit beschäftigt hast, was mit dem Aufbau dieser Images und der Infrastruktur für die daraus entstandenen Container los ist: Du bist Zielgruppe.
Wenn du dein Kubernetes mit Images frisch aus Pipelines voll automatischen Benchmarks und Scans fütterst, dann wirst du vermutlich nicht viel Neues lernen.