Docker Maria DB ausführen

Im Docker Hub gibt es für die Datenbank-Server MySQL und MariaDB diverse Images. Für die weiteren Abschnitte wird das offizielle MariaDB-Image eingesetzt.

Beim einrichten des Containers wird das Root Passwort für den Datenbank Server als Parameter übergeben.

Die Umgebungsvariable MYSQL_ROOT_PASSWORD kann später auch mit:

docker inspect mariadb-test1 

ausgelesen werden.

docker run -d --name mariadb-test1 -e MYSQL_ROOT_PASSWORD=-geheim mariadb

Das Kommando „docker run“ endet, sobald der neue Container erfolgreich eingerichtet ist und gestartet wurde.

Der Datenbank Server läuft nun im Hintergrund weiter, bis der Container explizit wieder gestoppt wird

docker stop mariadb-test1

Besonderheiten:

Der MariaDB-Server wird als Hintergrunddienst ausgeführt, nicht interaktiv im Vordergrund.

MariaDB speichert alle Datenbankdateien in /var/lib/mysql relativ zum Verzeichnisbaum des Docker-Containers.

Im Dockerfile von MariaDB, also in der Beschreibung des Images, ist /var/lib/mysql aber als Volume gekennzeichnet.

Volume ist ein Speicherpfad wo die jeweiligen Containerdaten gespeichert sind. Standardmäßig im Docker Verzeichnis /var/lib/docker/volumes

Das genaue Verzeichnis kann man mit „docker inspect mariadb-test1“ ermitteln, wenn man in der mehrseitigen Ausgabe nach „mounts“ sucht.

Der direkte Zugriff auf von Docker eingerichtete Verzeichnisse ist ohnedies tabu. Es sollten dazu immer Kommandos wie z.B. „docker volume“ verwendet werden.

MariaDB Client aufrufen

Im MariaDB-Container wird nur der MySWQL-Server ausgeführt. Anders als in anderen Containern ist eine interaktive Nutzung nicht vorgesehen. Man kann aber mit „docker exec“ in einem zweiten Terminal parallel zum Container einen zweiten Prozess starten, um dort den MariaDB-Client mysql auszuführen:

docker exec -it mariadb-test1 mysql -u root -p
>Enter password: ********* (root Passwort für MariaDB)
>Welchem to the MariaDB monitor.
>Server version: 10.2.8-MariaDB
>MariaDB> show status;
...
>exit

Ein Blick in den Container

Wenn man neugierig ist und weitere Details über den Container ermitteln möchte, starten man parallel zum MariaDEb-Server mit „docker exec“ einen bash-Prozess für den Container:

docker exec -it mariadb-test1 /bin/bash

cat /etc/os-release
>PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
...

Logging

Da der MariaDB-Container im Hintergrund läuft, sieht man im Terminal keine Fehlermeldungen noch Logging Ausgaben. Diese kann man mit „docker logs“ auslesen

docker logs mariadb-test1
....

Container und Volumes löschen

Mit „docker rm mariadb-test1“ kann man den Container löschen. Das externe Volume, das wegen des InnoDB-Masterspace mindestens 100 MiB groß ist, bleibt dabei allerdings erhalten.

Das ist beabsichtigt (!), weil sich dort ja die Datenbankdateien befinden.

Deren irrtümliches Löschen soll vermieden werden.

Will man diese Dateien sicher löschen führt man „volume prune“ aus.

Vorsicht: „volume prune“ löscht alle Volumes, die keinem Container zugeordnet sind.

docker stop mariadb-test1
docker rm mariadb-test1
docker volume prune

somit ist nun alles von dem Container: „MariaDB-Test1“ unwiederbringlich gelöscht.

Vorteil von externen Volumes

Wenn man vorhat die Container „richtig“ zu nutzen und auch regelmäßige Updates auszuführen (auf eine neuere Version), dann sollte man das Volume mit den heiklen Daten (Datenbankdateien) ein Verzeichnis eigener Wahl vorsehen.

Dieses Verzeichnis kann man dann mit dem Parameter -v angeben und weiterverwenden.

Das hat den Vorteil, dass dieses Verzeichnis z.B. nach einem Update des Containers weiterverwendet werden kann.

-- Verzeichnis erstellen
mkdir /home/<username>/varlibmysql

