Piwik auf Docker

erste Missverständnisse abbauen

Das erste Problem tauchte schon beim mounten der Verzeichnisse in den Container auf. Das die Notation im Plesk-Interface genau andersherum ist, als vom docker-Befehl bekannt, ist da noch das kleinere Problem. Ich hatte aber gehofft und scheinbar falsch verstanden, dass man mit dem Inhalt solcher zusätzlichen Volumes auch im Original-Paket vorhandene Files „überschreiben“ kann. Das geht prinzipiell auch. Nur muss man alle einzelne Files auch einzeln mounten. nimmt man das Verzeichnis in dem die Dateien liegen, dann wird auch der komplette Verzeichnisinhalt um-geschrieben und das zugewiesene Verzeichnis wird komplett umgebogen. Wenn in diesem Verzeichnis Files oder andere Verzeichnisse fehlen, werden die auch im Container nicht erreichbar sein. Mein Plan war ja, die zwei bis zwanzig Dateien, die ich schon mal anpasse, in das neu Verzeichnis und eine entsprechende Struktur zu legen und alle restlichen Dateien sollte weiterhin aus dem Original-Volume kommen und dadurch bei Updates auch aktuell gehalten werden. Nun muss ich also tatsächlich jede Datei einzeln mounten. – Da hatte ich wohl etwas missverstanden.
Einzig das config-Verzeichnis hatte ich komplett von außen hinein gemountet.

Das nächste Problem war dann, dass man den neuen Piwik-Container im Plesk nicht in die Webseite einbinden konnte. In dem Punkt „Proxyregel für Docker“ war der Piwik-Container nicht verfügbar. Erst als ich mir die Plesk-Hilfe noch mal genauer ansah, fand ich den Hinweis, dass man dafür in den Container-Einstellungen den Punkt „Manuelles Mapping“ einschalten muss und einen festen Port festlegen muss.

nur im Web-Root gültig

Trotzdem funktionierte die Proxy-Weiterleiung nicht. Ich hatte den URL-Pfad /piwik auf den Container „piwik“ umgeleitet und bekam immer einen 404er-Fehler. Irgendwann fand ich das Error-Log und stellte fest, dass in dem Docker-Container auch der komplette URL-Pfad /piwik/index.php ankommt. Die ist dort natürlich ungültig.
Auch verschiedene andere Einträge versuchte ich, fand aber scheinbar nicht die richtige Stelle, an denen die Weiterleitungen dann auch wirken. Folgende Einträge versuchte ich.:
erst für Apache:

ProxyPass        /piwik/ http://localhost:32773/
ProxyPassReverse /piwik/ http://localhost:32773/

oder auch für Nginx:

1
2
3
4
5
6

location ~ ^/piwik/.* {
	proxy_pass http://localhost:32773;
	proxy_set_header Host             $host;
	proxy_set_header X-Real-IP        $remote_addr;
	proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
}

Weil beides nicht den gewünschten Erfolg brachte, band ich den Container erst mal als / (Root) ein und dann klappte zumindest der Aufruf des Piwik-Webinterfaces.

MySQL bereitstellen

Und schon gab es die nächste Fehlermeldung: Die mysql-Datenbank war nicht erreichbar. Bekanntermaßen ist ja der auf dem Host-System laufende SQL-Serverdienst aus den Docker-Containern nicht direkt als „localhost“ erreichbar. Aber auch über den Hostname oder die zugehörige IP-Adresse erreicht man keinen SQL-Server, denn mysql lauscht erst mal nur an „localhost“ und auch wenn man die IP des Hostes konfiguriert, müssten immer noch die Berechtigungen auf die Container-IP-Adressen erweitert werden. – Das wollte ich nicht und einen extra Container für die Datenbank wollte ich schon gar nicht. Also suchte ich nach einer anderen Möglichkeit, die Datenbank in den Container zu mounten. – Tatsächlich reicht es aus, den Socket des Mysql-Servers in den Container zu mounten. Das allerdings war gar nicht so einfach. Zum einen gab es auf dem Server schon zwei Sockets, aber im Docker-Container funktionierte keiner der beiden Sockets. Erst ein Blick in die Ausgabe von phpinfo() brachte den Hinweis, dass der pdo_mysql.default_socket im piwik-Container auf „/tmp/mysql.sock“ zeigt. Als ich den MySQL-Socket dorthin mountete, kam ich auch an den SQL-Server und war wieder einen Schritt weiter.
Dann gab es aber noch ein weiteres Probleme mit der Datenbank. Ich erreichte sie plötzlich nicht mehr. Bis ich festgestellte, dass ich bei den ganzen Spielereien den ersten Piwik-Host mit der Datenbank zwischenzeitlich mal gelöscht hatte. Dabei wird logischerweise beides gelöscht, der Host und auch die zugehörige Datenbank auf der zentralen MySql-Instanz. So musste ich die Datenbank und den zugehörigen User erst wieder neu anlegen.

Piwik-Image selber bauen

Als nächstes wollte ich noch das Problem mit dem „fehlenden“ Pfad angehen. Ich hatte ja nun schon festgestellt, dass es scheinbar erst funktioniert, wenn ich den Pfad auch im Container gültig mache. Jedenfalls fand ich keine andere funktionierende Lösung.
Also beschloss ich das Docker-Image mit einer leichten Modifikation aus dem Original selber zu bauen. Dazu holte ich mir das originale Dockerfile vom git-Server und passte es an einer Stelle an.

37
38
39
40
41
42

...
COPY favicon.ico /var/www/html/
COPY robots.txt /var/www/html/
COPY piwik.inc.conf /etc/apache2/conf-available/
RUN a2enconf piwik.inc.conf
...

In der Datei piwik.inc.conf brachte ich den erforderlichen Alias unter und bei der Gelegenheit werden auch noch mein favicon.ico und robots.txt in das Image kopiert.
Beim selber-bauen gab es aber noch einen „witzigen“ Fallstrick. Wenn man dann nämlich das built anwirft, sollte man den Namen des Images individuell eindeutig festlegen! Ich nahm zuerst den Namen „piwik“ und wunderte mich, dass immer ganz kurz mit meinen Alias funktionierte und zwei Minuten später plötzlich nichts mehr lief. Bis ich dann darauf kam, dass ich ja auch einen Container mit dem Tool watchtower laufen habe, der meine Images aktuell hält. Hier tauschte der watchtower nach jedem built meinen neu gebauten Container „piwik“ jeweils unmittelbar gegen den mit dem angeblich neueren offiziellen Image „piwik“ aus. Erst als ich dem Image einen anderen Namen gab, blieb mein Container unangetastet.