Warum sollte ich mit einem Dockerfile ein eigenes Image erstellen?<\/h2>\n
Haupts\u00e4chlich gibt es zwei Gr\u00fcnde:<\/p>\n
- \n
- Um ein vorhandenes Image umfangreicher anzupassen<\/li>\n
- Zum „Containerisieren“ von Programmen, f\u00fcr die noch kein bzw. kein (offizielles) Image existiert<\/li>\n<\/ol>\n
Wie sieht ein Dockerfile genau aus?<\/h2>\n
Der grunds\u00e4tzliche Aufbau eines Dockerfiles ist leicht erkl\u00e4rt: Kommentare werden mit einer Raute # eingeleitet. Alle Befehle weisen das Format ANWEISUNG <Argumente><\/strong> auf:<\/p>\n
# Diese Zeile wird ignoriert\nANWEISUNG <Argumente><\/code><\/pre>\nDa sich Docker durch Modularit\u00e4t auszeichnet, gibt es immer ein Basis-Image<\/strong>. Es wird mit der Anweisung FROM<\/strong> definiert, das Argument ist der Name des Basis-Images. Alles was dort drin ist, wird auch in unserem Image enthalten sein – es sei denn, wir \u00e4ndern und entfernen etwas davon. In der Praxis ist das Dockerfile <\/strong>eine Textdatei mit gleichem Name, ohne .txt oder anderen Erweiterungen. Ich empfehle, pro Dockerfile einen eigenen Ordner zu erstellen.<\/p>\n
Unser erstes Dockerfile: Wir f\u00fcgen eine Datei hinzu<\/h2>\n
Beginnen wir mit dem ersten Grund, er ist am einfachsten: Wir haben ein Image, dass grunds\u00e4tzlich unseren Vorstellungen entspricht. Aber es gibt Dinge, die angepasst werden sollen. Ein m\u00f6gliches Szenario ist der Apache2 Webserver mit mod_php aus dem vorherigen Beitrag. Hier wird ein PHP-Modul ben\u00f6tigt, etwa MySQLi um sich zu einer MySQL-Datenbank verbinden zu k\u00f6nnen. Dies ist standardm\u00e4\u00dfig nicht enthalten bzw. nicht aktiviert.<\/p>\n
Um das zu \u00e4ndern, legen wir uns einen Ordner an, erzeugen eine Datei namens Dockerfile<\/strong> ohne Erweiterung und \u00f6ffnen sie. Es macht Sinn, mit der FROM <\/strong>Anweisung zu beginnen. Nach einem Leerzeichen geben wir das Apache-PHP-Image mit dem gew\u00fcnschten Tag an, etwa<\/p>\n
FROM php:8-apache-buster<\/code><\/pre>\n\nAn dieser Stelle wird das Buster-Image (Version 10, statt dem zum Erstellzeitpunkt aktuellsten Bullseye 11) image genutzt. Hintergrund ist dieser Bug im PHP-Image<\/a>, wodurch der sp\u00e4ter verwendete Befehl <\/p>\ndocker-php-ext-install<\/pre>\n
ohne Ausgabe nie fertiggestellt wird. Bitte den Status im verlinkten Bugticket pr\u00fcfen, falls dieser Fehler behoben ist, kann man auch aktuellere Images nutzen! Buster erh\u00e4lt noch bis Ende 2022 Sicherheitsupdates.\n<\/p><\/div>\n
Die wohl wichtigste Anweisung nach FROM <\/strong>hei\u00dft RUN<\/strong>: Damit f\u00fchrt man einen beliebigen Linux-Befehl aus. Wir nutzen im Folgenden die Shell-Form<\/em>, das hei\u00dft: Im Hintergrund wird eine SH-Shell<\/strong> gestartet und unser Befehl darin ausgef\u00fchrt. Ein einfaches Beispiel ist ein echo-Befehl:<\/p>\n
RUN echo Hallo Docker!<\/code><\/pre>\nWichtig zu verstehen ist: Ein Image ist eine Vorlage f\u00fcr einen Container. Es besteht aus mehreren Schichten eines Dateisystemes. Wie bei einer Schablone k\u00f6nnen wir mithilfe eines Images also beliebig viele identische Container erstellen. Mit diesem Verst\u00e4ndnis wird deutlich, dass obiger Befehl wenig Sinn ergibt: Beim ersten Bauen des Images w\u00fcrde der Echo-Befehl ausgef\u00fchrt. F\u00fcr das Image hat er keine Bedeutung, da er nichts ins Dateisystem schreibt. Ein sinnvolleres Beispiel w\u00e4re, wenn wir etwa eine PHP-Datei f\u00fcr den Webserver ablegen w\u00fcrden:<\/p>\n
RUN echo '<?php echo "Hallo vom Dockerfile";' > \/var\/www\/html\/hallo.php<\/code><\/pre>\nDamit sind wir an dieser Stelle f\u00fcr die erste Demo fertig und k\u00f6nnen die Datei speichern.<\/p>\n
Anlegen einer docker-compose.yml, die unser Image baut und einen Container startet<\/h3>\n
Aus dem Dockerfile <\/strong>l\u00e4sst sich ein Image bauen, welches f\u00fcr einen Container genutzt werden kann. Diese Schritte lassen sich h\u00e4ndisch und getrennt ausf\u00fchren. In der Praxis ist das m\u00fchsam. Wenn man Images f\u00fcr sich selbst entwickelt, die nicht \u00fcber z.B. den Docker-Hub mit anderen geteilt werden sollen, ist Docker-Compose auch hier der einfachste und sinnvollste Weg. Wir k\u00f6nnen dort n\u00e4mlich automatisch ein Image bauen und einen Container erstellen lassen.<\/p>\n
version: "2.4"\n\nservices:\n mein-webserver:\n build: .\n restart: always\n ports:\n - 80:80<\/code><\/pre>\nDie Besonderheit liegt darin, dass wir kein image<\/strong> angeben – sondern build<\/strong>. Das legt den sogenannten Buildkontext fest, also den Pfad, in dem ein Dockerfile gebaut wird. Der Punkt steht unter Linux f\u00fcr das aktuelle Verzeichnis. Dort sucht Compose nach einem Dockerfile. Sofern wir dies nicht anders benennen, m\u00fcssen wir keinen Dateiname angeben. Mit docker-compose up -d –build<\/strong> l\u00f6sen wir nun zwei Vorg\u00e4nge aus:<\/p>\n
- \n
- Anhand des Dockerfiles wird ein Image gebaut<\/li>\n
- Das Starten eines Containers mit dem zuvor erstellten Image<\/li>\n<\/ol>\n
$ docker-compose up -d --build\nSending build context to Docker daemon 335B\nStep 1\/3 : FROM php:8-apache-buster\n ---> e2070fb1b17d\nStep 2\/3 : RUN echo Hallo Docker!\n ---> Running in d51571677206\nHallo Docker!\n ---> 356e1b361b67\nStep 3\/3 : RUN echo '<?php echo "Hallo vom Dockerfile";' > \/var\/www\/hallo.php\n ---> Running in 05bb1b73251e\n ---> 3376002c07d3\nSuccessfully built 3376002c07d3\nSuccessfully tagged erstes-dockerfile_mein-webserver:latest\n[+] Running 1\/1\n \u283f Container erstes-dockerfile-mein-webserver-1 Started 1.2s<\/code><\/pre>\n$ docker-compose up -d --build\nSending build context to Docker daemon 335B\nStep 1\/3 : FROM php:8-apache-buster\n ---> e2070fb1b17d\nStep 2\/3 : RUN echo Hallo Docker!\n ---> Running in d51571677206\nHallo Docker!\n ---> 356e1b361b67\nStep 3\/3 : RUN echo '<?php echo "Hallo vom Dockerfile";' > \/var\/www\/hallo.php\n ---> Running in 05bb1b73251e\n ---> 3376002c07d3\nSuccessfully built 3376002c07d3\nSuccessfully tagged erstes-dockerfile_mein-webserver:latest\n[+] Running 1\/1\n \u283f Container erstes-dockerfile-mein-webserver-1 Started 1.2s<\/code><\/pre>\nHier sieht man, dass der erste echo-Befehl ausgef\u00fchrt wird – aber eben mangels Schreiboperation keine Auswirkung auf das Image hat. Der Zweite schreibt dagegen in eine PHP-Datei. Nach dem Start des Webservers k\u00f6nnen wir diese \u00fcber den Hostname oder die IP-Adresse des Pi aufrufen, wo das Skript ausgef\u00fchrt und der Text ausgegeben wird:<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/11\/grafik-3.png\")
<\/a><\/figure>\n<\/div>\nRealer Anwendungsfall: Installation von PHP-Modulen<\/h2>\n
Kommen wir zum anfangs erw\u00e4hnten realistischeren Anwendungsfall: Wir m\u00f6chten ein PHP-Modul installieren. Zun\u00e4chst f\u00fcgen wir im Dockerfile einen weiteren RUN-Befehl ein, um die PHP-Info auszugeben. Sie zeigt, welche Module installiert sind.<\/p>\n
RUN echo '<?php phpinfo();' > \/var\/www\/html\/info.php<\/code><\/pre>\nAnschlie\u00dfend das Image neu bauen und den Container ebenfalls neu erstellen. Damit ein neu erstelltes Image Anwendung findet, m\u00fcssen alle Container, die es verwenden neu erstellt werden. Docker-Compose k\u00fcmmert sich bei allen Containern der aktuellen docker-compose.yml Datei automatisch darum:<\/p>\n
docker-compose up -d --build<\/code><\/pre>\nDurch den Aufruf unseres erstellten Skriptes info.php<\/strong> k\u00f6nnen wir sehen, dass die MySQLi-Erweiterung nicht installiert ist. Auf der gesamten Seite gibt es nur einen Treffer in den Credits:<\/p>\n
![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/11\/grafik-4-1024x721.png\")
<\/a><\/figure>\nW\u00e4re die Erweiterung installiert, m\u00fcsste ein eigener Bereich mit ihrer Konfiguration weiter oben auftauchen. PHP bietet uns in den offiziellen Docker-Images zwei Werkzeuge f\u00fcr Erweiterungen: docker-php-ext-install <\/strong>zur Installation von Erweiterungen und docker-php-ext-configure<\/strong> f\u00fcr zus\u00e4tzliche Konfigurationsparameter. Letzteres ist nicht bei allen Erweiterungen n\u00f6tig.<\/p>\n
Um die MySQLi-Erweiterung zu installieren, ben\u00f6tigen wir einen RUN-Befehl, der docker-php-ext-install aufruft und als Parameter den Name der Erweiterung \u00fcbergibt:<\/p>\n
RUN docker-php-ext-install mysqli<\/code><\/pre>\nWie schon zuvor gezeigt, m\u00fcssen wir nun docker-compose up -d –build<\/strong> aufrufen, um das neue Image zu erstellen. Da die Erweiterung kompiliert werden muss, kann dies – vor allem auf dem Raspberry Pi – ein paar Minuten dauern. Wird anschlie\u00dfend die PHPInfo im Browser aktualisiert, sehen wir einen eigenen Bereich zu MySQLi:<\/p>\n
![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/11\/grafik-5-1024x721.png\")
<\/a><\/figure>\nDie Erweiterung wurde also erfolgreich installiert, sie kann nun im PHP-Code genutzt werden, um auf eine MySQL-Datenbank zuzugreifen. <\/p>\n
Auf \u00e4hnlichem Wege kann man auch ein eigenes Image erstellen, um etwa eine Anwendung zu dockerisieren. Dies schauen wir uns in einem eigenen Teil an.<\/p>\n","protected":false},"excerpt":{"rendered":"
In den bisherigen Beitr\u00e4gen haben wir ausschlie\u00dflich fertige Images aus dem Docker-Hub genutzt, beispielsweise f\u00fcr die Webserver Nginx und Apache. F\u00fcr einfachere Anwendungsf\u00e4lle reicht das. Wer sich tiefergehend mit Docker besch\u00e4ftigt, wird jedoch irgendwann an die Grenzen sto\u00dfen und m\u00f6chte ein Image anpassen oder gar ein komplett eigenes erstellen. Dies m\u00f6chten wir im heutigen Beitrag …<\/p>\n","protected":false},"author":5,"featured_media":7914,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[671],"tags":[497,771,983],"class_list":["post-7897","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-raspberry-pi","tag-docker","tag-docker-compose","tag-dockerfile"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/7897","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=7897"}],"version-history":[{"count":11,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/7897\/revisions"}],"predecessor-version":[{"id":9813,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/7897\/revisions\/9813"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/7914"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=7897"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=7897"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=7897"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}