Docker-Images
verstehen und erstellen

Überblick

In dieser Einführung zum Verständnis und zur Erstellung von Docker-Images behandeln wir nicht nur die Grundlagen, sondern zeigen Ihnen auch, wo Sie vorgefertigte Images finden, mit denen Sie direkt durchstarten können – sei es für containerisierte Anwendungen, Tools oder Services.

Als neuer Docker-Nutzer sollten Sie auch wissen, wie Sie eigene, maßgeschneiderte Images erstellen. Daher zeigen wir Ihnen kurz, wie Sie Docker-Images für Ihre Anwendungen und containerbasierten Services erstellen können. Doch bevor wir damit beginnen, werfen wir zunächst einen Blick auf die Grundlagen und den Aufbau eines Docker-Images.

Was ist ein Docker-Image?

Ein Docker-Image ist eine schreibgeschützte Vorlage, die eine Reihe von Anweisungen zur Erstellung eines Containers auf der Docker-Plattform enthält. Es bietet eine komfortable Möglichkeit, Anwendungen und vorkonfigurierte Serverumgebungen zu paketieren – für den privaten Gebrauch oder zur Weitergabe an andere Docker-Nutzer. Docker-Images sind außerdem der Einstiegspunkt für alle, die zum ersten Mal mit Docker arbeiten.

Der Aufbau eines Docker-Images

Ein Docker-Image besteht aus einer Sammlung von Dateien, die alle wichtigen Komponenten bündeln – darunter Installationen, Anwendungscode und Abhängigkeiten –, um eine vollständig funktionsfähige Container-Umgebung bereitzustellen. Sie können ein Docker-Image auf zwei Arten erstellen:

• Interaktiv: Sie starten einen Container auf Basis eines bestehenden Docker-Images, nehmen manuell Änderungen an der Container-Umgebung vor und speichern den daraus resultierenden Zustand als neues Image.
• Dockerfile: Sie erstellen eine einfache Textdatei, ein sogenanntes Dockerfile, das die Anweisungen zur Erstellung eines Docker-Images enthält.

Diese beiden Methoden werden wir später im Leitfaden noch im Detail behandeln. Zunächst konzentrieren wir uns auf die wichtigsten Konzepte rund um Docker-Images.

Docker-Layers

Jede Datei, aus der ein Docker-Image besteht, wird als Layer (Schicht) bezeichnet. Diese Schichten bilden eine Serie von Zwischen-Images, die stufenweise aufeinander aufbauen. Jede Schicht hängt von der direkt darunterliegenden ab. Die hierarchische Struktur der Schichten ist entscheidend für ein effizientes Lebenszyklus-Management Ihrer Docker-Images.

Daher sollten Sie Schichten, die sich häufig ändern, wie etwa den Anwendungscode, möglichst weit oben im Stack platzieren. Denn sobald eine Schicht geändert wird, muss Docker nicht nur diese, sondern auch alle darauf aufbauenden Schichten neu erstellen. Eine Änderung an einer oberen Schicht erfordert somit den geringsten Aufwand beim Neuaufbau des gesamten Images.

Container-Layer

Jedes Mal, wenn Docker einen Container aus einem Image startet, wird eine dünne beschreibbare Schicht hinzugefügt – der sogenannte Container-Layer. Darin werden alle Änderungen gespeichert, die während der Laufzeit des Containers vorgenommen werden.

Da dieser Layer den einzigen Unterschied zwischen einem laufenden Container und dem ursprünglichen Docker-Image darstellt, können beliebig viele gleichartige Container auf dasselbe zugrunde liegende Image zugreifen – und dabei dennoch jeweils ihren eigenen Zustand beibehalten.

Parent Image

In den meisten Fällen ist die erste Schicht eines Docker-Images das sogenannte Parent Image. Es bildet das Fundament, auf dem alle weiteren Schichten aufgebaut werden, und stellt die grundlegenden Bausteine für Ihre Container-Umgebungen bereit. Eine große Auswahl an vorgefertigten Images zur Verwendung als Parent Image finden Sie in der öffentlichen Container-Registry Docker Hub.

Darüber hinaus sind Parent Images auch über einige wenige Drittanbieter-Dienste verfügbar, wie z. B. die Google Container Registry. Alternativ können Sie auch ein eigenes, bereits vorhandenes Image als Basis für neue Images verwenden. Ein typisches Parent Image kann eine schlanke Linux-Distribution sein oder einen vorinstallierten Dienst wie ein Datenbankmanagementsystem (DBMS) oder ein Content-Management-System (CMS) enthalten.

