Docker Image

Das Docker-Projekt mit der gleich­na­mi­gen Software hat sich als Standard für die Container-Vir­tua­li­sie­rung etabliert. Ein zentrales Konzept bei der Nutzung der Docker-Plattform ist das Docker-Image. In diesem Artikel erklären wir, wie Docker-Images aufgebaut sind und wie sie funk­tio­nie­ren.

Der Begriff „Image“ ist Ihnen im Zu­sam­men­hang mit Vir­tua­li­sie­rung mög­li­cher­wei­se von vir­tu­el­len Maschinen (VMs) bekannt. Für ge­wöhn­lich handelt es sich bei einem VM-Image um eine Kopie eines Be­triebs­sys­tems. Ggf. enthält ein VM-Image weitere in­stal­lier­ten Kom­po­nen­ten wie Datenbank und Webserver. Der Begriff entstammt einer Zeit, in der Software auf optischen Da­ten­trä­gern wie CD-ROMs und DVDs verteilt wurde. Wollte man eine lokale Kopie des Da­ten­trä­gers anlegen, erstellte man mit einer spe­zi­el­len Software ein Abbild, auf Englisch „Image“.

Bei der Container-Vir­tua­li­sie­rung handelt es sich um die kon­se­quen­te Wei­ter­ent­wick­lung der VM-Vir­tua­li­sie­rung. Anstatt einen vir­tu­el­len Computer (Maschine) mit eigenem Be­triebs­sys­tem zu vir­tua­li­sie­ren, umfasst ein Docker-Image in der Regel lediglich eine Anwendung. Dabei kann es sich um eine einzelne Bi­när­da­tei handeln oder um einen Verbund mehrerer Software-Kom­po­nen­ten.

Um die Anwendung aus­zu­füh­ren, wird aus dem Image zunächst ein Container erzeugt. Alle auf einem Docker-Host laufenden Container greifen auf denselben Be­triebs­sys­tem-Kernel zurück. Dadurch sind Docker-Container und Docker-Images in der Regel deutlich leicht­ge­wich­ti­ger als ver­gleich­ba­re virtuelle Maschinen und deren Images.

Die Konzepte Docker-Container und Docker-Image sind eng mit­ein­an­der verknüpft. So kann nicht nur ein Docker-Container aus einem Docker-Image erzeugt werden, sondern auch aus einem laufenden Container ein neues Image. Docker-Image und Docker-Container stehen also in einem ähnlichen Zu­sam­men­hang wie Hühnerei und Huhn:

Im bio­lo­gi­schen Henne-Ei-System wird aus einem Ei genau ein Küken erzeugt. Das Ei geht dabei verloren. Im Gegensatz dazu lassen sich aus einem Docker-Image beliebig viele gleich­ar­ti­ge Container erzeugen. Aus dieser Re­pro­du­zier­bar­keit ergibt sich die Eignung von Docker als Plattform für ska­lier­ba­re An­wen­dun­gen und Dienste.

Ein Docker-Image ist eine un­ver­än­der­li­che Vorlage, aus der Docker-Container erzeugt werden. Das Image enthält sämtliche In­for­ma­tio­nen und Ab­hän­gig­kei­ten, um einen Container aus­zu­füh­ren. Dazu gehören grund­le­gen­de Programm-Bi­blio­the­ken und Nutzer-Schnitt­stel­len. Ins­be­son­de­re ist nor­ma­ler­wei­se eine Kom­man­do­zei­len-Umgebung („Shell“) und eine Im­ple­men­tie­rung der C-Standard-Bi­blio­thek mit an Bord. Hier eine Übersicht des of­fi­zi­el­len „Alpine-Linux“ Image:

Neben diesen grund­le­gen­den Kom­po­nen­ten, die den Linux-Kernel ergänzen, enthält ein Docker-Image in der Regel weitere Software. Hier einige Beispiele von Software-Kom­po­nen­ten für ver­schie­de­ne Ein­satz­ge­bie­te. Beachten Sie, dass ein einzelnes Docker-Image für ge­wöhn­lich eine kleine Auswahl der gezeigten Kom­po­nen­ten umfasst:

Wie wir gesehen haben, exis­tie­ren Docker-Image und Docker-Container im engen Wech­sel­spiel mit­ein­an­der. In welchen Merkmalen un­ter­schei­den sich die beiden Konzepte nun?

