Im letzten Artikel beschrieb ich die Installation von WordPress mit Docker im Swarm Mode auf einem Host. Nach kleineren Hürden war die grundsätzliche Installation erledigt und WordPress konnte in Betrieb genommen werden. Im Praxisbetrieb zeigte sich jedoch schnell, dass die Standard-Konfiguration noch ein wenig optimiert werden musste.
Im Folgenden skizziere ich anhand eines konkreten Beispiels, wie sich eine individuelle Konfiguration des Nginx-Proxy- sowie des PHP-FPM-Containers realisieren lässt. Anhand dieses Schemas sollte es möglich sein, auch weitere Einstellungen vorzunehmen.
Konfiguration des Nginx-Proxy
Ein erstes Problem zeigte sich beim Hochladen einer mehreren MByte-großen Theme-Datei. Das führte zur bekannten Nginx-Fehlermeldung “413 Request Entity Too Large“. Ein Blick in die Logs des Nginx-Proxy-Containers zeigte, dass die Ursache in dessen Konfiguration zu finden war:
geschke@rostock:~/services/nginx-proxy$ docker service logs uot72qrakvbb nginx-proxy-rostock_nginx-proxy.1.cmjci4xxp37r@rostock.mushaake.org | nginx.1 | 2018/04/28 17:32:08 [error] 57#57: *1 client intended to send too large body: 4954931 bytes, client: 89.0.101.236, server: www.example.com request: "POST /wp-admin/update.php?action=upload-theme HTTP/2.0", host: "www.example.com", referrer: "https://www.example.com/wp-admin/theme-install.php?browse=featured" nginx-proxy-rostock_nginx-proxy.1.cmjci4xxp37r@rostock.mushaake.org | nginx.1 | www.example.com 89.0.101.236 -
Insofern musste die Nginx-Proxy-Konfiguration verändert werden. Der Autor des Nginx-Proxy-Images bietet dazu bereits einige Hinweise an. Zwar wäre die Konfiguration auch für einzelne virtuelle Hosts möglich, aber meines Erachtens widerspricht dies dem Sinn des Nginx-Proxy, d.h. des einfachen Hinzufügens und Entfernens von virtuellen Hosts, ohne dass diese jeweils eine eigene Konfiguration benötigen. Insofern habe ich mich für die Möglichkeit der Proxy-weiten, globalen Konfiguration entschieden. Dabei wird einfach eine weitere Nginx-Config-Datei hinzugefügt, in der die entsprechenden Änderungen aufgeführt werden. Nginx-Proxy lies diese Datei bzw. Dateien beim Start ein, sofern sie in das Verzeichnis “/etc/nginx/conf.d/” gemountet werden.
Die docker-compose-Datei für den Nginx-Proxy bedurfte folgender Änderung:
version: '3.3'
services:
nginx-proxy:
[...]
volumes:
[...]
- ./proxy/conf.d/my_proxy.conf:/etc/nginx/conf.d/my_proxy.conf:ro
Damit wird die Datei my_proxy.conf im Nginx-Proxy in das dafür vorgesehene Verzeichnis gemountet. Die Datei kann alle Optionen beinhalten, die auch mittels der nginx.conf geändert werden können. Aktuell befindet sich nur eine Zeile darin, und zwar:
client_max_body_size 100m;
Danach wird einfach der komplette Nginx-Proxy-Stack neu gestartet:
geschke@rostock:~/services/nginx-proxy$ docker stack rm nginx-proxy-rostock Removing service nginx-proxy-rostock_nginx-proxy Removing service nginx-proxy-rostock_nginx-proxy-comp geschke@rostock:~/services/nginx-proxy$ docker stack deploy -c nginx-proxy_prod.yml nginx-proxy-rostock Creating service nginx-proxy-rostock_nginx-proxy-comp Creating service nginx-proxy-rostock_nginx-proxy
Damit war der erste Schritt erledigt, die Theme-Datei konnte hochgeladen werden… Fast!
Konfiguration des Nginx-Webserver-Services
Denn hinter dem Nginx-Proxy steht ein weiterer Nginx-Webserver, der zusammen mit PHP-FPM und MariaDB die einzelnen Services der Anwendung darstellt. Somit muss ebenfalls auf dem “inneren” Nginx die Änderung durchgeführt werden. Da es jedoch bereits eine Konfigurationsdatei für den inneren Nginx gibt, ist der Aufwand der Änderung hier relativ gering. Im Abschnitt “server” kann die betreffende Zeile einfach hinzugefügt werden:
server {
[...]
root /var/www/html;
client_max_body_size 100M;
Nach dem obligatorischen Neustart des Services bzw. des kompletten Docker Stacks war auch diese Hürde bewältigt. Doch der Upload funktionierte noch immer nicht…
Konfiguration des PHP-FPM-Services
Denn nun hatte sich das Problem auf die PHP-Seite verlagert mit der Fehlermeldung “The uploaded file exceeds the upload_max_filesize directive in php.ini“. Ebenfalls logisch, denn die zentrale PHP-Konfigurationsdatei beinhaltete noch die Standard-Größen, für den Fall der Option “upload_max_filesize” beträgt diese gerade einmal 2 MB.
Die Lösung sollte in ähnlicher Art und Weise erfolgen wie beim Nginx-Proxy, d.h. ich wollte vermeiden, die komplette php.ini-Datei zu kopieren bzw. in den Container zu mounten. Nun finden sich bei Ubuntu im Verzeichnis “/etc/php/7.2/fpm/conf.d/” zwar Konfigurationsdateien, jedoch handelt es sich dabei nur um Links auf *.ini-Dateien, die jeweils PHP-Extensions einbinden. Jedoch spricht auch nichts dagegen, mittels einer weiteren .ini-Datei Änderungen an der PHP-Konfiguration vorzunehmen. Insofern genügt es, eine Datei mit den Änderungen zu erstellen und diese – in dem Fall in der Reihenfolge als letzte – einzubinden.
Die Änderung in der entsprechenden docker-compose-Datei gestaltet sich damit wie folgt:
version: '3.3'
services:
[...]
phpbackend:
image: geschke/php-fpm-swrm
volumes:
[...]
- ./php/conf.d/99-custom.ini:/etc/php/7.2/fpm/conf.d/99-custom.ini:ro
Die ini-Datei, hier “99-custom.ini” genannt beinhaltet für die gewünschte Änderung nur die folgende Zeile, womit das Upload-Limit auf 20 MB herauf gesetzt wird:
upload_max_filesize = 20M
Nach einem erneuten Start des PHP-Containers funktionierte auch der Upload der größeren Theme-Datei problemlos.
Fazit
Insgesamt ist das Mounten von Dateien, in denen die jeweiligen Unterschiede zur Standard-Konfiguration verzeichnet sind, eine praktische und leichtgewichtige Lösung, um die Konfiguration einzelner Services anzupassen, ohne zu tief in die Konfiguration der Images einzugreifen bzw. sogar neue Docker-Images bauen zu müssen.
