Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Virtualisierung mit Docker

Grundlagen zum Docker-Buildfile

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Das Docker-Buildfile ist - wenn auch nicht sofort ersichtlich - einer der Hauptgründe für die Existenz von Docker. Machen Sie sich daher zunächst mit den Grundlagen zum Buildfile vertraut.

Transkript

Docker ist nicht nur bekannt für die völlig neue Art der Virtualisierung, die es zum Einsatz bringt, sondern vor allem auch für viele moderne Prinzipien, die im Zuge der Bereitstellung einer Anwendung bzw. eines Servers genutzt werden. Ein wesentlicher Teilaspekt hiervon ist, das so genannte Docker-Buidfile. Und auch Sie interessieren sich sicherlich, was dahinter steckt. Im Grunde ist das Docker-Buildfile nichts weiter als ein Makefile. Oder es verfolgt zumindest dieselben Prinzipien. Es handelt sich also um eine Art von Beschreibungssprache, wie etwas zusammengebaut wird. Das Zusammengebaute ist hier das jeweilig resultierende Docker-Image. Es handelt sich vor allem hier um sehr einfache Anweisungen. Denn keine Art von Logik, also Überprüfung, ob bestimmte Voraussetzungen getroffen sind oder auch nicht, ist möglich mit Hilfe des Docker-Buildfiles selbst abzubilden. Es handelt sich lediglich um simple Anweisungen, wie Führe Anwendung aus und Stelle jene Konfiguration bereit. Im Idealbild ist dieses Docker-Buildfile genauso versionert wie auch klassischerweise Code versioniert wird. Das heißt, Docker an sich versioniert nur die resultierenden Artefakte, also die so genannten Images. Das Docker-Buildfile selbst, also diese textuelle Beschreibungsdatei wird idealerweise in einem Versionskontrollsystem wie GIT versioniert. Fast alle auf dem Docker-Hub befindlichen Images haben auch ihr Docker-Buildfile dementsprechend in GIT hinterlegt. In dem Fall auf GitHub. Mit Hilfe eines solchen Versionskontrollsystemes lässt es sich also nun relativ einfach nachvollziehen, wie der Aufbau der Maschine sich über die Zeit hinweg verändert hat. Das Interessante ist an der Stelle auch, dass Docker mit Hilfe eines so genannten Caching-Mechanismus in der Lage ist, die einzelnen Teilschritte, die in dem Buildfile beschrieben sind relativ zügig auszuführen, wenn diese Schritte schon mal ausgeführt worden sind. Das bedeutet, der Prozess des Projektaufbaus anhand der Anweisungsdatei, wenn sich diese auch verändert haben. Nun befinde ich mich also in einem Ordner, in dem ein solches Docker-File vorliegt. Wichtig ist, dass das Docker-Buildfile als solches auch den korrekten Namen Docker-File tragen muss. Ansonsten erkennt die Docker- Anwendung das Docker-File nicht an. Wenn ich diese Datei nun inspiziere, sehe ich zunächst einmal, die Möglichkeit Kommentare anzugeben mit Hilfe der Raute und als nächstes dipe allererste Anweisung in diesem Docker-File ist die Referenz auf ein anderes Image, von dessen Basis aus alle weiteren Schritte ausgeführt werden. Docker wird also an dieser Stelle nun dieses Image herunterladen und auf diesem Image einen Container starten, in dem der Folgebefehl ausgeführt wird. Der Folgebefehl ist hier der run-Befehl, der all diese Zeilen ausführt innerhalb des Containers. In diesem Fall wird zunächst einmal der apt-Key importiert, um dementsprechend vom Repository von Ubuntu die binary Pakete herunterladen zu können. In dem Fall handelt es sich um die Installation einer Mongo-Datenbank. Als nächstes wird eine Anweisung gegeben, die Docker mitteilt, dass es einen Ordner innerhalb dieses Images nun gibt, der potenziell nach außen getragen werden kann. Das heißt, der Nutzer dieses Images kann entscheiden, ob er diesen Ordner speziell auf einen anderen Mountpunkt verschieben möchte, um beispielsweise die Daten extern zu lagern. Im Falle von Datenbankdaten kann es durchaus Sinn machen, diese Daten nicht innerhalb des Images bzw. des laufenden Containers vorzuhalten, sondern auf einer externen Partition. Als Nächstes wird der Startpunkt verschoben, von dem aus alle Folgeanweisungen starten. In dem Fall ist im Ordner data nun die binary Datei mongod, also der Mongo-Server und dieser wird über die cmd-Referenz nun als Standard Kommando beim Hochfahren des Containers festgelegt. Zu guter Letzt wird in diesem Buildfile noch beschrieben, dass es zwei Ports gibt, die potenziell relevant sind für die Nutzer des Images. Während also nun die letzten Schritte lediglich Hinweise für Docker sind, die die Konfiguration von Docker selbst betreffen, handelt es sich hier oben um Anweisungen, die innerhalb eines Containers ausgeführt werden müssen. Um diesen Build-Prozess nun zu starten befindet man sich also in dem Ordner, wo das Docker-File liegt, und nutzt den docker build-Befehl. In meinem Fall vergebe ich den tag mongo nun für mein neues Image. Das heißt, zukünftig wird es ein Image Mongo geben, sobald der Build-Prozess abgeschlossen ist. Und durch den Punkt referenziere ich das Docker-File im aktuellen Ordner. Wenn ich diesen Prozess starte, sieht man, wie in einzelnen Schritten Container gestartet werden und die jeweiligen Daten, die im Ausführungsschritt benötigt werden, heruntergeladen werden. Nachdem der Vorgang nun abgeschlossen ist, kann man in der Historie betrachtet noch einmal sehen, dass jeweils jeder einzelne Befehl beispielsweise auch der CMD-Befehl, in einem eigenen Container zeitweise lief. In meinen Docker-Images finde ich nun das von mir soeben erstellte neue Docker-Image Mongo vor. Interessant zu sehen ist noch, wenn ich den build-Befehl noch einmal durchführe beispielsweise um Mongo 2 herzustellen, werden die ganzen Schritte nicht noch einmal durchgeführt. Das heißt, für alle Schritte denen Docker bekannt war, dass sie bereits einmal genau in der Form durchgeführt worden, nutzt es den Cash. Würde ich nun einen Befehl später hier hinzufügen, würden alle Folgebefehle nicht mehr den Cash benutzen. Sie haben nun also die Prinzipien des Docker-Buildfiles kennengelernt und auch ein erstes Docker-Buildfile auf der Kommandozeile ausgeführt.

Virtualisierung mit Docker

Steigen Sie in die Container-Virtualisierung ein und entdecken Sie einfaches Prototyping neuer und unkomplizierte Skalierung bestehender Anwendungen.

3 Std. 36 min (36 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!