Zunächst stellen wir fest, dass ein Docker-Image inert ist. Es belegt lediglich etwas Spei­cher­platz, ver­braucht jedoch ansonsten keinerlei Sys­tem­res­sour­cen. Ferner ist ein Docker-Image nach der Er­stel­lung un­ver­än­der­lich. Es handelt sich also um ein „read-only“ bzw. schreib­ge­schütz­tes Medium. Dazu ein kleiner Hinweis: Ja, es ist möglich, einem exis­tie­ren­den Docker-Image eine Änderung hin­zu­zu­fü­gen. Dabei entsteht jedoch ein neues Image; das ur­sprüng­li­che Image liegt weiterhin in der un­ver­än­der­ten Version vor.

Wie erwähnt lassen sich aus einem Docker-Image beliebig viele, gleich­ar­ti­ge Container erzeugen. Was genau macht nun einen Docker-Container im Vergleich zum -Image aus? Bei einem Docker-Container handelt es sich um eine laufende (soll heißen: in der Aus­füh­rung be­find­li­che) Instanz eines Docker-Images. Wie jede auf einem Computer aus­ge­führ­te Software, ver­braucht ein laufender Docker-Container die Sys­tem­res­sour­cen Ar­beits­spei­cher und CPU-Zyklen. Ferner ändert sich der Zustand eines Con­tai­ners über dessen Le­bens­dau­er.

Falls diese Be­schrei­bung Ihnen zu abstrakt erscheint, ziehen Sie ein einfaches Beispiel aus dem täglichen Leben zu Hilfe. Stellen Sie sich ein Docker-Image wie eine DVD vor. Die DVD an sich ist inert ­– sie liegt in ihrer Hülle und macht ansonsten nichts. Dabei belegt sie dauerhaft denselben, be­grenz­ten Platz im Raum. Erst durch Abspielen in einer spe­zi­el­len Umgebung (DVD-Player) wird der Inhalt „lebendig“.

Wie der beim Abspielen einer DVD erzeugte Film hat ein laufender Docker-Container einen Zustand. Beim Film sind dies der aktuelle Wie­der­ga­be-Zeitpunkt, gewählte Sprache, Un­ter­ti­tel und der­glei­chen. Dieser Zustand ändert sich mit der Zeit, und ein spie­len­der Film ver­braucht dabei laufend Elek­tri­zi­tät. Wie aus einem Docker-Image beliebig oft gleich­ar­ti­ge Container gestartet werden können, lässt sich der Film einer DVD immer wieder abspielen. Ferner kann der laufende Film gestoppt und wieder gestartet werden – auch dies ist mit einem Docker-Container möglich.

Docker kommt heut­zu­ta­ge in allen Phasen des Software-Life­cy­cles zum Einsatz. Dazu gehören Ent­wick­lung, Test und Betrieb. Das zentrale Konzept im Docker-Ökosystem ist der Container, zu dessen Erzeugung wir immer ein Image benötigen. Docker-Images werden also überall dort verwendet, wo Docker zum Einsatz kommt. Schauen wir uns ein paar Beispiele an:

Ent­wi­ckelt man Software auf dem eigenen Gerät, möchte man die lokale Ent­wick­lungs­um­ge­bung so kon­sis­tent wie möglich halten. Meist benötigt man exakt über­ein­stim­men­de Versionen von Pro­gram­mier­spra­che, Bi­blio­the­ken und weiteren Software-Kom­po­nen­ten. Sobald sich nur eine der vielen in­ter­agie­ren­den Ebenen ändert, ergeben sich schnell Stör­ef­fek­te. Dann kom­pi­liert der Quelltext nicht oder der Webserver lässt sich nicht starten. Hier wirkt die Un­ver­än­der­lich­keit der Docker-Images Wunder: Als Ent­wick­ler kann man sich darauf verlassen, dass die im Image ent­hal­te­ne Umgebung kon­sis­tent bleibt.

Größere Ent­wick­lungs­pro­jek­te werden von Teams geleistet. Hier ist die Nutzung einer über die Zeit stabilen Umgebung Vor­aus­set­zung für Ver­gleich­bar­keit und Re­pro­du­zier­bar­keit. Alle Ent­wick­ler eines Teams greifen auf dasselbe Image zurück. Kommt ein Ent­wick­ler neu ins Team, zieht er sich das passende Docker-Image und kann sofort loslegen. Um Än­de­run­gen an der Ent­wick­lungs­um­ge­bung vor­zu­neh­men, wird einmalig ein neues Docker-Image erstellt. Die Ent­wick­ler beziehen das neue Image und sind damit sofort auf dem aktuellen Stand.

