{"id":2187,"date":"2023-09-10T07:59:36","date_gmt":"2023-09-10T05:59:36","guid":{"rendered":"https:\/\/linux-bibel.at\/?p=2187"},"modified":"2023-09-10T08:00:00","modified_gmt":"2023-09-10T06:00:00","slug":"erste-schritte-in-docker","status":"publish","type":"post","link":"https:\/\/linux-bibel.at\/index.php\/2023\/09\/10\/erste-schritte-in-docker\/","title":{"rendered":"Erste Schritte in Docker"},"content":{"rendered":"\n

Wie auf einem Computer die Software Docker<\/a> installiert wird, hat Robert in diesem Artikel bereits beschrieben:<\/p>\n\n\n\n

Docker – Anwendungen und Systeme unter Linux virtualisieren \/ isolieren<\/a><\/p>\n\n\n\n

Bislan<\/a>g habe ich ausschließlich VirtualBox genutzt, um virtuelle Maschinen aufzubauen und etwas auszutesten. Mit Docker<\/a> verspreche ich mir die Möglichkeit, meine Tests auf kleine Füße zu stellen, um nicht immer mit Kanonen auf Spatzen zu schießen.<\/p>\n\n\n\n

Um es vorweg zu nehmen: Aus meiner Sicht ist mein Wunsch in Erfüllung gegangen.<\/p>\n\n\n\n

Es hat keinen Zweck sich darüber Gedanken zu machen, ob man die neueste Linux<\/a>distribution<\/a> in Docker<\/a> testen kann. Grafischen Oberflächen kann man nicht nutzen – nur eben den Browser, wenn es bunt und anklickbar sein soll. Bedeutet, Docker<\/a> ist was für server<\/a>seitige Program<\/a>me.<\/p>\n\n\n\n

Um mich dem Thema überhaupt nähern zu können, hatte ich mich auf Docker Hub<\/a> umgesehen. In dem 6-teiligen Tutor<\/a>ial auf dem YouTube-Kanal von heise online<\/a> gibt es einige gute Hinweise für die ersten Schritte und wo man eben die für Docker<\/a> notwendigen Dinger (Images) bekommen kann.<\/p>\n\n\n\n

Tatsächlich hat es dann etwas gedauert, bis ich die Images, Container und Volumens auseinanderhalten und verwalten konnte.<\/p>\n\n\n\n

Natürlich bin ich ganz klein angefangen und habe die Konsole<\/a>nbefehl<\/a>e gelernt. Damit weiß ich dann eben, was passiert, sollte ich später mit Docker<\/a>-Compose (yaml-Script<\/a>, mache ich jetzt) oder Portainer (eine grafischen Oberfläche für Docker<\/a>) arbeite.<\/p>\n\n\n\n

Heute habe ich für mich den ersten Teil meiner Lernphase für Docker<\/a> abgeschlossen und kann nun via Docker<\/a>-Compose ein Tool starten und die Anwendungsdaten<\/a> in einem externen Volume speichern<\/a>. Das Speichern<\/a> der Anwendungdsdaten<\/a> in den Containern ist suboptimal, weil sie schnell verloren gehen. Daher, wenn man Container produktiv einsetzen möchte, ist das Erlernen mit dem Umgang von Volumes wichtig. Diese Volumes gehören dann zwan<\/a>gsläufig in die Backup<\/a>-Strategie des Computernutzters. \";)\"<\/p>\n\n\n\n

Meine Ausführungen werde ich über mehrere Artikel verteilen. Da wir hier im Wiki<\/a> sind, bitte für Fragen und Anregungen ein entsprechendes Thema im Forum öffnen. Danke!<\/p>\n\n\n\n

Im Docker<\/a> Hub liegen offizielle Images von Docker<\/a> und Images aus der Community. Bislan<\/a>g habe ich mich nur mit den offiziellen Images befast. Zum Lernen ist das wirklich ausreichend.<\/p>\n\n\n\n

Natürlich wollte ich es mir so einfach wie möglichen machen. Mein Lernmaterial bezieht sich auf Ghost<\/a>. Ghost<\/a> ist eine freie Bloggingplattform. Ich kenne das Tool nicht, nur vom Namen her. Zu jedem Docker<\/a>-Images gibt es eine Webseite, die Informationen zur weiteren Verwendung des jeweiligen Images bereithält.<\/p>\n\n\n\n

Auf keinen Fall wollte ich etwas machen, wobei zwei Container gleichzeitig zu nutzen sind. Und nur auf der Konsole<\/a> hantieren, wollte ich auch nicht.<\/p>\n\n\n\n

Teil 1<\/strong><\/h3>\n\n\n\n

Der Befehl<\/a> zum Download des Docker<\/a>-Images für Ghost<\/a> ist auf der Webseite zu finden. Auf der Konsole<\/a> ist der entsprechende Befehl<\/a> auszuführen. Dieses muss man mit root<\/a>-Rechten durchführen. Will man als Normaluser die Docker<\/a>befehl<\/a>e ausführen, ist mit root<\/a>-Rechten der User der Gruppe docker<\/a> hinzuzufügen:<\/p>\n\n\n\n

$ usermod -aG docker username<\/code><\/pre>\n\n\n\n
Nach einer Neuanmeldung kann der Normaluser ohne „sudo<\/code>“ arbeiten.<\/p>\n\n\n\n
Der einfachste Befehl<\/a> zum Download eines Images lautet:<\/p>\n\n\n\n
$ docker pull ghost<\/code><\/pre>\n\n\n\n
Will man Ghost<\/a> mit einer bestimmten Version nutzen bzw. ausprobieren, muss man mit sogenannten TAGS arbeiten. Diese TAGS beschreiben im Grunde genommen die Version bzw. die Versionsreihe. Dann könnte der pull-Befehl<\/a> z.B. so aussehen, wenn es die neueste Version sein soll:<\/p>\n\n\n\n
$ docker pull ghost:latest<\/code><\/pre>\n\n\n\n
Die Defaulteinstellung lautet wohl immer auf den TAG latest<\/strong>.<\/p>\n\n\n\n
Nachdem der einfache Pull-Befehl<\/a> abgesetzt ist, wird der Download gestartet und durchgeführt. Das Ergebnis sind wie folgt aus:<\/p>\n\n\n\n
Using default tag: latest\nlatest: Pulling from library\/ghost\ne1acddbe380c: Pull complete \n7263c7b7f332: Pull complete \n0e985e216445: Pull complete \n75a9268f63ec: Pull complete \n15b30c5db6de: Pull complete \n46e57f8bb6f3: Pull complete \n76bb54f82d33: Pull complete \nef365ad3ce09: Pull complete \nd9989d0de9cc: Pull complete \nDigest: sha256:26e68af5cfe2902f7e1524bdb1ac77f1fcd6ffd462a990f80aff595008c1d926\nStatus: Downloaded newer image for ghost:latest\ndocker.io\/library\/ghost:latest<\/code><\/pre>\n\n\n\n
Der interessierte User wird sich nun fragen, wo denn der Download abgelegt wird. Wo liegt das Image?<\/p>\n\n\n\n
Leider ist das nicht offensichtlich, denn im Downloadordner liegt es nicht.<\/p>\n\n\n\n
Es liegt hier:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Aber das Images selber interessiert uns nicht, denn damit wird nur auf der Konsole<\/a> (oder später in einer Docker<\/a>-Compose-Datei<\/a>) gearbeitet.<\/p>\n\n\n\n
Es gibt sehr viele und unterschiedliche Docker<\/a>befehl<\/a>e.<\/p>\n\n\n\n
Nun haben wir einen pull-Befehl<\/a> abgesetzt und ein Image heruntergeladen. Mit dem folgenden Befehl<\/a> (incl. Ergebnis) kann man feststellen, ob es wirklich vorhanden ist und welche anderen Images es vielleicht noch gibt:<\/p>\n\n\n\n
CODE: ALLES AUSWÄHLEN<\/a><\/p>\n\n\n\n
$ docker image ls\nREPOSITORY   TAG       IMAGE ID       CREATED        SIZE\nghost        latest    b05a58075ef6   22 hours ago   448MB<\/code><\/pre>\n\n\n\n
In diesem Fall liegt derzeit nur ein Image auf dem Rechner, hat eine Größe von 448MB und ist vor 22 Stunden zuletzt aktualisiert worden (von den Entwicklern).<\/p>\n\n\n\n
Als nächstes steht an, dass dieses Image irgendwie benutzbar gemacht werden muss. Um ein Image zu nutzen, muss der run-Befehl<\/a> verwendet werden. Es gibt diverse Möglichkeiten, um einen run-Befehl<\/a> zu kreieren. Es ist immer gut, auf der Webseite des Docker<\/a>-Images nach der Ausführung des run-Befehl<\/a>s zu schauen.<\/p>\n\n\n\n
Die einfachste Ausführung wäre<\/p>\n\n\n\n
CODE: ALLES AUSWÄHLEN<\/a><\/p>\n\n\n\n
$ docker run -d --name myghost ghost<\/code><\/pre>\n\n\n\n
Was steckt dahinter?<\/p>\n\n\n\n
Der run-Befehl<\/a> wird mit de Option -d<\/strong> gestartet sowie der Option –name<\/strong> gefolgt von einer Bezeichnung, die unser Container haben soll, nämlich myghost<\/a>. Und zum Schluss kommt der Image-Name hinten dran.<\/p>\n\n\n\n
Diesen Befehl<\/a> setzen wir nicht ab, denn Ghost<\/a> ist eine Webanwendung. Um eine Webanwendung auch wirklich im Browser starten zu können, muss der Befehl<\/a> erweitert werden:<\/p>\n\n\n\n
$ docker run -d --name myghost -e url=http:\/\/localhost:3001 -p 3001:2368 ghost<\/code><\/pre>\n\n\n\n
In die Adresszeile des Browsers ist später http:\/\/localhost:3001<\/a> (oder http:\/\/localhost:3001\/ghost<\/a> für Adminzugang) einzugeben.<\/p>\n\n\n\n
Das Ergebnis der Befehl<\/a>sausführung sieht wie folgt aus:<\/p>\n\n\n\n
a92b1f1e260d72392c211a4d06c8855a6f5d096d0fd92ea7716267be6befd9e0<\/code><\/pre>\n\n\n\n
Mehr ist in der Tat nicht zu sehen, da die Option -d<\/strong> alles unsichtbar im Hintergrund ablaufen lässt. <\/p>\n\n\n\n
Damit haben wir unseren ersten Container gestartet. Ob das wirklich so ist, und ob vielleicht noch mehr Container vorhanden sind, erfährt man hierüber:<\/p>\n\n\n\n
$ docker container ls -a\nCONTAINER ID   IMAGE     COMMAND                  CREATED              STATUS              PORTS                                       NAMES\na92b1f1e260d   ghost     \"docker-entrypoint.s\u2026\"   About a minute ago   Up About a minute   0.0.0.0:3001->2368\/tcp, :::3001->2368\/tcp   myghost<\/code><\/pre>\n\n\n\n
Mit folgendem Befehl<\/a> werden die Container angezeigt, die gerade ausgeführt werden:<\/p>\n\n\n\n
$ docker ps\nCONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                                       NAMES\na92b1f1e260d   ghost     \"docker-entrypoint.s\u2026\"   4 minutes ago   Up 4 minutes   0.0.0.0:3001->2368\/tcp, :::3001->2368\/tcp   myghost<\/code><\/pre>\n\n\n\n
Das ist nahezu die gleiche Anzeige wie beim ls<\/code>-Befehl<\/a>.<\/p>\n\n\n\n
Damit haben wir ein Image heruntergeladen und einen Container gestartet. Das ein Image sowie ein Container vorhanden sind, können wir nun prüfen.<\/p>\n\n\n\n
Das Ergebnis unserer Bemühungen sollte eine laufende Instanz von Ghost<\/a> in unserem Browser sein:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Teil 2<\/strong><\/h3>\n\n\n\n
Der erste Container läuft. Was man damit jetzt weiter macht, spielt im Moment noch keine Rolle.<\/p>\n\n\n\n
Das Handling von Images und Containern ist noch nicht beendet, denn Container können gestoppt, gestartet und gelöscht werden. Letztlich können Images nur gelöscht werden, wenn man sie nicht mehr benötigt.<\/p>\n\n\n\n
Um einen Container zu stoppen, könnte man so vorgehen:<\/p>\n\n\n\n
$ docker ps\nCONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                       NAMES\na92b1f1e260d   ghost     \"docker-entrypoint.s\u2026\"   26 minutes ago   Up 26 minutes   0.0.0.0:3001->2368\/tcp, :::3001->2368\/tcp   myghost\n$ docker stop a92b1f1e260d\na92b1f1e260d\n$ docker ps\nCONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES<\/code><\/pre>\n\n\n\n
1. Mit dem ersten Befehl<\/a> wird geprüft, ob der zu stoppende Container überhaupt läuft.
2. Der zweite Befehl<\/a> stoppt die Ausführung des Container über seine ID.
3. Mit dem dritten Befehl<\/a> wird das Ergebnis der Bemühungen überprüft.<\/p>\n\n\n\n
Das Ergebnis ist, dass der Container nicht mehr aktiv ist.<\/p>\n\n\n\n
Natürlich kann man einen Container auch wieder starten. Das sieht dann wie folgt aus:<\/p>\n\n\n\n
$ docker start a92b1f1e260d\na92b1f1e260d\n$ docker ps\nCONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS        PORTS                                       NAMES\na92b1f1e260d   ghost     \"docker-entrypoint.s\u2026\"   29 minutes ago   Up 1 second   0.0.0.0:3001->2368\/tcp, :::3001->2368\/tcp   myghost<\/code><\/pre>\n\n\n\n
Damit ist der Container wieder aktiv und ebenfalls lässt sich die Webseite wieder anzeigen.<\/p>\n\n\n\n
Der letzte Befehl<\/a>, der noch im Handling der Container wichtig ist, betrifft das Löschen. Damit ein Container gelöscht werden kann, muss er stoppt sein. Ingesamt kann das so ablaufen:<\/p>\n\n\n\n
$ docker ps\nCONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS         PORTS                                       NAMES\na92b1f1e260d   ghost     \"docker-entrypoint.s\u2026\"   32 minutes ago   Up 2 minutes   0.0.0.0:3001->2368\/tcp, :::3001->2368\/tcp   myghost\n$ docker stop a92b1f1e260d\na92b1f1e260d\n$ docker container rm a92b1f1e260d\na92b1f1e260d\n$ docker ps\nCONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES\n$ docker ps -a\nCONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES\n$ docker container ls -a\nCONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES<\/code><\/pre>\n\n\n\n
1. Prüfung, ob der zu löschende Container aktiv ist.
2. Wenn ja, wird der Container gestoppt.
3. Dann wird der Container gelöscht.
4. – 6. Es wird geprüft, ob der Container noch vorhanden ist (ich nutze meist Befehl<\/a> Nr. 6 nach dem Löschen).<\/p>\n\n\n\n
Der Container ist nun weg. Geblieben ist das Image. Denn mit dem Image kann man jederzeit einen neuen Container erstellen (run-Befehl<\/a>).<\/p>\n\n\n\n
Wären in dem Container Anwendungsdaten<\/a> vorhanden gewesen, so wären sie jetzt weg. Sobald der Container gelöscht wird, sind auch die Anwendungsdaten<\/a> gelöscht. Gestoppte Container behalten die Daten<\/a>.<\/p>\n\n\n\n
Generell sollte man in Containern keine Anwendungsdaten<\/a> speichern<\/a>. Diese Daten<\/a> gehören in ein Volume, das außerhalb des Containers liegt.<\/p>\n\n\n\n
Das Löschen von Images wird zu einem späteren Zeitpunkt behandelt.<\/p>\n\n\n\n
Teil 3<\/strong><\/h3>\n\n\n\n
Anwendungsdaten<\/a> können gespeichert werden. Allerdings nicht im Container, da gehören sie nicht hin, sondern dafür verwendet man Volumes<\/strong>.<\/p>\n\n\n\n
Der generelle Befehl<\/a> zum Anlegen eines Volumes lautet wie folgt:<\/p>\n\n\n\n
$ docker volume create<\/code><\/pre>\n\n\n\n
Mit diesem Befehl<\/a> wird ein Volume angelegt, dessen „Name“ aus zufälligen Ziffern und Buchstaben besteht und ellenlan<\/a>g ist.<\/p>\n\n\n\n
Es wäre schon besser, wenn man dem Ki<\/a>nd einen Name gibt:<\/p>\n\n\n\n
$ docker volume create meinvolume<\/code><\/pre>\n\n\n\n
Der letzte Teil des Befehl<\/a>s „meinvolume“ ist nun der Name des Volumes. Ob Volumes vorhanden und wie sie benannt sind, lässt sich wie folgt feststellen:<\/p>\n\n\n\n
$ docker volume create meinvolume\nmeinvolume\n$ docker volume ls\nDRIVER    VOLUME NAME\nlocal     0bf98e29f96b7bf612a0b183bc4b43007142f3244eb3e9cd0033dae29f92ee57\nlocal     445e2c5a1e8f0b7319bca133189a910ce388566bec53968f87adfb8ee1e2f640\nlocal     a36d2c024a46485c50549b59a6da30da3d110530d9555c3e92a02bff9e0adb3c\nlocal     meinvolume<\/code><\/pre>\n\n\n\n
Aus meiner Sicht ist der lesbare Volumenname angenehmer als die 3 bereits bestehenden Volumes aus meiner Testphase, die ich absichtlich habe bestehen lassen. Natürlich lassen sich, analog zu Images und Containern, Volumens löschen.<\/p>\n\n\n\n
Die Volumes werden im Host<\/a>system abgelegt und können ganz normal benutzt werden. Wie bereits weiter oben angedeutet, sind diese Volumes durchaus in die Sicherungsroutinen einzubauen, wenn wichtige Daten<\/a> in den Volumens erzeugt und gehalten werden. Die Volumens liegen standardmäßig hier:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Bitte beachten, dass auch ein in der Gruppe docker<\/a> angelegter Normaluser den Ordner docker<\/a><\/strong> nicht sieht. Hier muss mit sudo<\/a> gearbeitet werden.<\/p>\n\n\n\n
Volumens enthalten die Anwendungsdaten<\/a>. Natürlich muss man beim Löschen von Volumens aufpassen. Im Grunde genommen ist das nichts anderes wie das Löschen der eigenen Systemfestplatte. <\/p>\n\n\n\n
Folgender Befehl<\/a> löscht ein Volume:<\/p>\n\n\n\n
$ docker volume rm meinvolume\nmeinvolume\n$ docker volume ls\nDRIVER    VOLUME NAME\nlocal     0bf98e29f96b7bf612a0b183bc4b43007142f3244eb3e9cd0033dae29f92ee57\nlocal     445e2c5a1e8f0b7319bca133189a910ce388566bec53968f87adfb8ee1e2f640\nlocal     a36d2c024a46485c50549b59a6da30da3d110530d9555c3e92a02bff9e0adb3c<\/code><\/pre>\n\n\n\n
Mit dem ersten Befehl<\/a> wurde das Volume gelöscht. Mit dem zweiten Befehl<\/a> wurde überprüft, ob das Volume tatsächlich gelöscht wurde.<\/p>\n\n\n\n
Es ist nicht wirklich vorteilhaft, wenn die Volumes irgendwo in den Tiefen des Systems versteckt liegen. Es macht Sinn, dass man eine Struktur aufbaut, die alle Volumes beinhaltet und somit auch einfach in die Sicherungsroutinen eingefügt werden kann.<\/p>\n\n\n\n
Dazu lenkt man das Volume an einen definierten Ort. Im Home<\/a>-Verzeichnis<\/a> meines Users habe ich einen Ordner docker<\/a>data<\/strong> sowie einen Unterordner ghost<\/a><\/strong> angelegt. Ich möchte erreichen, dass die Anwendungsdaten<\/a> im Unterordner gespeichert werden. Dort kann ich sie jederzeit sehen und benutzen wie alle anderen Daten<\/a> auch.<\/p>\n\n\n\n
Das Verlinken des Volumes auf den Unterordner ghost<\/a><\/strong> kann während der Ausführung des run-Befehl<\/a>s erfolgen. Das sieht dann sehr kryptisch aus:<\/p>\n\n\n\n
docker run -d --name myghost -e url=http:\/\/localhost:3001 -p 3001:2368 -v ~\/dockerdata\/ghost:\/var\/lib\/ghost\/content ghost<\/code><\/pre>\n\n\n\n
Wie mit dem run-Befehl<\/a> ein Container erzeugt wird, wurde weiter oben schon beschrieben. Der aktuelle Befehl<\/a> wurde um den Zusatz<\/p>\n\n\n\n
\n
-v ~\/docker<\/a>data\/ghost<\/a>:\/var\/lib\/ghost<\/a>\/content<\/p>\n<\/blockquote>\n\n\n\n
erweitert. Die Option –<\/p>\n\n\n\n
v<\/code><\/pre>\n\n\n\n
steht für Volume. Hinter dem Doppelpunkt wird der Originalort angegeben, an dem das Volume liegt.<\/p>\n\n\n\n
In dem Unterordner ghost<\/a><\/strong> unter \/home<\/a>\/django\/docker<\/a>data wurden nun weitere Ordner angelegt:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Alle Anwendungsdaten<\/a>, die von nun an in Ghost<\/a> erstellt oder hingebracht werden, werden in diesen Ordnern gespeichert.<\/p>\n\n\n\n
Ich habe mich als Admin angemeldet und einen ersten Artikel geschrieben, in dem ein Bild eingefügt wurde. Dieses Bild wird im Unterordner images<\/strong> abgelegt.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Auf der Webseite ist das Ergebnis der Artikelerstellung auch zu bewundern:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Teil 4<\/strong><\/h3>\n\n\n\n
Das Arbeiten in\/auf der Konsole<\/a> macht durchaus Spaß. Das Handling von Images, Containern und Volumes in der einfachsten Art und Weise, wie bislan<\/a>g beschrieben, ist eine wichtige Grundlage zum Kennenlernen von Docker<\/a> und seinen vielen Möglichkeiten.<\/p>\n\n\n\n
Aber man muss auch die Zeit bedenken, die es kostet, immer wieder diese Befehl<\/a>e einzutippen. Inbesondere die Aktionen aus Teil 3 lassen sich sehr gut automatisieren. Und das funktioniert mit docker<\/a>-compose<\/strong>.<\/p>\n\n\n\n
Bei der Installation von Docker<\/a> wird dieses Tool nicht installiert. Es lässt sich aber ganz flott nachinstallieren:<\/p>\n\n\n\n
sudo apt-get install docker-compose<\/code><\/pre>\n\n\n\n
Die 3 wichtigsten Befehl<\/a>e von docker<\/a>-compose sind:<\/p>\n\n\n\n
1. docker<\/a>-compose up -d
2. docker<\/a>-compose stop
3. docker<\/a>-compose down<\/p>\n\n\n\n
Mit dem ersten Befehl<\/a> wird das Tool im Hintergrund gestartet. Der zweite Befehl<\/a> stoppt das Tool. Der dritte Befehl<\/a> fährt das Tool herunter. Sobald das erfolgt, wird auch sofort der Container, der beim Start erzeugt wurde, gelöscht. Man muss eigentlich als User nichts mehr machen, um im Container zu arbeiten bzw. die Arbeit mit dem Container zu beenden. Das macht eben docker<\/a>-compose.<\/p>\n\n\n\n
Das funktioniert aber alles nur, wenn eine entsprechende Konfiguration<\/a>sdatei<\/a> vorhanden ist. Diese Konfiguration<\/a>sdatei<\/a> muss den Namen docker<\/a>-compose.yaml<\/strong> haben, sonst läuft docker<\/a>-compose nicht. Die Einrückungstiefe der Program<\/a>mzeilen sollte mit je zwei Leerzeichen erfolgen. Tabs gehe auch, können aber Problem verursachen.<\/p>\n\n\n\n
Der Inhalt der Datei<\/a> ist nun so aufgebaut, dass das gleiche erreicht wird, wie in den obigen Beschreibungen dargestellt. So sieht es aus:<\/p>\n\n\n\n
\n
version: ‚3.1‘<\/p>\n\n\n\n
services:<\/p>\n\n\n\n
meinghost<\/a>:
image: ghost<\/a>
restart: always
ports<\/a>:
– 8081:2368
volumes:
– .\/ghost<\/a>:\/var\/lib\/ghost<\/a>\/content
environment:
url: http:\/\/localhost:8081<\/a><\/p>\n<\/blockquote>\n\n\n\n
Die Ausführung von docker<\/a>-compose zum Start des Tools ist dann wie folgt vorzunehmen:<\/p>\n\n\n\n
$ docker-compose up -d\nCreating network \"dockerdata_default\" with the default driver\nCreating dockerdata_meinghost_1 ... done\n<\/code><\/pre>\n\n\n\n
Es wird bei der Ausführung ein Default-Netzwerk<\/a> eingerichtet. Auch Netzwerk<\/a>e kann man in Docker<\/a> wie Images, Container und Volumes selber erstellen und verwalten. In dem Script<\/a> ist das aber nicht erfolgt, daher wird ein Default-Netzwerk<\/a> ausgeführt.<\/p>\n\n\n\n
Ob die Ausführung des Befehl<\/a> gelungen ist, zeigt wieder eine Überprüfung der laufenden Container:<\/p>\n\n\n\n
$ docker ps -a\nCONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                       NAMES\n3311a4b8aa24   ghost     \"docker-entrypoint.s\u2026\"   4 minutes ago    Up 4 minutes    0.0.0.0:8081->2368\/tcp, :::8081->2368\/tcp   dockerdata_meinghost_1\n52e8545e09eb   ghost     \"docker-entrypoint.s\u2026\"   32 minutes ago   Up 32 minutes   0.0.0.0:3001->2368\/tcp, :::3001->2368\/tcp   myghost<\/code><\/pre>\n\n\n\n
Hier ist zu sehen, dass zwei Container laufen. Der erste Container ist der mit docker<\/a>-compose erzeugte Container, der auf Port 8081 läuft. Der zweite Container ist der vorhin erstellte Container, der auf Port 3001 gelegt wurde.<\/p>\n\n\n\n
Auch der mit dem Script<\/a> erzeugte Container nutzt das vorhandene Volume und zeigt die gleiche Webseite an.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Egal, was mit den Containern passiert, solan<\/a>ge das Volume unangetastet bleibt, kann man mit jedem Container auf das Volume zugreifen. Allerdings muss man beim Wechsel des Image aufpassen. Man kann nicht einfach so eine andere Version des Images nutzen. Dazu später irgendwan<\/a>n mal mehr.<\/p>\n\n\n\n
Verfasst von Bommo<\/p>\n
\r\n    
\r\n    \r\n                            \"Gef\u00e4llt\r\n            <\/a>\r\n    1    <\/span>\r\n<\/div>
\r\n    \r\n                            \"Gef\u00e4llt\r\n            <\/a>\r\n    <\/span>\r\n<\/div><\/div>","protected":false},"excerpt":{"rendered":"
Wie auf einem Computer die Software Docker installiert wird, hat Robert in diesem Artikel bereits beschrieben: Docker – Anwendungen und Systeme unter Linux virtualisieren \/ isolieren Bislang habe ich ausschlie\u00dflich VirtualBox genutzt, um virtuelle Maschinen aufzubauen und etwas auszutesten. Mit Docker verspreche ich mir die M\u00f6glichkeit, meine Tests auf kleine F\u00fc\u00dfe zu stellen, um nicht immer mit […]<\/p>\n","protected":false},"author":1,"featured_media":2194,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66,67],"tags":[68,69],"class_list":["post-2187","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-docker","category-virtualisierung","tag-docker","tag-virtualisierung"],"_links":{"self":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/2187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/comments?post=2187"}],"version-history":[{"count":2,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/2187\/revisions"}],"predecessor-version":[{"id":2196,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/posts\/2187\/revisions\/2196"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/media\/2194"}],"wp:attachment":[{"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/media?parent=2187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/categories?post=2187"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/linux-bibel.at\/index.php\/wp-json\/wp\/v2\/tags?post=2187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}