Wenn ein Image erstellt wird, bekommt es eine eindeutige Identifizierung, bestehend aus Zahlen und Buchstaben. Jede \u00c4nderung am Image erzeugt einen neuen Identifizierer. Tats\u00e4chlich arbeiten tut man mit den Identifizieren eigentlich nicht, sondern nur mit den Repositories.<\/p>\n\n\n\n
Repositories<\/h3>\n\n\n\n
Ein Repository ist eine Menge bestehend aus Images. Der Name ist \u00e4hnlich wie eine URL aufgebaut. Er besteht aus dem Host, dem Benutzernamen und einer Kurzbezeichnung, die der Ersteller gew\u00e4hlt hat. Mit : kann man zus\u00e4tzlich noch ein tag anh\u00e4ngen, um eine bestimmte Version zu laden.<\/p>\n\n\n\n
Indices<\/h3>\n\n\n\n
docker pull<\/em> und docker run<\/em> benutzen ohne Angabe eines anderen Repositories stets Docker Hub und dessen Index.<\/p>\n\n\n\n Ein Dockerfile ist ein Skript, das alle Anweisungen enth\u00e4lt, um ein Image zu erzeugen. Docker Hub erzeugt aus dem Dockerfile und den zugeh\u00f6rigen Daten mittels eines continuous build system automatisch Images. Images, die auf diese Art im Docker Hub erzeugt sind, bekommen die Kennzeichnung vertrauensw\u00fcrdig, weil der Weg von den Einzelteilen zum Image bekannt ist.<\/p>\n\n\n\n <\/p>\n\n\n\n An die Images auf Docker Hub kommt man auch ohne Login ran, also warum sollte man sich einen Account anlegen?<\/p>\n\n\n\n F\u00fcr die meisten wird ein Account vielleicht gar nicht n\u00f6tig sein. Wenn man nur die aktuellen Images laden und ausf\u00fchren will, ist ein Account tats\u00e4chlich nicht notwendig.<\/p>\n\n\n\n Ein Account bietet aber ein paar Vorteile. Bei einigen Repositories kann es sogar erforderlich sein, sich anzumelden und damit zu authentifizieren.<\/p>\n\n\n\n Mit einem Account bekommt man Zugriff auf private Repositories. Man erh\u00e4lt die M\u00f6glichkeit, Images selbst hochzuladen und seine eigenen Images zu taggen.<\/p>\n\n\n\n docker login<\/em> und docker logout<\/em> sind die Kommandos, die man dazu braucht. Mit docker search <begriff><\/em> kann man den Index nach dem Begriff durchsuchen lassen. Das Kommando hat einen eingebauten Timeout, es installiert nichts, sondern zeigt nur die gefundenen Treffer an.<\/p>\n\n\n\n Wenn man ein Dockerfile bekommen hat, kann man mit Problem dabei ist, dass sich die Quellen auf die sich das Dockerfile bezieht inzwischen verschoben haben k\u00f6nnten.<\/p>\n\n\n\n Das Erzeugen des Images dauert unter Umst\u00e4nden eine Weile.<\/p>\n\n\n\n Ein Layer ist ein Image, das mit mindestens einem anderen Image verbunden ist. Das Parent Layer ist eine direkte Abh\u00e4ngigkeit vom aktuellen Image.<\/p>\n\n\n\n Wenn man z.B. ein Image benutzt, welches eine SQL-Datenbank braucht, ist das Image mit der SQL-DB ein Parent Layer. Images, die die Datenbank braucht, sind dann keine direkten Abh\u00e4ngigkeiten mehr.<\/p>\n\n\n\n Wenn man ein Image ausf\u00fchrt, werden alle Layer zu einem gemeinsamen Dateisystem zusammengemerged. Man k\u00f6nnte sich die Parent Layer wie DLLs vorstellen, die zur Laufzeit direkt eingebunden werden.<\/p>\n\n\n\n Um aus einem allgemeinen Layer ein speziallisiertes zu machen, reicht es, wenn man die speziellen Dinge in einem neuen Layer einf\u00fcgt.<\/p>\n\n\n\n Docker sucht sich das beste Dateisystem aus f\u00fcr das System auf dem es ausgef\u00fchrt wird. Aber Dateisysteme unterscheiden sich nat\u00fcrlich in ihren Dateiattributen, -gr\u00f6\u00dfen und Regeln f\u00fcr Namen.<\/p>\n\n\n\n Union Dateisysteme m\u00fcssen st\u00e4ndig zwischen den Regeln der Dateisysteme \u00fcbersetzen. Im besten Fall funktioniert das gut, im schlechtesten gehen Features verloren.<\/p>\n\n\n\n Eine Schwierigkeit mit Containern ist, dass sie Daten nicht dauerhaft speichern k\u00f6nnen, weil die Images, aus denen sie erstellt werden, schreibgesch\u00fctzt sind. Wie soll man also Daten, Logs usw. in die \u00e4u\u00dfere Welt bringen?<\/p>\n\n\n\n Die Antwort auf diese Frage sind Volumes.<\/p>\n\n\n\n Der Verzeichnisbaum eines Containers wird aus einem Satz von mount points erzeugt, die beschreiben, wie das Dateisystem zusammen zu setzen ist.<\/p>\n\n\n\n Ein Volume<\/strong> ist ein mount point des Containers, wo ein Teil des Hostverzeichnisbaums eingebunden ist.<\/p>\n\n\n\n Als Beispiel soll folgender Container dienen, in dem ein Programm zwei Dateien schreibt.<\/p>\n\n\n\n Die erste Datei wird nur in die Layer des containers geschrieben und w\u00fcrde beim Beenden der Layer verloren gehen. Die zweite Datei wird an ein Volume geschrieben welches mit dem Host verbunden ist. Die Datei kann nach einem Neustart des Containers wieder benutzt werden.<\/p>\n\n\n\n Man k\u00f6nnte den Zusammenhang zwischen Images und Volumen so beschreiben, dass Images die statischen, unver\u00e4nderlichen Dateien, wie Programme, enth\u00e4lt. W\u00e4hrend Volumen f\u00fcr die sich \u00e4ndernden Daten benutzt werden.<\/p>\n\n\n\n Es gibt zwei Arten von Volumen, die in einem Container gemountet werden k\u00f6nnen.<\/p>\n\n\n\n Bind mounting wird benutzt, wenn man die Dateien bereits auf dem Host hat oder \u00e4u\u00dfere Programme diese Dateien ebenfalls benutzen sollen\/m\u00fcssen.<\/p>\n\n\n\n Wenn man ein Volumen in einen container einbindet, werden die in dem (Container-)Verzeichnis befindlichen Daten ausgeblendet und nur die Dateien des Volumen sind sichtbar.<\/em><\/p>\n\n\n\n Um ein Volumen einzubinden benutzt man die Option -v Wenn man sicherstellen will, dass der Container keine Dateien \u00e4ndern kann, kann man das Volumen als schreibgesch\u00fctzt mounten: Verwendet man ein host-Verzeichnis, das es nicht gibt, legt Docker es f\u00fcr einen an.<\/p>\n\n\n\n Man kann nicht nur Verzeichnisse sondern auch\u00a0 einzelne Dateien binden. Das ist besonders dann sinnvoll, wenn man in ein Verzeichnis, welches bereits Dateien enth\u00e4lt, eine zus\u00e4tzliche Datei hinzuf\u00fcgen will. Die Datei muss vorhanden sein, sonst nimmt Docker an, es handelt sich um ein Verzeichnis und legt es an.<\/p>\n\n\n\n Beispiel<\/strong>: Ein Container enth\u00e4lt einen Web-Shop f\u00fcr einen Kunden. Man kann ihn nun f\u00fcr verschiedene Kunden anpassen, indem man die Bilddatei mit dem Logo (und einige andere Kleinigkeiten) mittels verschiedener eingebundener Volumen austauschen.<\/p>\n\n\n\n Verwaltete Volumen unterscheiden sich von Bind mount indem\u00a0 die Volumen vom Docker daemon in einem von ihm gesch\u00fctzten Bereich angelegt wird.<\/p>\n\n\n\n Damit werden die Volumen von bestimmten Pfaden des Dateisystems entkoppelt. Diese Volumen werden erzeugt, indem nur der mount point bei der Option -v (–volume) angegeben wird Wenn man Volumen zwischen mehreren Containern teilen muss, weil alle auf die selben Dateien zugreifen sollen, hat man nat\u00fcrlich erstmal ein Problem, wenn der Docker daemon die Daten „irgendwo“ ablegt. Um diesem Problem Herr zu werden, gibt es zwei Wege.<\/p>\n\n\n\n Wenn man Bind mount benutzt, ist der offensichtlichste Weg, dass man bei den Aufrufen das gleiche Verzeichnis \u00fcbergibt. Dies wird host-dependant sharing<\/strong> <\/p>\n\n\n\n Um die Volumen nicht f\u00fcr jeden Container neu angeben zu m\u00fcssen, kann man Docker sagen, dass es die Volumen eines oder mehrerer anderer Container \u00fcbernehmen soll. Dies teilt man mit –volumes-from mit.<\/p>\n\n\n\n Verwaltete Volumen haben einen Lebenszyklus, der unabh\u00e4ngig von irgendwelchen Containern ist, aber man kann sie nur \u00fcber die Container referenzieren.<\/p>\n\n\n\n Verwaltete Volumen sind so genannte zweite Klasse Einheiten. Es gibt keinen Weg, sie zu teilen oder zu l\u00f6schen, weil man keine M\u00f6glichkeit hat, sie einzeln zu identifizieren.<\/p>\n\n\n\n Jeder Container, der ein Volumen mountet, kann als dessen Besitzer angesehen werden.<\/p>\n\n\n\n Aufr\u00e4umen von verwalteten Volumen ist eine manuelle Aufgabe. Docker kann keine bind mount Volumen l\u00f6schen, weil diese nicht von Docker verwaltet werden. Docker kann verwaltete Volumen l\u00f6schen, wenn die Container gel\u00f6scht werden. Will man Container zu Verf\u00fcgung stellen, die z.B. Webserver oder Email-Server betreiben, m\u00fcssen sie auch f\u00fcr das Netzwerk freigegeben werden.<\/p>\n\n\n\n Als Protokoll<\/strong> bezeichnet man eine Vereinbarung auf eine gemeinsame Sprache. Docker setzt eine bridge ein, um sein virtuelles Netzwerk mit dem realen Netzwerk des hosts zu verbinden. Docker setzt zwei Arten von virtuellen Netzwerken ein, single-host und multi-host. Die single-host virtual networks dienen dazu, Container zu isolieren.<\/p>\n\n\n\n Alle Container sind mit einem virtuellen Netzwerk docker0<\/em> <\/p>\n\n\n\n Es gibt vier Archetypen und jeder Container folgt genau einem davon:<\/p>\n\n\n\n Container aufr\u00e4umen Wenn Container fertig sind (Status exited) sollten sie aufger\u00e4umt werden, wenn sie nicht gleich wieder verwendet werden. Das geschieht mitdocker rm <ID>Versucht man das bei einem laufenden container, bekommt man eine Fehlermeldung. \u00dcbergibt man beim Erzeugen die Option –rm, wird der container automatisch aufger\u00e4umt, wenn er in den exited-Status wechselt.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[27],"tags":[],"class_list":["post-218","post","type-post","status-publish","format-standard","hentry","category-docker"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/dtp-soft.de\/index.php?rest_route=\/wp\/v2\/posts\/218","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/dtp-soft.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/dtp-soft.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/dtp-soft.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/dtp-soft.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=218"}],"version-history":[{"count":2,"href":"http:\/\/dtp-soft.de\/index.php?rest_route=\/wp\/v2\/posts\/218\/revisions"}],"predecessor-version":[{"id":221,"href":"http:\/\/dtp-soft.de\/index.php?rest_route=\/wp\/v2\/posts\/218\/revisions\/221"}],"wp:attachment":[{"href":"http:\/\/dtp-soft.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=218"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/dtp-soft.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=218"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/dtp-soft.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=218"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Dockerfile<\/h3>\n\n\n\n
Docker-Account, wof\u00fcr?<\/h2>\n\n\n\n
Installation von einem Dockerfile aus<\/h3>\n\n\n\n
docker build –t <repositorie_to_build_into> <dockerfile><\/em>
das Image daraus erzeugen.<\/p>\n\n\n\nLayers
<\/h2>\n\n\n\nSchw\u00e4chen eines gemeinsamen (Union) Dateisystems<\/h2>\n\n\n\n
Volumes<\/h2>\n\n\n\n
![\"\"](\"http:\/\/dtp-soft.de\/wp-content\/uploads\/2018\/10\/Volumes.png\")
Volumenarten<\/h3>\n\n\n\n
Bind mount<\/h4>\n\n\n\n
docker run … -v dir_on_host:mount_in_container<\/em><\/p>\n\n\n\n
docker run … -v dir_on_host:mount_in_container:ro<\/strong><\/em><\/p>\n\n\n\nDocker managed space<\/h4>\n\n\n\n
docker … -v<\/em> mount_point<\/em><\/p>\n\n\n\nVolumen teilen<\/h3>\n\n\n\n
Besitztum der Volumen<\/h4>\n\n\n\n
Volumen l\u00f6schen<\/h4>\n\n\n\n
docker rm -v …<\/em>
versucht alle gebundenen verwalteten Volumen zu l\u00f6schen. Noch von anderen Containern benutzte Volumen k\u00f6nnen nicht gel\u00f6scht werden. L\u00f6scht man einen Container und gibt die Option -v nicht an, entstehen Waisen. Waisen zu l\u00f6schen erfordert viel h\u00e4ndische Arbeit.<\/p>\n\n\n\nNetzwerk<\/h2>\n\n\n\n
Das Interface<\/strong> ist die Adresse eines Gespr\u00e4chspartners.
Eine bridge<\/strong> ist ein Adapter zwischen zwei Netzwerken, um diese miteinander zu verbinden.
<\/p>\n\n\n\nVier Netzwerk Container Archetypen<\/h3>\n\n\n\n