Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

WordPress Docker Container

Verzeichnisse und docker-compose Datei erstellen

Wir legen wie erwartet ein Verzeichnis „wordpress.xp-server.de“ unterhalb von „/var/www“ an. In diesem Verzeichnis befinden sich dann die „docker-compose“-Datei und das Verzeichnis mit der eigentlichen Anwendung von WordPress.

Im Gegensatz zur Nextcloud Installation brauchen wir hier kein separates Datenverzeichnis.

Das Setup der „docker-compose“-Datei sollte uns jetzt keine Probleme mehr bereiten. Das haben wir ja mittlerweile schon ein paar mal gemacht :)

mkdir -p /var/www/wordpress.xp-server.de
nano /var/www/wordpress.xp-server.de/docker-compose.yml
### WordPress
### docker-compose.yml
###
##Start
version: '3'
services:

 wordpress:
  image: wordpress-php73-apache:latest
  container_name: wordpress
  restart: always
  networks:
   - intern
   - web
  ports:
   - 80
  environment:
   WORDPRESS_DB_NAME: wp_data
   WORDPRESS_DB_USER: wp_user
   WORDPRESS_DB_PASSWORD: 'unglaublichsicherespasswort'
   WORDPRESS_TABLE_PREFIX: tprefx_
   WORDPRESS_DB_HOST: maria104master:3306
  labels:
   - "traefik.enable=true"
   - "traefik.backend=wordpress"
   - "traefik.frontend.rule=Host:wordpress.xp-server.de"
   - "traefik.docker.network=web"
   - "traefik.frontend.headers.STSSeconds=315360000"
   - "traefik.frontend.headers.browserXSSFilter=true"
   - "traefik.frontend.headers.contentTypeNosniff=true"
   - "traefik.frontend.headers.forceSTSHeader=true"
   - "traefik.frontend.headers.STSIncludeSubdomains=true"
   - "traefik.frontend.headers.STSPreload=true"
   - "traefik.frontend.headers.customFrameOptionsValue=SAMEORIGIN"
  volumes:
   - ./wpdata:/var/www/html
  external_links:
   - maria104master

networks:
  intern:
    external: true
  web:
    external: true
##EOF

Die „docker-compose“-Datei ist bis auf kleine Anpassungen ziemlich das, was wir bei den vorhergehenden Dateien schon kennengelernt haben:

Zeilen 5-8: Wir deklarieren die Version (3) und den Namen des Services (wordpress).

Zeile 9: Als Image verwenden wir unser frisch gebackenes eigenes WordPress Image des vorherigen Kapitels. Die Versionsbezeichnung „:latest“ sorgt dafür, dass wir immer das mit „:latest“ getaggte Image laden.

Zeile 10: Containername für Docker: wordpress
Ist an der Stelle vielleicht inkonsequent, da ich die Container wie auch die Backends eigentlich mit der vollen URL benennen sollte. Da wir aber im Moment nur eine Instanz von WordPress hochfahren, verzichte ich auf den vollen Domainnamen…

Zeile 11: Unser CMS soll natürlich immer laufen, bzw. nach einem Neustart des Servers automatisch mit neu gestartet werden, daher „restart: always“.

Zeilen 12-14: Wir brauchen beide Docker-Netzwerke. Das Interne für die Verbindung zur Datenbank und das „Web“ zum Internet über unseren Reverse-Proxy Traefik.

Zeilen 15+16: Wir docken Traefik auf Port 80 an den Container an.

Zeilen 17-22: Über die „Environment“-Variablen übergeben wir den Datenbank-Server, den Namen der Datenbank, des Benutzers und das Passwort intern an WordPress, damit wir das beim Setup nicht mehr einzustellen brauchen. Hier musst Du Deine eigenen Werte eintragen!
Das „Table Prefix“ ist eine vor den eigentlichen Tabellennamen angestellte Zeichenkette, die verhindern soll, dass die Tabellennamen, die ja bekannt sind, einfach so „erraten“ werden können. Einfach ein paar Zeichen eingeben und mit einem Unterstrich von den folgenden Tabellennamen trennen. Hat im täglichen Betrieb sonst keine Bedeutung und steigert nur ein wenig die Sicherheit…

Zeilen 23-34: Die Traefik-Label, welche diverse Einstellungen an unseren Reverse Proxy Dienst übergeben.
Zeile 26 bitte mit Deiner URL ersetzen, damit die Verbindung ins Internet und das Anfordern des Zertifikats klappt!
Wichtig! Hier bespreche ich ja nur den Einsatz von einer Subdomain, „wordpress.xp-server.de“. Möchten wir stattdessen eine „Haupt“-Domain mit und ohne „www“ online bringen, müssen wir beide Varianten in die Zeile schreiben. Die „Hauptdomain“ als erstes. Also für „www.xp-server.de“ schaut die Konfiguration dann wie folgt aus:

   - "traefik.frontend.rule=Host:www.xp-server.de,xp-server.de"

Hintergrund: „www.xp-server.de“ und „xp-server.de“ sind aus Sicht des DNS zwei völlig unterschiedliche Adressen, auch, wenn sie auf den gleichen Server zeigen. Traefik muss folgerichtig beide kennen, damit er a) beide auf den WordPress Container leiten und b) für beide ein Zertifikat besorgen kann. WordPress kümmert sich dann um das Weiterleiten der Adresse von „nicht www“ auf „www“, damit „www.xp-server.de“ und „xp-server.de“ nicht gleichzeitig mit unterschiedlicher URL aufrufbar sind. Das würde Google abstrafen… Darum erscheint oben im Browser, falls jemand „xp-server.de“ eingibt, gleich „www.xp-server.de“. Die Webseite ist einzig mit dieser URL im Netz.