Base Image

Ein Base Image ist vereinfacht gesagt eine leere erste Schicht, mit der Sie Docker-Images komplett von Grund auf erstellen können. Base Images bieten die volle Kontrolle über den Inhalt eines Images, richten sich jedoch in der Regel an fortgeschrittene Docker-Nutzer.

Docker Manifest

Zusätzlich zu den einzelnen Layer-Dateien enthält ein Docker-Image auch eine weitere Datei, das sogenannte Manifest. Dabei handelt es sich im Wesentlichen um eine JSON-basierte Beschreibung des Images. Es enthält Informationen wie Image-Tags, eine digitale Signatur sowie Details zur Konfiguration des Containers für verschiedene Host-Plattformen.

Was ist der Unterschied zwischen Container Registry und Container Repository?

Auch wenn die Begriffe „Registry“ und „Repository“ häufig synonym verwendet werden, bezeichnen sie im Docker-Ökosystem für die Speicherung und Verteilung von Images zwei unterschiedliche, hierarchisch strukturierte Konzepte: den übergeordneten Dienst und den konkreten Speicherort für Image-Versionen.

Container Registries

Container Registries sind Kataloge von Speicherorten – den sogenannten Repositories –, in die Sie Container-Images hochladen (push) und daraus herunterladen (pull) können. Es gibt drei Haupttypen von Registries:

1. Docker Hub: Die offizielle Registry von Docker, über die Sie auf mehr als 100.000 Container-Images zugreifen können, die von Softwareanbietern, Open-Source-Projekten und der Docker-Community bereitgestellt wurden. Sie können den Dienst auch nutzen, um eigene private Images zu hosten und zu verwalten.
2. Registry-Dienste von Drittanbietern: Vollständig verwaltete Angebote, die als zentraler Zugriffspunkt für Ihre eigenen Container-Images dienen. Sie ermöglichen die Speicherung, Verwaltung und Absicherung von Images – ohne den Aufwand, eine eigene Registry vor Ort zu betreiben. Beispiele für Registry-Dienste, die Docker-Images unterstützen, sind Red Hat Quay, Amazon ECR, Azure Container Registry, Google Container Registry und die JFrog Container Registry.
3. Selbstgehostete Registries: Dieses Modell wird von Organisationen bevorzugt, die Container-Images auf eigener Infrastruktur betreiben möchten – typischerweise aus Gründen der Sicherheit, Compliance oder wegen geringer Latenzanforderungen. Um eine selbstgehostete Registry zu betreiben, müssen Sie einen eigenen Registry-Server einrichten. Alternativ können Sie auch eine eigene private, remote oder virtuelle Docker Registry konfigurieren.

Container Repositories

Container-Repositories sind die konkreten Speicherorte, an denen Docker-Images physisch abgelegt sind. Jedes Repository enthält eine Sammlung zusammengehöriger Images mit demselben Namen. Die einzelnen Images innerhalb eines Repositories werden jeweils durch einen anderen Tag referenziert und repräsentieren unterschiedliche Versionen derselben grundlegenden Container-Deployment-Konfiguration. Auf Docker Hub ist zum Beispiel mysql der Name des Repositories, das verschiedene Versionen des Docker-Images für das beliebte Open-Source-DBMS MySQL enthält.

Sicherheit, Governance und Vertrauen in agentischen Repositories

Die autonome Natur agentischer Repositories bringt neue Herausforderungen in den Bereichen Sicherheit und Governance mit sich, die ein sorgfältiges Management erfordern. Da KI-Agenten in der Lage sind, Code auszuführen und Entscheidungen zu treffen, ist es entscheidend, dass ihr Verhalten sicher, nachvollziehbar und mit den Richtlinien des Unternehmens vereinbar ist.

Sicherheitsherausforderungen angehen

Da agentische Repositories autonom mit der Software-Lieferkette interagieren können, entstehen neue Aspekte für die Anwendungssicherheit (Application Security, AppSec). Eine zentrale Herausforderung besteht darin, Prompt-Injection-Angriffe abzuwehren – also Eingaben in natürlicher Sprache, mit denen ein Angreifer das Verhalten eines Agenten manipulieren kann. Eine weitere Sorge ist die Möglichkeit, dass Agenten unbeabsichtigt Schwachstellen einführen oder nicht konforme Abhängigkeiten integrieren – ohne ausreichende Kontrolle. Um diese Risiken zu minimieren, müssen agentische Repositories mit robusten Sicherheitsfunktionen ausgestattet sein, darunter:

• Zero-Trust-Architekturen: Jede Aktion eines Agenten muss unabhängig von ihrer Herkunft verifiziert und authentifiziert werden.
• Explainable AI (XAI): Für jede Entscheidung eines Agenten wird eine nachvollziehbare, menschenlesbare Begründung geliefert, um Audits und Debugging zu ermöglichen.
• Automatisierte Schutzmechanismen: Strikte Richtlinien sorgen dafür, dass Agenten keine unbefugten Aktionen durchführen können – etwa bekannte Schwachstellen einführen oder ohne Erlaubnis auf sensible Daten zugreifen.

Die Rolle von Governance und Vertrauen

Governance-Rahmenbedingungen für agentische Repositories gehen über rein technische Kontrollen hinaus und umfassen Richtlinien, die den Handlungsspielraum und die Befugnisse von KI-Agenten definieren. Vertrauen entsteht durch Transparenz und Verantwortlichkeit. Unternehmen müssen klare Rahmenbedingungen schaffen, die den Autonomiegrad eines Agenten, die Rechte zur Datennutzung sowie die Entscheidungsverantwortung festlegen. So können Organisationen sicherstellen, dass KI-Agenten – je tiefer sie in operative Abläufe eingebunden werden – kontrolliert und risikobewusst eingesetzt werden. Ziel ist es, Governance nicht als Hindernis zu sehen, sondern als grundlegenden Erfolgsfaktor, der Vertrauen schafft und die sichere sowie skalierbare Einführung agentischer KI ermöglicht.

Wie agentische Repositories Sicherheit, Governance und Vertrauen verbessern

Auch wenn agentische KI neue Sicherheits- und Governance-Anforderungen mit sich bringt, kann ihre korrekte Anwendung die Sicherheitslage und Compliance eines Unternehmens sogar verbessern.

• Sicherheit: Durch intelligente Automatisierung verfolgen agentische Repositories einen proaktiven Ansatz für Sicherheit und Compliance. Sie analysieren kontinuierlich die Software-Lieferkette auf Schwachstellen und Richtlinienverstöße – und bieten damit ein Maß an Sorgfalt, das über manuelle Prüfungen hinausgeht. Dies wird durch die Integration von Sicherheitsscannern direkt in die Workflows der Agenten erreicht, sodass jedes Artefakt vor der Verwendung geprüft wird.
• Governance: Die Fähigkeit von Agenten, über Explainable AI nachvollziehbare und auditierbare Begründungen für ihr Handeln zu liefern, ist entscheidend für Transparenz und Vertrauen. Teams können Entscheidungen validieren und die Einhaltung von Governance-Richtlinien sicherstellen.

So erstellen Sie ein Docker-Image

In diesem letzten Abschnitt gehen wir näher auf die zwei Methoden zur Erstellung von Docker-Images ein, damit Sie Ihr Wissen direkt in die Praxis umsetzen können.

Interaktive Methode

Vorteile: Schnellste und einfachste Methode zur Erstellung von Docker-Images. Ideal für Tests, Fehlersuche, Abhängigkeitsanalysen und zur Validierung von Prozessen.

Nachteile: Schwieriges Lifecycle-Management, da jede Änderung manuell vorgenommen werden muss – fehleranfällig. Zudem ist es einfacher, nicht optimierte Images mit unnötigen Schichten zu erstellen.

Die folgenden Schritte zeigen vereinfacht, wie ein Image interaktiv erstellt wird:

• Docker installieren und den Docker-Dienst starten
• Ein Terminal öffnen
• Verwenden Sie folgenden Befehl, um eine interaktive Shell-Session mit einem Container zu starten, der auf dem angegebenen Image (image_name:tag_name) basiert:

$ docker run -it image_name:tag_name bash

Wenn Sie keinen Tag angeben, wird automatisch die neueste Version des Images mit dem Tag latest verwendet. Falls das Image nicht lokal vorhanden ist, lädt Docker es aus dem entsprechenden Repository auf Docker Hub herunter.

In unserem Beispiel starten wir eine Containerumgebung, die auf der neuesten Version von Ubuntu basiert:

$ docker run -it ubuntu bash

• Konfigurieren Sie Ihre Container-Umgebung, z. B. durch Installation von Frameworks, Abhängigkeiten, Bibliotheken, Updates oder Anwendungscode. Im folgenden Beispiel wird ein NGINX-Server installiert:

# apt-get update && apt-get install -y nginx

Als Nächstes müssen Sie den Namen oder die ID Ihrer laufenden Containerinstanz kennen.

