#2 Allgemeine Probleme und Migration

Das Repository sollte direkt out-of-the-box eine lauffähige WordPress Instanz erstellen. In diesem Post möchte ich jedoch über allgemeine Fehlerbehandlung und Probleme berichten, die mir bei der Vorbereitung der Images unter gekommen sind.

Ich kann keine Bilder hochladen oder plugins runterladen.

Unabhängig von Docker und seinen Containern, liegt die Ursache bei einem Abbruch im Hochladeprozess  darin, dass die Ziel-Ordner nicht richtig freigegeben worden sind. Für den Download und Upload von Daten ist das PHP Modul zuständig. Der Nutzer unter dem PHP arbeitet ist www-data:www-data, sodass die Ordner auch dementsprechend für diesen Nutzer freigegeben werden sollten. Dies kann wie folgt geschehen:

$ sudo chown -R www-data:www-data wp-content/
$ sudo chmod -R 755 wp-content/

Interessant zu wissen ist auch, dass www-data nur ein Name ist und intern vom Betriebssystem noch einmal auf eine eindeutige UID und GID gemappt wird. Dieses Problem trat bei Benutzung des originalen PHP-fpm Modules auf. Innerhalb des Containers war die UID und GID von www-data auf 82 gemappt, während diese auf dem Host System von www-data auf 33 gemappt worden sind. Obwohl also anscheinend der gleiche Nutzername vorherschte, ware es in Wirklichkeit so, dass der interne Nutzer des Containers mit der ID 82 auf den Ordner im Host System schreiben wollte, welcher nur für den Nutzer mit der ID 33 freigegeben war. Dieses Problem habe ich umschifft, indem ich in dem Dockerfile die jeweiligen IDs des Nutzers innerhalb des Containers entsprechend zu der ID 33 geändert habe.

Caddy funktioniert nicht mehr, startet jedes mal neu.

Dies ist ein allgemeines Problem wenn man mit dem Caddy Container arbeitet. Wenn Caddy gestartet wird und eine Domain konfiguriert ist, sowie die automatische Zertifikats Abfrage über Let’s Encrypt aktiviert ist, so generiert Caddy immer ein neues Zertifikat, wenn es kein vorhandenes findet. Wenn dieses erstellte Zertifikat nicht auf dem Host System persisitiert wird, wird es beim herunterfahren des Containers gelöscht und eine neue Anfrage wird beim Neustart ausgeführt. Das Problem jedoch ist, dass Let’s Encrypt nur eine begrenzte Anzahl an Zertifikaten für eine Domaine zulässt (mit einer GÜltigkeit von 7 Tagen). Wird diese Anzahl überschritten, wird kein Zertifikat mehr ausgestellt (siehe auch diesen Post ). Deshalb würde ich auch empfehlen, die Zertifikate an das Host System zu binden. Zertifikate werden per Default intern im $HOME Verzeichnis (/home/.caddy) des Caddy Containers gepspeichert. Dieser Pfad kann auch wieder nach belieben durch injizieren einer Umgebungsvariable (CADDDYPATH) konfiguriert werden.

Migration

Ich hatte zuvor schon eine funktionsfähige WordPress Installation mit Hilfe dieser Quelle (medium) hochziehen können. Die beigefügten Services sind die Folgenden: Caddy (v0.9), PHP(v5.6) and MySQL(v5.5). Jedoch war die PHP Version mittlerweile veraltet und musste somit auf den neuesten Stand gebracht werden.

Wieso PHP 7

PHP 7 ermöglicht eine Performance Steigerung im Vergleich zu PHP 5 (siehe dazu diesen Artikel ). Dadurch, dass der Raspberry Pi nur ein kleiner Mini Computer ist, wollen wir natürlich jedes Performance Prozent rauskitzeln. PHP 7 ist jedoch wiederum nicht kompatibel mit der MySQL 5.5 Version, sodass auch die Datenbank upgedatet werden musste. Daraus resultierte ein neues Problem, da noch kein MySQL 7 image für die ARM Architektur des Pi’s vorhanden war, musste ich also mit MariaDB(v10.3.17) vorlieb nehmen.

Migration der Datenbank

Es gab keine großen Schwierigkeiten bei der Migration der Daten von MySQL 5.5 nach MariaDB 10.3.17. Die angehangenen Ordner unter /var/lib/mysql konnten wiederverwendet werden, sodass in der docker-compose.yml nur das Quell Image ausgetauscht werden musste (zur Sicherheit vorher jedoch doch noch ein backup ziehen). Nachdem die MariaDB das allererste mal gestartet wurde, muss die Datenbank upgedatet werden mit dem foolgendem Befehl:

$ docker exec webservice_mariadb_1 sh -c 'exec mysql_upgrade -uroot -p"[myrootpassword]"' 

Wegen des Updates wurden die gehashtenWordpress Passwörter ungültig, sodass diese wiederrum erneuert werden mussten. Um dies zu tun muss zuerst in den Datenbank Container navigiert werden :

$ docker exec -it webservice_mariadb_1 mysql -u root -p

Meine WordPress Datenbank hat den Namen blog, unter welchem die Nutzer-Daten in der Tabelle wp_users gespeichert sind. Dadurch, dass ich nur einen Nutzer hatte war es für mich leicht das Passwort zurückzusetzen. Das Zurücksetzen auf das Passwort “passw0rd” könnte wie folgt aussehen:

$ UPDATE blog.wp_users SET user_pass=MD5('passw0rd')

Bei der initialen Änderung und Vergabe des Passwortes erlaubt WordPress ein MD5 hash, scheint diesen jedoch später in einen sicherern hash abzuändern.  (Quelle, 17.11.2019).

<<< zurück: #1 Installation von WordPress auf einem Raspberry Pi mit Hilfe von Docker-Compose in unter 10 Minuten