-- Container erstellen mit dem externen Volume Verzeichnis
docker run -d --name mariadb-test2 \
-e MYSQL_ROOT_PASSWORT=geheim \
-v /home/<username>/varlibmysql/: \
/var/lib/mysql mariadb

-- das Zeichen "\" kennzeichnet einen Zeilenumbruch um die Lesbarkeit zu verbessern, in Linux wird dieses Zeichen sogar akzeptiert. In der PowerShell (Windows) muss dieses mit einem "`" ersetzt werden. 

Unter Linux und macOS muss der Pfad zum lokalen Volume-Verzeichnis mit „/“ beginnen. Ein relativer Pfad in der Form ./name wird nicht akzeptiert. Wenn man nur „name“ angibt, betrachtet docker run die Zeichenkette als Volume-Namen. Es erzeugt dann selbst ein Volume, Bennet dieses aber mit „name“.

Sollten ein Fehler auftreten, wegen Selinux hilft dieser Parameter:

:z (speziell für selinux)
z.B. -v /var/db:/var/db:z

Der Container kann nun genutzt werden. Detaillierte Informationen über den Zustand und der Einstellungen des Docker-Containers inklusive der benutzen Blume-Verzeichnisse können bei Bedarf mit „docker inspect <containername>“ ermittelt werden.

Später stellt man fest, dass es eine neue Version des zugrunde liegenden Images gibt. Man löscht nun den Container, wobei die Datenbanken im lokalen Volume-Verzeichnis erhalten bleiben. Anschließend richtet man einen neuen Container ein, der die vorhandenen Datenbanken weiternutzt.

Zu Beachten ist dabei dass das MariaDB-Root-Passwort nicht wieder angegeben werden muss!

docker stop mariadb-test2
docker rm mariadb-test2
docker run -d --name mariadb-test 3 \
-v /home/<username>/varlibmysql/: \
/var/lib/mysql mariadb

Port Weiterleitung

Es gibt verschiedene Möglichkeiten, auf den MariaDB-Server zuzugreifen. Den Aufruf des MariaDB-Clients mit „docker exec“ oder eine zweite Variante besteht darin, den Port „3306“ des Containers mit der Option „-p“ im Host-System zugänglich zu machen.

In der Testumgebung wird der Port 13306 verwendet um Konflikte mit anderen Datenbanken zu verhindern!

Es wird auch davon ausgegangen dass sich das Volume im lokalen Verzeichnis: „/home/<username>/varlibmysql und die MariaDB Datenbanken bereits initialisiert sind.

docker run -d --name mariadb-test4 -p 13306:1306 \
-v /home/<username>/varlibmysql/ \
:/var/lib/mysql mariadb

mit folgendem Kommando kann man es sofort testen:
mysql -u root -p --port 13306 --protocol=tcp
>>Enter Password: ********

Die Kommunikationsvarianten 1 (MySql-Client als Docker-Prozess) und 2 (über einen Netzwerkport) sind gewissermaßen Brücken zur klassischen Welt.

Beide Varianten sind im Docker-Universum aber untypisch. Es gibt eine wesentlich elegantere Variante zwischen Docker-Containern zu kommunizieren.

Das ist dann praktisch wenn in einem Container der Datenbank-Server läuft, im zweiten ein Datenbank-Client (z.B. ein CMS).

Die Kommunikation zwischen den beiden Containern erfolgt über ein von Docker verwaltetes internes Netzwerk, das mit „docker network“ eingerichtet wird

docker network create test-net

Ich richte nun einen neuen Container für MariaDb ein, der dieses Netzwerk dank der Option –network nutzt.

docker run -d --name mariadb-test5 --network test-net \
-v /home/<username>/varlibmysql/:/var/lib/mysql mariadb

Als Test für die Docker interne Kommunikation eigentlich sich das Image phpmyadmin ausgezeichnet. PhpMyAdmin und der MariaDB-Server laufen in zwei voneinander getrennten Container.

docker run -d --name pea -p 8080:80 \
--network test-net \
-e PMA_HOST=mariadb-test5 \
phpmyadmin/phpmyadmin

Entscheidend ist einerseits die Option „–network test-net“, die den Container in das gleiche Netzwerk wie den MariaDB-Server platziert, und andererseits die Angabe der Variablen „PMA_HOST“, damit die phpMyAdmin-Maschine weiß, unter welchem Namen der MariaEB-Server im Netzwerk läuft.

Docker Netzwerke kümmern sich automatisch um die netzwerkinterne Namensauflösung, wobei die mit –name angegebenen Namen gelten.

Die Option „-p“ leitet den Port 80 des Containers Oma auf den lokalen Port 8080 um. Um phpMyAdmin auszuprobieren, öffnet man den Docker-Host im Webbrowser „http://<ipadresseDesDockerHosts>:8080 und einloggen mit Root –> Passwort ist das von mariadb gewählte Passwort.

WordPress installieren

Zur Inbetriebnahme von WordPress sind lediglich zwei Kommandos notwendig:

mkdir /home/<username>/wp-html 
docker run -d --name wp-test1 --network test-net \
-v /home/<username>/wp-html:/var/www/html -p 8081:80 \
-e WORDPRESS_DB_PASSWORD=geheim \ 
-e WORDPRESS_DB_HOST=mariadb-test5 wordpress

Unter der Adresse http://<ipadresseDesDockerHosts>:8081 kann man die WordPress Seite nun in Betrieb nehmen.

Die Anfangskonfiguration beschränkt sich auf zwei Dialoge: Auf der ersten Seite wählt man die gewünschte Spreche aus, auf der zweiten Seite richtet man den WordPress-Administrator ein.

Die oft heikle Konfiguration der Zugangsdaten des Datenbank Servers entfällt, das wurde schon im Script des WordPress Containers erledigt (-e WORDPRESS….)

„–network test-net“ sorgt dafür, dass der WordPress Container im gleichen Netzwerk wie der MarieDB Server läuft.

Die Option „-v“ ist optional. Man erreicht damit, dass alle HTML-, PHP-, CSS- und sonstige Dateien der WordPress-Installation außerhalb des Containers an dem von mir gewählten Ort gespeichert werden. Wenn später der WordPress-Container aktualisiert wird, kann dieses Verzeichnis weiterverwendet werden.

Mit „-p“ gibt man an unter welchem Port die WordPress-Installation auf dem Docker-Host angesprochen wird.

Die Option „-e WORDPRESS_DB_PASSWORD=geheim“ ist normalerweise überflüssig, weil Docker das root-Passwort des MariaDB-Servers mit docker inspect aus dem Datenbank Container ausliest. Das funktioniert aber nur, wenn beim Einrichten des MariaDB-Containers die Option „-e MYSQL_ROOT_PASSWORD=geheim“ verwendet wurde. Beim ersten mal ist das immer der Fall, nicht aber, wenn später ein MariaDB-Update durchgeführt wird und das /var/lib/mysql-Bolume weiterverwendet wird.

Die Option „-e WORDPRESS_DB_HOST=mariadb-test5“ gibt an, unter welchem Hostanemn der MariaDB-Server im Docker-internen Netzwerk „test-net“ bekannt ist. Hier muss derselbe Name genannt werden, der beim Einrichten des MariaDB-Servers mit der Option –name angehen wurde. Weiter Umgebungsvariablen des offiziellen WordPress-Images findet man unter:

https://hub.docker.com/_/wordpress

Aufruf funktioniert nur über den Docker Host richtig. Ruft man von einem entfernten Rechner die Seite auf, erscheint diese falsch, weil die CSS Formatierungen etc Schuld daran sind. Man muss die allgemeinen Einstellungen der WordPress Installation anpassen. Dort ist als WordPress-URL der Hostname „localhost“ eingetragen. Stattdessen muss man dort den richtigen Hostnamen des Rechners angeben.

WordPress Update

Nichts leichter wie einen Container zu updaten wenn die Volumes außerhalb liegen, denn dort sind alle relevanten und Wichten Config Einstellungen gespeichert.

Angenommen man möchte das neueste WordPress Major Release installieren:

docker pull wordpress
docker stop wp-test1
docker rm wp-test1
docker run -d --name wp-test2 --network test-net \
-v /home/<username>/wp-html:/var/www/html \
-p 8081:80 wordpress

Die beiden -e Optionen zur Einstellung der Umgebungsvariablen sind nicht mehr erforderlich, weil diese Parameter bereits nd der Daten in /var/www/html/sp-config.php gespeichert wurden und weiterverwendet wurden.