Idee

Der vServer mit nginx läuft und die Domain ist auch durchgeschaltet, also sollte es doch einfach sein WordPress zu installieren.

Die erste Idee ist natürlich das über meinen Webhoster (Strato) zu machen, allerdings brauche ich dafür eine neue Datenbank, welche auch kostenpflichtig ist. Bei der Domain kann ich den A-Record ändern, also kann das WordPress auch auf dem vServer laufen. Das sollte über Docker einfach sein.

WP Image

Also mal eben WordPress Docker Image suchen, aus dem offiziellen Repro, natürlich mit Alpine Linux, es soll wenig Speicherplatz benutzt werden. Da wird man auch fündig:

wordpress:php7.1-fpm-alpine

soll es sein, das hat mit 40 MByte eine super Größe.

Dazu braucht man eine MySql Datenbank oder MariaDB. MySql ist offiziell unterstützt, MariaDB soll genauso gehen allerdings möchte ich keine Experimente, also entscheide ich mich für MySql.

MySql Image

Ein Blick in das offizielle Repro zeigt leider keine Version mit Alpine Linux, was sehr schade ist. Bei einer kurzen Recherche sehe ich noch ein 2tes Repro, welches so halb ofizell aussieht:

mysql/mysql-server

allerdings gibt es hier auch kein Image, das auf Alpine Linux basiert. Dabei sollte es doch möglich sein ein kleines Image, wie z.B.wangxian/alpine-mysql zu bauen, welches jetzt gerade 51 MByte hat. Allerdings ist mir das Dockerfile zu trivial, es werden wohl die Voreinstellung über Environment Variablen, wie im ofiziellen Image, nicht unterstützt. Zum selber bauen habe ich keine Zeit und wie schon geschrieben möchte ich für das WordPress auch keine Experimente. Das soll einfach nur funktionieren.

Dann wird also mit knirschenden Zähnen das offizielle MySql Image mit 144 MByte benutzt. Eine ältere Version sollte es dann auch nicht sein.

Zusammenbau

In die docker-compose.yml kommt dann:

 

 wordpress:
   image: wordpress:php7.1-fpm-alpine
   container_name: wordpress
   depends_on:
     - wordpressdb
   volumes:
     - /home/docker/data/wordpress:/var/www/html
   environment:
     - WORDPRESS_DB_HOST=wordpressdb
     - WORDPRESS_DB_USER=wordpress
     - WORDPRESS_DB_PASSWORD=-----
     - WORDPRESS_DB_NAME=wordpress
   networks:
     - pb_net

 wordpressdb:
   image: mysql
   environment:
     - MYSQL_ROOT_PASSWORD=------
     - MYSQL_DATABASE=wordpress
     - MYSQL_USER=wordpress
     - MYSQL_PASSWORD=------
   volumes:
     - /home/docker/data/wordpressdb:/var/lib/mysql
   networks:
     - pb_net

 

Auch hier habe ich erstmal unverschlüsselte Volumes benutzt. Wie im Teil 3 beschrieben läuft auf /var/lib/docker/volumes ein ecryptfs.

Jetzt muss ja nur noch der Nginx WordPress ausliefern, also erster Versuch, in der Art wie ich auch Rails anbinde:

 

server {
 server_name pflegebot.com;
 listen 443 ssl;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_set_header Host $http_host;
 proxy_set_header REMOTE_ADDR $remote_addr;
 proxy_redirect off;
 
 location / {
   proxy_pass http://wordperss:9000;
 }
 
 ssl_certificate /etc/letsencrypt/live/pflegebot.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/pflegebot.com/privkey.pem;
}

 

und……….

Nichts geht 🙁

Also mal wieder Dokumentation lesen und feststellen, dass das fpm wordpress image ’nur‘ einen fastcgi Server aufbaut. Dafür soll es ja auch echt schnell wein :-). Mit fastcgi in Webservern habe ich seit meiner Zeit mit Perl nicht mehr gearbeitet, aber im Netz ist die Lösung schnell gefunden:

server {
 server_name pflegebot.com;
 listen 443 ssl;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_set_header Host $http_host;
 proxy_set_header REMOTE_ADDR $remote_addr;
 proxy_redirect off;
 root /var/www/html;
 
 location / {
   index index.html index.htm index.php;
 }
 
 location ~ .php$ {
   include fastcgi_params;
   fastcgi_pass wordpress:9000;
   fastcgi_index index.php;
   fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;
 }
 ssl_certificate /etc/letsencrypt/live/pflegebot.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/pflegebot.com/privkey.pem;
}

 

Webserver durchstarten und siehe da, das php wird ausgeliefert, aber die Assets nicht. Kein css zu sehen.

Ist ja auch klar, die werden statisch geliefert und nicht über php.

Also entweder man nimmt dann ein großes WP-Image, welches mit Apache daher kommt, die gibt es nicht mit Alpine Linux, man baut sich so etwas selber (aber ‚keine Experimente‘) oder man macht die etwas schmutzige Lösung, die ich im Netz gefunden habe.

Da ich keine weitere Zeit reinstecken möchte, nehme ich also die nicht so schöne Lösung und lass‘ den nginx vor dem WordPress die statischen Dateien ausliefern. Dazu muss die Volume aus dem WordPress Container auch in den nginx Contaimer geladen werde. Damit haben die beiden eine enge Kopplung, das möchte man eigentlich vermeiden und genau das halte ich für die nicht so schöne Lösung.

In einem anderen Projekt habe ich mal einen nginx in einen Rails Container gebaut, um statische Assets schnell zu liefern. Da benötigt der Container aber 2 Prozesse, welche über supervisord gesteuert werden. Der supervisor benötigt auch Python und das Ganze kann kein kleines Image ergeben.

Also gibt es in der docker-compose.yml bei dem nginx service:

 volumes:
 - /home/docker/data/wordpress:/var/www/html:ro

Zusammen mit:

root /var/www/html;

in der nginx config (s.o.) werden dann auch die Assets ausgeliefert.

Fazit

Es wäre wesentlich einfacher gewesen den Euro für die zusätzliche Datenbank beim Hoster zu investieren und sich die Arbeit zu sparen. Für die technische Umsetzung hätten es dann auch Subdomains getan.