WordPress mit Docker und nginx installieren

Man kann relativ einfach mit Docker ein WordPress Blog auf einem Server deployen. Fangen wir mit den Docker-Einstellungen an, die alle in der Datei docker-compose.yml gesammelt sind:

version: '3.1'
services:
  wordpress:
    image: wordpress
    restart: always
    ports:
      - 8082:80
    environment:
      WORDPRESS_DB_HOST: ...
      WORDPRESS_DB_USER: ...
      WORDPRESS_DB_PASSWORD: ...
      WORDPRESS_DB_NAME: ...
    volumes:
      - ./wordpress:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
  db:
    image: biarms/mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: ...
      MYSQL_USER: ...
      MYSQL_PASSWORD: ...
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - ./db:/var/lib/mysql

Die docker-compose.yml packt man am besten in einen eigenen Ordner /docker/wordpress. Mit dem Befehl docker-compose up -d startet man zwei Container, einen für WordPress, einen für die Datenbank. Man sieht nun auch, dass im WordPress-Ordner zwei Unterordner erschienen sind, in denen die Daten der Datenbank und von WordPress leben. Diese beiden Ordner enthalten alle für das Blog relevanten Daten und sollten auch entsprechend gebackupt werden.

Jetzt werden noch ein paar kleine Einstellungen in der UI von WordPress vorgenommen und … fertig. Naja, fast!

Versucht man mit diesen Einstellungen ein Bild größer als 2MB auf den Blog zu laden wird man eine Fehlermeldung ernten – die maximale Upload-Größe ist nämlich überschritten. Aus diesem Grund existiert die Direktive bzgl. der Datei uploads.ini in der docker-compose.yml. Die Idee hierbei ist, dass „von außen“ einige Einstellungen in der php.ini des Docker Containers überschrieben werden. Das geschieht durch die Datei uploads.ini, die vom Host-System in den Container an die richtige Stelle gelegt wird und dann eben für das gewünschte Verhalten von PHP sorgt. Diese Datei sieht wie folgt aus:

file_uploads = On
memory_limit = 256M
upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 600
max_input_time = 600

Zuletzt braucht man die Konfiguration des nginx Proxy, da der Blog aktuell ja nur von einem „komischen“ Port angesprochen werden kann und zudem auch die Kommunikation nicht sicher™ erfolgt. In meinem Beispiel sieht die nginx Konfiguration so aus:

server {
   server_name holger.tk;
   listen 443 ssl http2 default_server;
   ssl_certificate /etc/letsencrypt/live/holger.tk/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/holger.tk/privkey.pem;
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
   include /etc/letsencrypt/options-ssl-nginx.conf;
   client_max_body_size 128M;

   location / {
      proxy_pass  http://localhost:8082;
      proxy_redirect     off;
      proxy_set_header   Host $host;
      proxy_set_header   X-Real-IP $remote_addr;
      proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header   X-Forwarded-Host $server_name;
      proxy_set_header   X-Forwarded-Proto https;
      proxy_set_header   Upgrade $http_upgrade;
      proxy_set_header   Connection "upgrade";
      proxy_read_timeout 86400;
   }
}

server {
    if ($host = holger.tk) {
        return 301 https://$host$request_uri;
    }
    server_name holger.tk;
    listen 80;
}

Wie immer wird diese Datei im Ordner /etc/nginx/sites-available gespeichert und nach /etc/nginx/sites-enabled gesymlinked. Mit service nginx restart wird die neue Konfiguration geladen und der Blog ist nun hoffentlich über https ansprechbar.

Der Teil, der mir am meisten Kopfzerbrechen bereitet hat, ist die client_max_body_size. Ohne diese Einstellung gibt es einen Konflikt mit den Einstellungen in der uploads.ini. Der Versuch ein Foto über 2 MB Größe über https auf den Blog zu laden resultiert in einer wirren und nur mäßig hilfreichen Fehlermeldung à la „Das ist keine gültige JSON Antwort“. Mit der Einstellung klappt aber alles und Bilder bis 128 MB können hochgeladen werden.

Das sollte ausreichen.