Jetzt wollte ich “mal schnell” ein Worpress einrichten. Mit docker geht das ja jetzt alles super einfach.
Stimmt auch, aber leider nur im Prinzip.

Was zu meiner momentanen Lösung gehört:

1. auf meinem “produktiv”-Docker-Host (den ich via https://www.tutum.co/ verwalte – nebei: sehr empfehlenswert):
   • folgender Service-Stack:

     mysql:
      image: 'mysql:latest'
      environment:
      - MYSQL_ROOT_PASSWORD=xxxxx
      restart: always
      roles:
      - global
      sequential_deployment: true
      tags:
      - prod
      volumes:
      - '/opt/wordpress/var_lib_mysql:/var/lib/mysql'
      - '/etc/localtime:/etc/localtime'
      - '/etc/timezone:/etc/timezone'
     wordpress:
      image: 'dsteinkopf/wordpress:latest'
      links:
      - mysql
      ports:
      - '8082:80'
      restart: always
      roles:
      - global
      sequential_deployment: true
      tags:
      - prod
      volumes:
      - '/opt/wordpress/var_www_html:/var/www/html'
      - '/etc/localtime:/etc/localtime'
      - '/etc/timezone:/etc/timezone'

   • Ich verwende das “offical” mysql-Image. Das docker-Image “tutum/mysql/ klappt nicht (so gut), weil sich dann das wordpress-Image nicht so reibungslos mysql username und pw etc. via docker-Verlinkung holen kann.
   • Ich habe ein eigenes WordPress-Docker-Image gebaut, dessen Dockerfile (siehe github) nur aus “FROM wordpress” besteht. (Es ist also identisch zum “official” wordpress-Image – und ist derzeit WordPress 4.4)
     Grund: Das ist die einzige Möglichkeit, die ich kenne, bei Docker-Hub einen Webhook einzutragen, der mir bei Tutum das Image automatisch von dort neu holt und installiert.
2. Ein Apache auf einem “echten” (naja virtuellen) Host.
   • Diese macht die SSL-Terminierung.
   • Das Zertifikat habe ich von Letsencrypt vollautomatisch holen lassen – mit Hilfe von

     ./letsencrypt-auto --redirect --rsa-key-size 4096 --domains nerdblog.steinkopf.net

   • Die Apache-Config sieht bei meinen anderen Hosts im Kern immer nur so aus:

     RewriteEngine On
     ProxyRequests Off
     ProxyPass / https://mydockerhost.steinkopf.net:x8082x/
     ProxyPassReverse / https://mydockerhost.steinkopf.net:x8082x/

   • Bei WordPress reicht das nicht. Einiges googeln hat mir den Eindruck verschafft, dass WordPress für diesen “Betriebsmode” nicht wirklich gebaut wurde. Ich habe mich mehrfach ausgesperrt und nicht das Prinzip der Redirects verstanden. Vielleicht findet sich das genaue Verständnis ja noch.
   • Wenn man sich durch eintragen falscher Werte in der WP-Konfig in “” oder “” aussperrt kann mit sich retten mit einträgen in der wp-config.php:

     define('WP_SITEURL', 'https://nerdblog.steinkopf.net/');
     define('WP_HOME', 'https://nerdblog.steinkopf.net/');

3. “Lösung” (fast) für das Reverse-Proxy-Problem:
   • In der wp-config.php:

     if (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
         $_SERVER['REMOTE_ADDR'] = $_SERVER["HTTP_X_FORWARDED_FOR"];
     }

   • In der Apache-Config:

     
         ProxyHTMLEnable On
         ProxyHTMLExtended On
     
         ProxyHTMLLinks a href
         ProxyHTMLLinks area href
         ProxyHTMLLinks link href
         ProxyHTMLLinks img src longdesc usemap
         ProxyHTMLLinks object classid codebase data usemap
         ProxyHTMLLinks q cite
         ProxyHTMLLinks blockquote cite
         ProxyHTMLLinks ins cite
         ProxyHTMLLinks del cite
         ProxyHTMLLinks form action
         ProxyHTMLLinks input src usemap
         ProxyHTMLLinks head profile
         ProxyHTMLLinks base href
         ProxyHTMLLinks script src for
         ProxyHTMLLinks iframe src
     
         RequestHeader unset Accept-Encoding
     
         ProxyHTMLURLMap /wp-admin/ /wp-admin/
         ProxyHTMLURLMap \/wp-admin\/ \/wp-admin\/
         ProxyHTMLURLMap https://nerdblog.steinkopf.net/ https://nerdblog.steinkopf.net/
         ProxyHTMLURLMap https://nerdblog.steinkopf.net https://nerdblog.steinkopf.net
      
     
      ProxyPassReverseCookieDomain mydockerhost.steinkopf.net nerdblog.steinkopf.net
      ProxyPassReverseCookiePath / /

   • Anmerkungen:
     • Die ersten beiden “ProxyHTMLURLMap” sind nicht  nötig, ich habe sie aber drin gelassen – zu Erinnerung, dass man hier noch ggf. was mit Pfaden machen könnte, wenn nötig.
     • vgl. http://faq.wpde.org/wordpress-url-aendern/
     • und https://wordpress.org/support/topic/wordpress-behind-reverse-proxy-1
     • bzw. https://wordpress.org/support/topic/wordpress-behind-a-reverse-proxyssl-endpoint-slightly-borked
4. Offene Probleme:
   • Themes, die das img-Tag mit “usemap” benutzen, funktionieren nicht, da das mod_proxy_html mit ProxyHTMLLinks in der “usemap” immer nur den ersten Link anpasst, weil es vermutlich den Rest des Attributs als zum ersten Link gehörend betrachtet.
   • In Mails die verschickt werden, enhalten noch den internen Link. 🙁 Wer sollte das auch korrigieren? Der Reverse-Proxy kommt ja hier gar nicht “vorbei”.
   • Beim Theme-Preview wird auch noch die interne URL verwendet. (Zum Bearbeiten des Theme gehe auch also direkt auf die intern URL…)
   • Alle Plugins (z.B. Sharing-Plugins), die die Wordpress-URL an andere Dienste weiter geben, benutzen auch die falsche interne.