• Öffnen Sie eine weitere Bash-Shell und geben Sie den folgenden docker ps-Befehl ein, um aktive Containerprozesse aufzulisten:

$ docker ps

Die folgende Beispielausgabe zeigt unseren laufenden Container mit der ID e61e8081866d und dem Namen keen_gauss:

CONTAINER ID    IMAGE    COMMAND    CREATED          STATUS        PORTS    NAMES
e61e8081866d       ubuntu      “bash”         2 minutes ago     Up 2 minutes         keen_gauss

Dieser Name wird vom Docker-Daemon zufällig generiert. Sie können Ihren Container jedoch auch mit einem aussagekräftigeren Namen versehen, indem Sie ihm mit dem Operatornamen im Befehl docker run einen eigenen Namen zuweisen.

• Speichern Sie das Image mit dem Befehl docker commit, wobei Sie entweder die Container-ID oder den Namen angeben:

$ docker commit keen_gauss ubuntu_testbed

Im obigen Beispiel haben wir das Image ubuntu_testbed genannt und es aus dem Container keen_gauss erstellt.

• Verwenden Sie nun den Befehl docker images, um das soeben erstellte Image anzuzeigen:

$ docker images

Ihr neues Image sollte in den Ergebnissen aufgeführt sein.

REPOSITORY     TAG        IMAGE ID          CREATED            SIZE
ubuntu                 latest      775349758637    5 minutes ago      64.2MB

• Kehren Sie schließlich zu Ihrer interaktiven Container-Shell zurück und geben Sie exit ein, um sie zu beenden.

# exit

Dockerfile-Methode

Vorteile: Saubere, kompakte und reproduzierbare Image-Erstellung auf Rezeptbasis. Einfacheres Lifecycle-Management und bessere Integration in Continuous-Integration- (CI) und Continuous-Delivery-Prozesse (CD). Klar dokumentierte Schritt-für-Schritt-Anleitung direkt im Dockerfile.

Nachteile: Für Einsteiger schwieriger und zeitaufwendiger in der Erstellung.

Die Dockerfile-Methode ist die bevorzugte Vorgehensweise für reale, produktionsreife Container-Deployments in Unternehmen. Sie bietet einen systematischeren, flexibleren und effizienteren Weg zur Erstellung von Docker-Images – und ist der Schlüssel zu kompakten, zuverlässigen und sicheren Container-Umgebungen.

Kurz gesagt: Die Dockerfile-Methode besteht aus drei Schritten, bei denen Sie ein Dockerfile erstellen und die Befehle hinzufügen, die zum Aufbau des Images erforderlich sind.

Die folgende Tabelle zeigt die am häufigsten verwendeten Anweisungen in einem Dockerfile:

Beispiel für ein Dockerfile

Dies ist ein Beispiel-Dockerfile zum Erstellen eines Images, das auf dem offiziellen Ubuntu 18.04 basiert und NGINX installiert.

Als Nächstes richten wir eine .dockerignore-Datei ein, um bestimmte Dateien vom Build-Prozess auszuschließen, die sonst während der Erstellung des Docker-Images in das finale Image übernommen würden.

.dockerignore-Dateien spielen eine wichtige Rolle bei der Erstellung kompakterer und performanterer Container, da sie verhindern, dass sensible oder unnötige Dateien und Verzeichnisse ins Image gelangen. Die .dockerignore-Datei sollte sich im Stammverzeichnis des Build-Kontexts befinden – also im Verzeichnis, von dem aus das Image erstellt wird. Dabei handelt es sich entweder um das aktuelle Arbeitsverzeichnis oder um einen explizit angegebenen Pfad, den Sie beim Ausführen des Docker-Build-Befehls angeben (dazu mehr im nächsten Abschnitt).

Der Docker-Build-Kontext

Nun erstellen Sie Ihr Docker-Image mit dem Befehl docker build. Verwenden Sie das Flag -t, um dem Image einen Namen und Tag zu geben:

$ docker build -t my-nginx:0.1 .

Im obigen Beispiel wurde das Image direkt aus dem Verzeichnis erstellt, in dem sich auch das Dockerfile und der Build-Kontext befinden – das . steht dabei für das aktuelle Arbeitsverzeichnis, aus dem der Docker-Daemon alle benötigten Dateien und Ordner einliest.

Wie bei der interaktiven Methode können Sie den folgenden Befehl verwenden, um das erstellte Image anzuzeigen:

$ docker images

REPOSITORY     TAG IMAGE ID        CREATED SIZE

