{"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

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 Kanonen auf Spatzen zu schie\u00dfen.<\/p>\n\n\n\n

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

Es hat keinen Zweck sich dar\u00fcber Gedanken zu machen, ob man die neueste Linuxdistribution in Docker testen kann. Grafischen Oberfl\u00e4chen kann man nicht nutzen – nur eben den Browser, wenn es bunt und anklickbar sein soll. Bedeutet, Docker ist was f\u00fcr serverseitige Programme.<\/p>\n\n\n\n

Um mich dem Thema \u00fcberhaupt n\u00e4hern zu k\u00f6nnen, hatte ich mich auf Docker Hub<\/a> umgesehen. In dem 6-teiligen Tutorial auf dem YouTube-Kanal von heise online<\/a> gibt es einige gute Hinweise f\u00fcr die ersten Schritte und wo man eben die f\u00fcr Docker notwendigen Dinger (Images) bekommen kann.<\/p>\n\n\n\n

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

Nat\u00fcrlich bin ich ganz klein angefangen und habe die Konsolenbefehle gelernt. Damit wei\u00df ich dann eben, was passiert, sollte ich sp\u00e4ter mit Docker-Compose (yaml-Script, mache ich jetzt) oder Portainer (eine grafischen Oberfl\u00e4che f\u00fcr Docker) arbeite.<\/p>\n\n\n\n

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

Meine Ausf\u00fchrungen werde ich \u00fcber mehrere Artikel verteilen. Da wir hier im Wiki sind, bitte f\u00fcr Fragen und Anregungen ein entsprechendes Thema im Forum \u00f6ffnen. Danke!<\/p>\n\n\n\n

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

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

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

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

Der Befehl zum Download des Docker-Images f\u00fcr Ghost ist auf der Webseite zu finden. Auf der Konsole ist der entsprechende Befehl auszuf\u00fchren. Dieses muss man mit root-Rechten durchf\u00fchren. Will man als Normaluser die Dockerbefehle ausf\u00fchren, ist mit root-Rechten der User der Gruppe docker hinzuzuf\u00fcgen:<\/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 zum Download eines Images lautet:<\/p>\n\n\n\n
$ docker pull ghost<\/code><\/pre>\n\n\n\n
Will man Ghost 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\u00f6nnte der pull-Befehl 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 abgesetzt ist, wird der Download gestartet und durchgef\u00fchrt. 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 (oder sp\u00e4ter in einer Docker-Compose-Datei) gearbeitet.<\/p>\n\n\n\n
Es gibt sehr viele und unterschiedliche Dockerbefehle.<\/p>\n\n\n\n
Nun haben wir einen pull-Befehl abgesetzt und ein Image heruntergeladen. Mit dem folgenden Befehl (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\u00c4HLEN<\/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\u00f6\u00dfe von 448MB und ist vor 22 Stunden zuletzt aktualisiert worden (von den Entwicklern).<\/p>\n\n\n\n
Als n\u00e4chstes steht an, dass dieses Image irgendwie benutzbar gemacht werden muss. Um ein Image zu nutzen, muss der run-Befehl verwendet werden. Es gibt diverse M\u00f6glichkeiten, um einen run-Befehl zu kreieren. Es ist immer gut, auf der Webseite des Docker-Images nach der Ausf\u00fchrung des run-Befehls zu schauen.<\/p>\n\n\n\n
Die einfachste Ausf\u00fchrung w\u00e4re<\/p>\n\n\n\n
CODE: ALLES AUSW\u00c4HLEN<\/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 wird mit de Option -d<\/strong> gestartet sowie der Option –name<\/strong> gefolgt von einer Bezeichnung, die unser Container haben soll, n\u00e4mlich myghost. Und zum Schluss kommt der Image-Name hinten dran.<\/p>\n\n\n\n
Diesen Befehl setzen wir nicht ab, denn Ghost ist eine Webanwendung. Um eine Webanwendung auch wirklich im Browser starten zu k\u00f6nnen, muss der Befehl 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\u00e4ter http:\/\/localhost:3001<\/a> (oder http:\/\/localhost:3001\/ghost<\/a> f\u00fcr Adminzugang) einzugeben.<\/p>\n\n\n\n
Das Ergebnis der Befehlsausf\u00fchrung 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\u00e4sst. <\/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\u00e4hrt man hier\u00fcber:<\/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 werden die Container angezeigt, die gerade ausgef\u00fchrt 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.<\/p>\n\n\n\n
Damit haben wir ein Image heruntergeladen und einen Container gestartet. Das ein Image sowie ein Container vorhanden sind, k\u00f6nnen wir nun pr\u00fcfen.<\/p>\n\n\n\n
Das Ergebnis unserer Bem\u00fchungen sollte eine laufende Instanz von Ghost 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\u00e4uft. 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\u00f6nnen gestoppt, gestartet und gel\u00f6scht werden. Letztlich k\u00f6nnen Images nur gel\u00f6scht werden, wenn man sie nicht mehr ben\u00f6tigt.<\/p>\n\n\n\n
Um einen Container zu stoppen, k\u00f6nnte 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 wird gepr\u00fcft, ob der zu stoppende Container \u00fcberhaupt l\u00e4uft.
2. Der zweite Befehl stoppt die Ausf\u00fchrung des Container \u00fcber seine ID.
3. Mit dem dritten Befehl wird das Ergebnis der Bem\u00fchungen \u00fcberpr\u00fcft.<\/p>\n\n\n\n
Das Ergebnis ist, dass der Container nicht mehr aktiv ist.<\/p>\n\n\n\n
Nat\u00fcrlich 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\u00e4sst sich die Webseite wieder anzeigen.<\/p>\n\n\n\n
Der letzte Befehl, der noch im Handling der Container wichtig ist, betrifft das L\u00f6schen. Damit ein Container gel\u00f6scht 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\u00fcfung, ob der zu l\u00f6schende Container aktiv ist.
2. Wenn ja, wird der Container gestoppt.
3. Dann wird der Container gel\u00f6scht.
4. – 6. Es wird gepr\u00fcft, ob der Container noch vorhanden ist (ich nutze meist Befehl Nr. 6 nach dem L\u00f6schen).<\/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).<\/p>\n\n\n\n
W\u00e4ren in dem Container Anwendungsdaten vorhanden gewesen, so w\u00e4ren sie jetzt weg. Sobald der Container gel\u00f6scht wird, sind auch die Anwendungsdaten gel\u00f6scht. Gestoppte Container behalten die Daten.<\/p>\n\n\n\n
Generell sollte man in Containern keine Anwendungsdaten speichern. Diese Daten geh\u00f6ren in ein Volume, das au\u00dferhalb des Containers liegt.<\/p>\n\n\n\n
Das L\u00f6schen von Images wird zu einem sp\u00e4teren Zeitpunkt behandelt.<\/p>\n\n\n\n
Teil 3<\/strong><\/h3>\n\n\n\n
Anwendungsdaten k\u00f6nnen gespeichert werden. Allerdings nicht im Container, da geh\u00f6ren sie nicht hin, sondern daf\u00fcr verwendet man Volumes<\/strong>.<\/p>\n\n\n\n
Der generelle Befehl zum Anlegen eines Volumes lautet wie folgt:<\/p>\n\n\n\n
$ docker volume create<\/code><\/pre>\n\n\n\n
Mit diesem Befehl wird ein Volume angelegt, dessen „Name“ aus zuf\u00e4lligen Ziffern und Buchstaben besteht und ellenlang ist.<\/p>\n\n\n\n
Es w\u00e4re schon besser, wenn man dem Kind einen Name gibt:<\/p>\n\n\n\n
$ docker volume create meinvolume<\/code><\/pre>\n\n\n\n
Der letzte Teil des Befehls „meinvolume“ ist nun der Name des Volumes. Ob Volumes vorhanden und wie sie benannt sind, l\u00e4sst 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\u00fcrlich lassen sich, analog zu Images und Containern, Volumens l\u00f6schen.<\/p>\n\n\n\n
Die Volumes werden im Hostsystem abgelegt und k\u00f6nnen ganz normal benutzt werden. Wie bereits weiter oben angedeutet, sind diese Volumes durchaus in die Sicherungsroutinen einzubauen, wenn wichtige Daten in den Volumens erzeugt und gehalten werden. Die Volumens liegen standardm\u00e4\u00dfig hier:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Bitte beachten, dass auch ein in der Gruppe docker angelegter Normaluser den Ordner docker<\/strong> nicht sieht. Hier muss mit sudo gearbeitet werden.<\/p>\n\n\n\n
Volumens enthalten die Anwendungsdaten. Nat\u00fcrlich muss man beim L\u00f6schen von Volumens aufpassen. Im Grunde genommen ist das nichts anderes wie das L\u00f6schen der eigenen Systemfestplatte. <\/p>\n\n\n\n
Folgender Befehl l\u00f6scht 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 wurde das Volume gel\u00f6scht. Mit dem zweiten Befehl wurde \u00fcberpr\u00fcft, ob das Volume tats\u00e4chlich gel\u00f6scht 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\u00fcgt werden kann.<\/p>\n\n\n\n
Dazu lenkt man das Volume an einen definierten Ort. Im Home-Verzeichnis meines Users habe ich einen Ordner dockerdata<\/strong> sowie einen Unterordner ghost<\/strong> angelegt. Ich m\u00f6chte erreichen, dass die Anwendungsdaten im Unterordner gespeichert werden. Dort kann ich sie jederzeit sehen und benutzen wie alle anderen Daten auch.<\/p>\n\n\n\n
Das Verlinken des Volumes auf den Unterordner\u00a0ghost<\/strong>\u00a0kann w\u00e4hrend der Ausf\u00fchrung des run-Befehls 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 ein Container erzeugt wird, wurde weiter oben schon beschrieben. Der aktuelle Befehl wurde um den Zusatz<\/p>\n\n\n\n
\n
-v ~\/dockerdata\/ghost:\/var\/lib\/ghost\/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\u00fcr Volume. Hinter dem Doppelpunkt wird der Originalort angegeben, an dem das Volume liegt.<\/p>\n\n\n\n
In dem Unterordner\u00a0ghost<\/strong>\u00a0unter \/home\/django\/dockerdata wurden nun weitere Ordner angelegt:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Alle Anwendungsdaten, die von nun an in Ghost 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\u00fcgt wurde. Dieses Bild wird im Unterordner\u00a0images<\/strong>\u00a0abgelegt.<\/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 macht durchaus Spa\u00df. Das Handling von Images, Containern und Volumes in der einfachsten Art und Weise, wie bislang beschrieben, ist eine wichtige Grundlage zum Kennenlernen von Docker und seinen vielen M\u00f6glichkeiten.<\/p>\n\n\n\n
Aber man muss auch die Zeit bedenken, die es kostet, immer wieder diese Befehle einzutippen. Inbesondere die Aktionen aus Teil 3 lassen sich sehr gut automatisieren. Und das funktioniert mit docker-compose<\/strong>.<\/p>\n\n\n\n
Bei der Installation von Docker wird dieses Tool nicht installiert. Es l\u00e4sst 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 Befehle von docker-compose sind:<\/p>\n\n\n\n
1. docker-compose up -d
2. docker-compose stop
3. docker-compose down<\/p>\n\n\n\n
Mit dem ersten Befehl wird das Tool im Hintergrund gestartet. Der zweite Befehl stoppt das Tool. Der dritte Befehl f\u00e4hrt das Tool herunter. Sobald das erfolgt, wird auch sofort der Container, der beim Start erzeugt wurde, gel\u00f6scht. 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-compose.<\/p>\n\n\n\n
Das funktioniert aber alles nur, wenn eine entsprechende Konfigurationsdatei vorhanden ist. Diese Konfigurationsdatei muss den Namen docker-compose.yaml<\/strong> haben, sonst l\u00e4uft docker-compose nicht. Die Einr\u00fcckungstiefe der Programmzeilen sollte mit je zwei Leerzeichen erfolgen. Tabs gehe auch, k\u00f6nnen aber Problem verursachen.<\/p>\n\n\n\n
Der Inhalt der Datei 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:
image: ghost
restart: always
ports:
– 8081:2368
volumes:
– .\/ghost:\/var\/lib\/ghost\/content
environment:
url: http:\/\/localhost:8081<\/a><\/p>\n<\/blockquote>\n\n\n\n
Die Ausf\u00fchrung von docker-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\u00fchrung ein Default-Netzwerk eingerichtet. Auch Netzwerke kann man in Docker wie Images, Container und Volumes selber erstellen und verwalten. In dem Script ist das aber nicht erfolgt, daher wird ein Default-Netzwerk ausgef\u00fchrt.<\/p>\n\n\n\n
Ob die Ausf\u00fchrung des Befehl gelungen ist, zeigt wieder eine \u00dcberpr\u00fcfung 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-compose erzeugte Container, der auf Port 8081 l\u00e4uft. Der zweite Container ist der vorhin erstellte Container, der auf Port 3001 gelegt wurde.<\/p>\n\n\n\n
Auch der mit dem Script 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, solange 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\u00e4ter irgendwann 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}]}}