Ein wordpress-Testserver

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 word­press-Instal­la­ti­on.

MariaDB für wordpress 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@'%';

wordpress 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­to­wer sorgt spä­ter dafür, dass auch updates auf das jeweils letz­te Image aus­ge­führt wer­den.

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” kli­cken.

Im Start­dia­log machen wir fol­gen­de Anga­ben:

  • 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­li­che Umge­bungs­va­ria­ble:
    • 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 umge­lei­tet.

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 wer­den.

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

Reverse Proxy 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 wer­den.

Den Pro­xy rich­ten wir über Diens­tenginxSer­verHin­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­li­che Optio­nen:
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 erwie­sen.


Quel­len:

Eine Antwort auf „Ein wordpress-Testserver“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.