my-nginx       0.1 f95ae2e1344b    10 seconds ago 138MB

ubuntu         18.04 ccc6e87d482b  12 days ago 64.2MB

Auch hier sollte Ihr neues Image in der Liste erscheinen.

Best Practices beim Erstellen von Docker-Images

Ein Docker-Image zu erstellen bedeutet mehr, als es einfach nur zum Laufen zu bringen – es geht darum, effiziente, sichere und wartbare Images zu bauen, die zuverlässig in der Produktion eingesetzt werden können. Einige Best Practices machen dabei den entscheidenden Unterschied:

• Image-Schichten (Layer) optimieren: Platzieren Sie häufig veränderte Bestandteile, wie z. B. Anwendungscode, möglichst weit oben im Layer-Stack. Dadurch verkürzen sich Build-Zeiten bei kleinen Änderungen. Die unteren Schichten sollten stabilen Abhängigkeiten wie OS-Paketen oder Frameworks vorbehalten sein.
• Build-Cache optimal nutzen: Docker speichert Layer, die sich zwischen Builds nicht verändert haben. Durch eine sinnvolle Reihenfolge der Dockerfile-Befehle (z. B. zuerst Abhängigkeiten installieren, dann Code kopieren) lassen sich unnötige Rebuilds vermeiden.
• Multi-Stage-Builds implementieren: Mit Multi-Stage-Builds trennen Sie Build- und Laufzeitabhängigkeiten. So können Sie z. B. in einem Build-Stage eine Anwendung kompilieren und in einem zweiten, schlanken Stage ausführen. Das reduziert die Image-Größe und verhindert, dass sensible Dateien in die Produktionsumgebung gelangen.

Diese Best Practices führen zu schnelleren Builds, kleineren Images und weniger Sicherheitsrisiken – und erhöhen gleichzeitig die Produktivität der Entwickler.

Nächste Schritte und weiterführende Inhalte

Sobald Sie sich mit dem Erstellen von Docker-Images vertraut gemacht haben, können Sie tiefer in fortgeschrittene Techniken und Integrationen einsteigen:

• Vertiefung Ihres Docker-Wissens: Die Docker-Dokumentation behandelt erweiterte Dockerfile-Syntax, automatisiertes Scanning und reproduzierbare Build-Pipelines, die über die Grundlagen hinausgehen.
• Fortgeschrittene Build-Techniken erkunden: Nutzen Sie Content Trust für signierte Images, erstellen Sie reproduzierbare Builds über Digests und automatisieren Sie Workflows mit CI/CD-Tools, um Ihre Container-Supply-Chain zu stärken.
• Nahtlose Verwaltung mit JFrog: JFrog Artifactory und die JFrog Container Registry bieten Enterprise-Funktionen für die Speicherung, Versionierung und Freigabe von Docker-Images. Mit integriertem Vulnerability Scanning, Build-Metadaten und Anbindung an CI/CD-Pipelines unterstützen die JFrog-Produkte Teams bei der sicheren und skalierbaren Verwaltung ihrer Container-Images.

Durch den Einsatz bewährter Verfahren und die Erweiterung Ihres Toolsets behandeln Sie Docker-Images nicht mehr nur als Artefakte, sondern als integralen Bestandteil einer sicheren, automatisierten und unternehmensreifen Entwicklungs- und Lieferkette.

Docker-Images mit JFrog verwalten

Wenn Sie die Grundlagen von Docker-Images beherrschen, schaffen Sie damit die Basis für effiziente, sichere und skalierbare containerisierte Anwendungen. Ob Sie mit interaktiven Builds experimentieren oder Dockerfiles für produktionsreife Workflows nutzen – mit Best Practices stellen Sie sicher, dass Ihre Images in puncto Performance und Sicherheit optimiert sind.

Um Ihre Container-Strategie weiter auszubauen, bietet die JFrog Software Supply Chain Plattform Lösungen in Enterprise-Qualität für die sichere Verwaltung, Speicherung und Skalierung von Docker-Images – vollständig integriert in Ihre CI/CD-Pipelines, mit Schwachstellenscans und detaillierten Metadatenanalysen.

Mit JFrog werden Ihre Container-Images nicht nur zu verwalteten Artefakten – sie werden zu einem verlässlichen Bestandteil Ihrer automatisierten Software-Lieferkette.

Wenn Sie mehr erfahren wollen, besuchen Sie unsere Website, machen Sie eine virtuelle Tour oder vereinbaren Sie eine persönliche Demo – ganz nach Ihren Wünschen.