Im ersten Teil haben wir mit docker-compose eine erste WordPress Instanz gestartet, diese wollen wir nun aus dem Internet erreichbar machen.

Wir haben nur eine öffentliche IP Adresse, die wir unter unseren verschiedenen Applikationen routen müssen. Für diesen Zweck haben wir einen NGINX, der als Reverse Proxy fungiert. HTTP(S) Traffic aus dem Internet wird über den Router an den NGINX weitergeleitet. Pro Zielapplikation wird von dort dann abhängig vom Hostname im HTTP Header an die richtige VM im lokalen Netz 192.168.1.0/24 weitergeleitet. Zudem ist der NGINX für die SSL Terminierung über Let’s Encrypt Zertifikate zuständig. Intern betreiben wir alle Applikation mit HTTP unverschlüsselt.

Nameserver konfigurieren

Wir haben dyndns.com als als Domain Name Server. Dort navigieren wir in den Zone Level Service für tdm.consult.com und legen einen neuen CNAME Record wie folgt an:

blog.tdm-consult.com 600 CNAME hage.tdm-consult.com.

Dabei „zeigt“ der CNAME Record auf den A-Record hage.tdm-consult.com, hinter dem sich die eigentliche IP Adreesse verbirgt. 600 ist der TTL Wert, also die Gültigkeitsspanne des Eintrags.

Reverse Proxy konfigurieren

Auf unserem Router müssen wir nichts machen: Der leitet bisher schon jeden Traffic auf Port 80 (HTTP) und 443 (HTTPS) an den Internen Reverse Proxy. Auch der NGINX läuft natürlich als Docker-Container. Für die Konfiguration haben wir ein Volume für die Konfiguration ./conf:/etc/nginx/conf.d:ro gemappt. In diesem Verzeichnis wird nun eine weitere Datei für unseren neuen Service angelegt. Per internen Konvention benennen wir sie nach der Domain mit .conf Endung, also blog.tdm-consult.com.conf:

server {
  listen 80;
  listen [::]:80;

  server_name blog.tdm-consult.com;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;

  ssl_certificate /etc/nginx/letsencrypt/live/blog.tdm-consult.com/fullchain.pem;
  ssl_certificate_key /etc/nginx/letsencrypt/live/blog.tdm-consult.com/privkey.pem;

  server_name blog.tdm-consult.com;

  location /.well-known/ {
      root /etc/nginx/acme-challenge;
  }

  location / {
      proxy_pass http://192.168.1.24/;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Port $server_port;
  }
}

Wir leiten als Traffic auf Port 80 HTTP direkt auf Port 443 HTTPS via Redirection (HTTP Code 301) um und akzeptieren nur verschlüsselte Verbindungen.

Zertifikat anfordern

Die Zertifikate gibt es ja noch nicht – sie werden unter /etc/nginx/letsencrypt erwartet. Hierzu haben wir ein separates Docker-Compose File, dass das Image certbot/certbot geeignet parametrisiert und den Ziel-Folder ebenfalls als Volume mounted: 

version: '2'
services:
  certbot:
    image: certbot/certbot
    entrypoint:
      - certbot
      - certonly
      - -m info@tdm-consult.com
      - --agree-tos
      - --webroot
      - --webroot-path=/data/acme-challenge
      - -d ${FQDN}
    volumes:
      - ./acme-challenge:/data/acme-challenge
      - ./letsencrypt:/etc/letsencrypt

Der Server, für den das Zertifikat angefragt werden soll, wird als FQDN Environment in den Container gegeben. Das neue Zertifikat kann nun wie folgt abgerufen werden:

export FQDN=blog.tdm-consult.com
docker-compose -f docker-compose-certbot.yml up

Der Zertifikat ist drei Monate gültig, danach kann es über denselben Mechanismus aktualisiert werden. Im letzten Schritt wird der NGINX zum Neuladen der Konfiguration veranlasst:

# reload NGINX configuration
docker exec -it docker_nginx_nginx_1 nginx -s reload

Zur Sicherung aller Daten, also der NGINX Konfiguration, der Docker-Files sowie der Zertifikate selbst, liegen diese alle im Git: Sie werden nun eingecheckt. Dabei ist zu beachten, dass der cerbot-Container als root läuft, so dass auch die Dateien entsprechend erzeugt wurden: Dies müssen wir vor dem Commit noch ändern. Das Script sieht dann so aus:

sudo chown tdm:users -R letsencrypt
git add --all
git commit -m "New Certificate for blog Domain"
git push origin

Das ganze verpacken wir noch in ein Script, damit später die Erneuerung aller Zertifikate automatisch und ggf. über Cron gesteuert funktioniert:

#!/bin/bash

# request for renewal
export FQDN=www.tdm-consult.com
docker-compose -f docker-compose-certbot.yml up
...
export FQDN=blog.tdm-consult.com
docker-compose -f docker-compose-certbot.yml up

# reload NGINX configuration
docker exec -it docker_nginx_nginx_1 nginx -s reload

# checkin new certificates with GIT
sudo chown tdm:users -R letsencrypt
git add --all

today=$(date +%Y-%m-%d)
git commit -m "Certificate re-newal as of $today"
git push origin

WordPress konfigurieren

Jetzt fehlen noch zwei Dinge, die wir in WordPress konfigurieren muss: Da ist zum einen die Basis-URL, die wie umstellen müssen. Dazu wird unter Settings | General für WordPress Address (URL) und Site Address (URL) die öffentliche Adresse eingetragen, also z.B. https://blog.tdm-consult.com.

Zudem müssen wir WordPress mitteilen, dass wir hinter einem Reverse Proxy betrieben werden. Unter Administration Over SSL sind die Hintergründe beschrieben. Für uns bedeutet dies ganz konkret, dass beim Start von WordPress über Docker-Compose die Umgebungsvariable HTTP_X_FORWARDED_PROTO gesetzt werden muss. Der wordpress-Block im Docker-Compose sieht dann wie folgt aus:

    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
      HTTP_X_FORWARDED_PROTO: https

Anschließend ist die Seite unter blog.tdm-consult.com zu erreichen.

Im nächsten Teil wollen wir ein Theme installieren und dem Blog so etwas mehr Eleganz verleihen – und das natürlich so, dass das Theme auch bei zukünftigen Installation über Docker automatisch heruntergeladen und aktiviert wird.