Docker-Images bilden die Grundlage der modernen ser­vice­ori­en­tier­ten Ar­chi­tek­tur. Anstatt einer einzigen, mo­no­li­thi­schen Anwendung werden einzelne Dienste mit wohl­de­fi­nier­ten Schnitt­stel­len ent­wi­ckelt. Jeder Dienst wird in ein eigenes Image gepackt. Die daraus ge­star­te­ten Container kom­mu­ni­zie­ren mit­ein­an­der über das Netzwerk und stellen somit die Ge­samt­funk­tio­na­li­tät der Anwendung her. Die Kapselung in eigenen Docker-Images erlaubt die von­ein­an­der un­ab­hän­gi­ge Ent­wick­lung und Wartung der Dienste. Die einzelnen Dienste können sogar in ver­schie­de­nen Pro­gram­mier­spra­chen ge­schrie­ben werden.

Auch im Da­ten­cen­ter finden Docker-Images Ver­wen­dung. Jeder Dienst wie Load-Balancer, Webserver, Da­ten­bank­ser­ver etc. ist als Docker-Image definiert. Die daraus erzeugten Container können jeweils eine gewisse Last stemmen. Eine Or­chestra­tor-Software überwacht die Container, deren Aus­las­tung und Zustand. Bei stei­gen­der Last startet der Or­chestra­tor zu­sätz­li­che Container aus dem ent­spre­chen­den Image. Dieser Ansatz erlaubt die schnelle Ska­lie­rung von Diensten als Reaktion auf sich ändernde Be­din­gun­gen.

Anders als bei Images vir­tu­el­ler Maschinen der Fall, ist ein Docker-Image im Nor­mal­zu­stand keine einzelne Datei. Statt­des­sen handelt es sich um einen Verbund mehrerer Kom­po­nen­ten. Hier eine kurze Übersicht; Details folgen im weiteren Verlauf:

• Image-Layers enthalten durch Operation auf dem Da­tei­sys­tem hin­zu­ge­füg­te Daten. Layers werden über­la­gert und durch ein Union-Da­tei­sys­tem auf eine kon­sis­ten­te Ebene reduziert.
• Ein Parent-Image stellt Grund­funk­tio­nen des Images bereit und verankert das Image im Stammbaum des Docker-Öko­sys­tems.
• Ein Image-Manifest be­schreibt den Verbund und iden­ti­fi­ziert die darin ent­hal­te­nen Image-Layers.

Was nun, wenn man ein Docker-Image in eine einzelne Datei über­füh­ren möchte? Auch dies ist mit dem „docker save“-Befehl auf der Kom­man­do­zei­le möglich. Dabei wird eine tar-Archiv-Datei erzeugt. Diese lässt sich ganz normal zwischen Systemen bewegen. Mit dem folgenden Befehl wird ein Docker-Image mit Namen „busybox“ in eine Datei „busybox.tar“ ge­schrie­ben:

Häufig wird die Ausgabe von „docker save“ auf der Kom­man­do­zei­le per Pipeline an Gzip übergeben. So werden die Daten nach Ausgabe in die tar-Datei kom­pri­miert:

Eine via „docker save“ erzeugte Image-Datei lässt sich mit „docker load“ als Docker-Image in den lokalen Docker-Host ein­spei­sen:

Ein Docker-Image besteht aus schreib­ge­schütz­ten Schichten, auf Englisch „Layers“ genannt. Jeder Layer be­schreibt suk­zes­si­ve Än­de­run­gen am Da­tei­sys­tem des Images. Für jede Operation, die zu einer Änderung am Da­tei­sys­tem des Images führen würde, wird ein neuer Layer angelegt. Der dabei zum Einsatz kommende Ansatz wird generell als „Copy-on-Write“ be­zeich­net: Ein Schreib­zu­griff legt eine ver­än­der­te Kopie in einem neuen Layer an; die Ur­sprungs­da­ten bleiben un­ver­än­dert. Falls Ihnen das Prinzip bekannt vorkommt: Die Ver­si­ons­kon­troll-Software Git arbeitet nach demselben Muster.

Wir können die Layers eines Docker-Image anzeigen. Wir nutzen hier den „docker image inspect“-Befehl auf der Kom­man­do­zei­le. Der Aufruf gibt ein JSON-Dokument zurück, das wir mit dem Standard-Tool jq ver­ar­bei­ten:

Um die in den Layers ent­hal­te­nen Än­de­run­gen wieder zu­sam­men­zu­füh­ren, wird ein spe­zi­el­les Da­tei­sys­tem verwendet. Dieses Union-Da­tei­sys­tem über­la­gert sämtliche Layers, sodass sich auf der Ober­flä­che eine kon­sis­ten­te Ordner- und Da­tei­struk­tur ergibt. His­to­risch kamen ver­schie­de­ne, als „Storage-Driver“ be­zeich­ne­te Tech­no­lo­gien zum Einsatz, um das Union-Da­tei­sys­tem zu im­ple­men­tie­ren. Heut­zu­ta­ge wird für die meisten An­wen­dungs­fäl­le der Storage-Driver overlay2 empfohlen:

Es ist möglich, den ver­wen­de­ten Storage-Driver eines Docker-Image aus­zu­ge­ben. Wir nutzen hier den „docker image inspect“-Befehl auf der Kom­man­do­zei­le. Der Aufruf gibt ein JSON-Dokument zurück, das wir mit dem Standard-Tool jq ver­ar­bei­ten:

Jeder Image-Layer ist durch einen ein­deu­ti­gen Hash ge­kenn­zeich­net, der aus den darin ent­hal­te­nen Än­de­run­gen errechnet wird. Nutzen zwei Images denselben Layer, wird dieser nur einmal lokal ge­spei­chert. Beide Images greifen dann auf denselben Layer zurück. Dies führt zu einer ef­fi­zi­en­ten lokalen Spei­che­rung und re­du­zier­ten Trans­fer­men­gen beim Beziehen von Images.

Einem Docker-Image liegt für ge­wöhn­lich ein „Parent-Image“ (zu Deutsch „Eltern-Image“) zugrunde. In den meisten Fällen wird das Parent-Image durch eine FROM-Anweisung in der Do­cker­file fest­ge­legt. Das Parent-Image definiert eine Basis, auf dem davon ab­ge­lei­te­te Images aufbauen. Dabei werden die exis­tie­ren­den Image-Layers durch zu­sätz­li­che Layers über­la­gert.

Durch das „Erben“ vom Parent-Image ordnet sich ein Docker-Image in einen Stammbaum ein, der sämtliche exis­tie­ren­den Images umfasst. Viel­leicht fragen Sie sich bereits, wo der Stammbaum seinen Anfang nimmt. Die Wurzeln des Stamm­baums werden durch wenige, spezielle „Base-Images“ fest­ge­legt. In den meisten Fällen wird ein Base-Image mit der „FROM scratch“-Anweisung in der Do­cker­file definiert. Es gibt jedoch auch andere Wege, ein Base-Image zu erstellen. Dazu mehr im Abschnitt „Woher stammen Docker-Images?“.

Wie wir gesehen haben, besteht ein Docker-Image aus mehreren Layers. Nutzt man den „docker image pull“-Befehl, um ein Docker-Image von einer Online-Registry zu beziehen, wird also keine einzelne Image-Datei her­un­ter­ge­la­den. Statt­des­sen lädt der lokale Docker-Daemon die einzelnen Layers herunter und speichert diese. Woher stammt nun die In­for­ma­ti­on über die einzelnen Layers?

Die In­for­ma­ti­on darüber, aus welchen Image-Layers ein Docker-Image besteht, ist im so­ge­nann­ten Image-Manifest enthalten. Das Image-Manifest ist eine JSON-Datei, die ein Docker-Image voll­stän­dig be­schreibt. Unter anderem enthält ein Image-Manifest:

• Versions-, Schema- und Grö­ßen­an­ga­ben
• kryp­to­gra­fi­sche Hashes der zum Einsatz kommenden Image-Layers
• Angaben zu ver­füg­ba­ren Pro­zes­sor­ar­chi­tek­tu­ren

Um ein Docker-Image eindeutig zu iden­ti­fi­zie­ren, wird ein kryp­to­gra­fi­scher Hash des Image-Manifest errechnet. Beim Aufrufen von „docker image pull“ wird zunächst die Manifest-Datei her­un­ter­ge­la­den. Im Anschluss bezieht der lokale Docker-Deamon die einzelnen Image-Layers.

Wie wir gesehen haben, bilden Docker-Images einen wichtigen Teil des Docker-Öko­sys­tems. Es gibt viel­fäl­ti­ge Mög­lich­kei­ten, ein Docker-Image zu erlangen. Wir un­ter­schei­den zwei grund­le­gen­de Wege, deren Aus­prä­gun­gen wir uns im Folgenden anschauen:

1. Exis­tie­ren­des Docker-Image von Registry beziehen
2. Neues Docker-Image erzeugen

