Ein word­press-Test­ser­ver

Mit Docker lässt sich sehr leicht ein Ent­wick­lungs­ser­ver für word­press auf­bau­en. Auf ihm kann man belie­big instal­lie­ren, löschen und tes­ten, ohne dass ein Pro­duk­tiv­sys­tem beein­träch­tigt wird. Docker sorgt dafür, dass er auch schnell mal wie­der frisch auf­ge­setzt wer­den kann, soll­te ein­mal etwas schief gehen.

Docker ist ja bereits ein­ge­rich­tet. Ein nginx Web­ser­ver und eine MariaDB lau­fen schon für Next­Cloud. Bei­des kann auch für die word­press-Umge­bung mit­ge­nutzt wer­den. Was fehlt, ist zunächst eine Daten­bank für die wordpress-Installation.

MariaDB für word­press vorbereiten

In der Daten­bank-Ser­ver muss ledig­lich eine Daten­bank und ein zusätz­li­cher Nut­zer für word­press ange­legt wer­den. Das erle­digt man am bes­ten in der Docker-Shell:

host# docker exec -it mariadb bash
docker# mysql -u root -p <mysql-root-passwort>
mysql# create database wordpress;
mysql# create user wordpress@localhost identified by '<mysql-nutzer-passwort>';
mysql# create user wordpress@'%' identified by '<mysql-nutzer-passwort>';
mysql# grant all privileges on wordpress.* to wordpress@localhost;
mysql# grant all privileges on wordpress.* to wordpress@'%';

word­press unter Docker

Das offi­zi­el­le word­press-Docker-Image ist mit der omv-Docker-GUI schnell her­un­ter­ge­la­den: unter „Docker Images” den Knopf „Image bereit­stel­len” drü­cken und „word­press” als Quel­le ein­ge­ben. Das lädt das aktu­el­le offi­zi­el­le word­press-Image; unser watch­tower sorgt spä­ter dafür, dass auch updates auf das jeweils letz­te Image aus­ge­führt werden.

Jetzt muss der word­press-Con­tai­ner noch so kon­fi­gu­riert wer­den, dass er die Daten­bank nut­zen kann und über den Web­ser­ver von außen erreich­bar ist. Das geschieht wie­der, indem wir word­press in der Image-Lis­te der omv-Docker-GUI aus­wäh­len und auf „Image star­ten” klicken.

Im Start­dia­log machen wir fol­gen­de Angaben:

• Con­tai­ner Name: word­press
• Restart Poli­cy: always
• Netz­werk­mo­dus: Bridge
• Host­na­me: wordpress.mydmain.tld
• Port­wei­ter­lei­tung:
  • Host IP: 0.0.0.0
  • Host Port: 8800
  • Expo­sed Port: 80
  • Pro­to­col: tcp
• Zusätz­liche Umgebungsvariable:
  • WORDPRESS_DB_HOST: <db-ser­ver-adres­se>
  • WORDPRESS_DB_USER: word­press
  • WORDPRESS_DB_PASSWORD: <mys­ql-nut­zer-pass­wort>
  • WORDPRESS_CONFIG_EXTRA:
    define(‘WP_HOME’,‘https://wordpress.mydmain.tld ’);
    define(‘WP_SITEURL’,‘https:// wordpress.mydmain.tld ’);
    
• Volu­mes and Bind mounts:
  • Host path: /container/wordpress
  • Con­tai­ner path: /var/www/html

Im Con­tai­ner bedient word­press den Port 80. Da die­ser extern nicht ver­füg­bar ist, sorgt die Bridge dafür, dass er auf den exter­nen Port 8800 umge­setzt wird.

Unter WORDPRESS_CONFIG_EXTRA wird WP_HOME und WP_SITEURL so defi­niert, wie sie von „außen” auf­ge­ru­fen wer­den, sonst trägt word­press die Anga­ben beim ers­ten Start mit der fal­schen Port­num­mer in die Daten­bank ein.

Um auch an die word­press-Daten unter /var/www/html des Docker-Con­tai­ners zu kom­men, wer­den sie über ein Volu­me-mount auf das Ver­zeich­nis /container/wordpress des Hosts umgeleitet.

WORDPRESS_DB_HOST zeigt auf den MyS­QL-DB-Ser­ver, unter dem der MariaDB-Con­tai­ner erreich­bar ist; im mei­nem Fall wäre das der Docker-Host selbst. Das WORDPRESS_DB_PASSWORD muss ent­spre­chend des im MariaDB-Con­tai­ner genutz­ten gesetzt werden.

Der Con­tai­ner wird auto­ma­tisch sofort nach dem Spei­chern der Kon­fi­gu­ra­ti­on gestartet.

Rever­se Pro­xy für nginx

Der Host­na­me wordpress.mydomain.tld (der natür­lich an die eige­ne Domain ange­pas­set wer­den muss) wird im DNS so ein­ge­rich­tet, dass er auf die Adres­se des Web­ser­vers auf­löst. nginx küm­mert sich dann um die Wei­ter­lei­tung auf den ent­spre­chen­den Port.

Wie schon bei Next­Cloud muss im nginx-Dienst auch für word­press ein eige­ner Rever­se Pro­xy ein­ge­rich­tet wer­den. Er lei­tet Anfra­gen an wordpress.mydomain.tld an den ent­spre­chen­den Port wei­ter, der dann schließ­lich von der Docker-Bridge an den kor­rek­ten Con­tai­ner durch­ge­reicht wird. 

Außer­dem sorgt nginx dafür, dass der word­press-Ver­kehr ver­schlüs­selt wird und unver­schlüs­sel­te Anfra­gen auf den https-Port umge­lenkt wer­den. Das SSL-Zer­ti­fi­kat muss zuvor in die omv-Kon­fi­gu­ra­ti­on unter Zer­ti­fi­ka­te → Hin­zu­fü­gen → Impor­tie­ren ein­ge­tra­gen werden.

Den Pro­xy rich­ten wir über Diens­te → nginx → Ser­ver → Hin­zu­fü­gen mit fol­gen­den Anga­ben ein:

• Akti­vie­ren
• Ver­zeich­nis: kei­nes
• Host­typ: Namens­ba­siert
• Ser­ver­na­me: wordpress.mydmain.tld
• SSL akti­vie­ren
• Zer­ti­fi­kat: <aus­wäh­len>
• Only use SSL
• Zusätz­liche Optionen:

location / {
  proxy_pass http://127.0.0.1:8800;
  proxy_http_version 1.1;
  proxy_set_header Host $http_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-Proto $scheme;
  proxy_redirect http:// https://;
} 

Haben wir alles rich­tig gemacht, soll­te nach dem Spei­chern und Akti­vie­ren der Kon­fi­gu­ra­ti­on unser word­press jetzt unter https://wordpress.mydomain.tld erreich­bar sein.

---

Zusätz­li­cher Tipp: spielt man wäh­rend der Tests mit ver­schie­de­nen Kon­fi­gu­ra­tio­nen, Adres­sen und Ports, hilft es unge­mein, den Brow­ser-Cache öfter zu lee­ren, sonst lenkt der Brow­ser Anfra­gen hart­nä­ckig auf zuvor genutz­te URLs um. Ins­be­son­de­re Chro­me hat sich hier als sehr stör­risch erwiesen. 

---

Quel­len:

• word­press image on Docker Hub
• site​point​.com: how to use the offi­ci­al docker word­press image