Zeilen 35+36: Hier richten wir einen Volume-Mount ein, damit die ganze WordPress-Anwendung nebst aller Daten, Plugins, Themes und unseren Uploads persistent auf unserem Host gespeichert wird. Der Inhalt des „/var/www/html“-Verzeichnisses des Containers wird relativ zum Basisverzeichnis unseres Hosts „/var/www/wordpress.xp-server.de“ in das neue Verzeichnis „wpdata“ gespeichert.

Zeilen 37+38: Der externe Link zum MariaDB Container wird eingerichtet.

Zeilen 40-44: Die Netzwerke werden noch einmal aufgelistet und über „external“ mitgeteilt, dass diese Netzwerke beim Schließen des Containers nicht gelöscht werden sollen.

WordPress Container starten, Logfile auswerten

Da wir das Image lokal erzeugt haben, brauchen wir das nicht mehr aus dem Internet herunterladen und können den Container gleich hochfahren lassen.

Bitte beachten: Dieser Vorgang ist zeitkritisch!
Sobald der Container läuft, kann sich theoretisch jeder auf unserer URL einloggen und das Setup beenden. Dann ist das „sein“ CMS, nicht unseres… :/
Also bitte gleich nach dem Hochfahren des Containers über den Browser einloggen und das Setup SELBST abschließen, bevor es jemand anders tut!

docker-compose -f /var/www/wordpress.xp-server.de/docker-compose.yml up -d
docker ps -a
docker logs -f --tail="50" wordpress

Anzeige *

6 Kommentare zu „WordPress Docker Container“

  1. Hallo Peter,
    erstmal vielen Danke für deine Tutorials. Dadurch habe ich es geschafft auf meinem Heimserver eine WordPressinstallation mit Rev.Proxy zu installieren.
    Jetzt habe ich aber ein Problem mit dem Matomo iFrame in meine Datenschutzerklärung. Leider wird mit der Inhalt im Frame nicht angezeigt, ich bekomme im Edge die Meldung, dass „Dieser Inhalt kann nicht in einem Frame angezeigt werden.
    An dieser Stelle sollten Sie eigentlich Inhalte sehen, aber der Herausgeber lässt die Anzeige in einem Frame nicht zu. Dadurch wird die Sicherheit der Informationen gewährleistet, die Sie ggf. auf dieser Website eingeben.“

    Wenn ich den Link anklicke wird mir der Inhalt auf einer extra Seite korrekt angezeigt.

    Habe keine Ahnung wo ich da anfagen soll. Bzw. wo das Problem liegt (WordPress,Ninja-Firewall,Traefik,Matomo)? Vielleicht kannst du mir helfen?

    Grüße Oliver

    1. Hallo Oliver,
      vielen Dank für das Lob! Dann hat sich die ganze Mühe auch rentiert, wenn ich jemand damit helfen konnte.

      Ich glaube, dass Dein iframe Link beim Kopieren oder Einfügen geändert wurde. Da stehen hinter den Anweisungen jeweils (ich muss das gesperrt schreiben, sonst wird das auch interpretiert) [& a m p ;], was da eigentlich nicht hingehört.

      In Gutenberg mach ich den Iframe mit einem „HTML“-Block, damit der 1:1 dargestellt und nicht interpretiert wird.

      Was auch sein kann sind besondere Security Header (X-Frame-Options), welche das Ausliefern von Iframes unterbinden. Aber da sehen ich auf Deiner Seite eigentlich nichts davon.

      Probier mal bitte, den Iframe als „HTML“-Block neu zu setzen. Ich hoffe, dass es das war :)

      Update: Ist doch ein Security Frame, der Inspector bringt mir diese Ausgabe:
      [ Laden verboten durch X-Frame-Options: „DENY“ ]

      Update 2: Mea Culpa…
      Ich hab beim traefik nicht aufgepasst. Da gehört für Matomo einer der Labels anders gesetzt, sonst haben wir den Salat.
      In Zeile 30 der docker-compose.yml Datei von matomo gehört „traefik.frontend.headers.frameDeny=true“ auf „false“ gesetzt.
      Danach den Container stoppen, starten und es müsste gehen.

        1. Super, danke für die Rückmeldung :)
          Hab das Tutorial entsprechend angepasst, damit da keiner mehr drüber stolpert.
          Noch viel Erfolg mit Deiner Webseite und einen „Guten Rutsch“ in neue Jahr!

    1. Noch mal Danke für diesen Hinweis, Christian!

      Da dachte ich, dass sich im WordPress Image das Apache Modul „remoteip“ darum kümmert?

      Vorher hab ich das über die Datei „.htninja“ im Webroot von WordPress gelöst…
      Mehr Info: http://nintechnet.com/ninjafirewall/wp-edition/help/?htninja

      Wobei die Lösung direkt über die wp-config.php schon sehr elegant ist, muss ich sagen…

      Und gern geschehn! Wenn die ganze Dokumentation für jemand hilfreich war, hab ich sie gerne ins Netz gestellt :)

Kommentar verfassen

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

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top