Oft beginnt ein Docker-Projekt mit dem Schritt, ein exis­tie­ren­des Docker-Image von einer so­ge­nann­ten Registry zu beziehen. Dabei handelt es sich um eine über das Netzwerk er­reich­ba­re Plattform, die Docker-Images be­reit­stellt. Der lokale Docker-Host kom­mu­ni­ziert mit der Registry, um in Folge eines „docker image pull“-Befehls ein Docker-Image her­un­ter­zu­la­den.

Zum einen gibt es öf­fent­lich zu­gäng­li­che Online-Registrys. Diese bieten eine große Auswahl exis­tie­ren­der Docker-Image zur Nutzung an. Auf der of­fi­zi­el­len Docker-Registry „Docker-Hub“ sind zum Zeitpunkt der Ar­ti­kel­er­stel­lung mehr als acht Millionen frei ver­füg­ba­re Docker-Images gelistet. Mi­cro­softs „Azure Container Registry“ hält neben Docker-Images weitere Container-Images in ver­schie­de­nen Formaten vor. Ferner erlaubt die Plattform eigene, nicht­öf­fent­li­che Container-Registrys anzulegen.

Neben den genannten Online-Registrys gibt es die Mög­lich­keit, selbst ein lokales Registry zu hosten. Darauf greifen z. B. größere Or­ga­ni­sa­tio­nen zurück, um den eigenen Teams ge­schütz­ten Zugriff auf selbst erstellte Docker-Images zu geben. Von der Firma Docker wird für diesen Zweck das „Docker Trusted Registry“ (DTR) angeboten. Dabei handelt es sich um eine On-Premises-Lösung für das Be­reit­stel­len einer fir­men­in­ter­nen Registry im eigenen Re­chen­zen­trum.

Manchmal möchte man für ein Projekt ein speziell an­ge­pass­tes Docker-Image erstellen. Für ge­wöhn­lich greift man dabei auf ein exis­tie­ren­des Docker-Image zurück und passt dieses nach Bedarf an. Erinnern wir uns, dass Docker-Images un­ver­än­der­lich sind: Pflegen wir Än­de­run­gen ein, ist das Resultat ein neues Docker-Image. Zur Erzeugung eines neuen Docker-Images gibt es die folgenden Wege:

1. Mit Do­cker­file auf Parent-Image aufbauen
2. Aus laufendem Container erzeugen
3. Neues Base-Image erstellen

Der wohl häufigste Ansatz zur Er­stel­lung eines neuen Docker-Image besteht darin, ein Do­cker­file zu schreiben. Das Do­cker­file enthält spezielle An­wei­sun­gen, die das Parent-Image und sämtliche be­nö­tig­ten Än­de­run­gen festlegen. Mit Aufruf von „docker image build“ wird das neue Docker-Image aus dem Do­cker­file erzeugt. Hier ein minimales Beispiel:

His­to­risch stammt der Begriff „Image“ vom „Abbilden“ eines Da­ten­trä­gers (auf Englisch „to image“). Im Kontext vir­tu­el­ler Maschinen (VM) lässt sich aus einem laufenden VM-Image ein Schnapp­schuss erstellen. Ähnlich ist dies auch mit Docker möglich. Mit dem „docker commit“-Befehl legen wir ein Abbild eines laufenden Con­tai­ners als neues Docker-Image an. Sämtliche im Container vor­ge­nom­men Än­de­run­gen werden dabei ge­spei­chert:

Ferner haben wir dir Mög­lich­keit, dem „docker commit“-Befehl Do­cker­file-An­wei­sun­gen zu übergeben. Die mit den An­wei­sun­gen kodierten Än­de­run­gen werden Teil des neuen Docker-Image:

Um im Nach­hin­ein nach­voll­zie­hen zu können, welche Än­de­run­gen zu einem Docker-Image geführt haben, nutzen wir den „docker image history“-Befehl:

Wie wir gesehen haben, basieren wir ein neues Docker-Image auf einem Parent-Image oder Zustand eines laufenden Con­tai­ners. Was jedoch, wenn man für ein neues Docker-Image bei null anfangen möchte? In diesem Fall bieten sich zwei Wege. Man kann wie oben be­schrie­ben eine Do­cker­file mit der spe­zi­el­len „FROM scratch“-Anweisung nutzen. Heraus kommt dabei ein neues, minimales Base-Image.

Möchte man sogar noch auf Dockers scratch-Image ver­zich­ten, nutzt man ein spe­zi­el­les Tool wie de­boot­strap und prä­pa­riert damit eine Linux-Dis­tri­bu­ti­on. Diese wird im Anschluss per tar-Befehl in ein „Tarball“-Archiv verpackt und via „docker image import“ in den lokalen Docker-Host im­por­tiert.