Technology

Traefik V3: Installation, Konfiguration und CrowdSec-Security

Psycho0verload

17. Oktober 2024

32 Min Read

316 Views

0 Comments

8. Dienst starten

Uff! Das war wirklich eine lange und gründliche Anleitung bis jetzt. Ich habe mein Bestes gegeben, um viele Aspekte direkt zu erläutern und das Verständnis für die Funktionsweise sowie den Aufbau des Stacks zu erleichtern.

Table Of Content

Bevor wir den finalen Schritt gehen und den Dienst starten, möchte ich dir folgendes ans Herz legen: Nimm dir einen Moment Zeit, um nochmal alle Schritte durchzugehen und sicherzustellen, dass alle Dateien richtig erstellt und korrekt befüllt wurden.

8.1. Checkliste

Wurden alle .env-Dateien korrekt konfiguriert?
Ist die docker-compose.yml mit den richtigen Einbindungen versehen?
Sind alle Einträge in den Middleware-Dateien (traefik-bouncer, default) korrekt eingetragen?
Wurde die Traefik-Konfiguration (traefik.yml, tls.yml, http.middlewares.default.yml) richtig angelegt?

Jetzt, bevor du weitermachst: Gönn dir eine kurze Pause, entspann dich, streck dich mal und lass deine Augen etwas Erholung vom Bildschirm haben. Mit frischem Kopf und voller Energie sind wir dann bereit für den nächsten Schritt! ☕️☕️☕️

Bereit?

Dann gehen wir jetzt in das Verzeichnis des Projekts:

cd /opt/containers/traefik-crowdsec-stack

Und starten den Dienst mit Docker Compose:

docker compose up -d

Unsere URL für das Traefik-Dashboard, welche wir in Kapitel: „7.3.1. Allgemeine .env-Datei“ unter SERVICES_TRAEFIK_LABELS_TRAEFIK_HOST festgelegt haben, sollte jetzt erreichbar sein. Beim Aufrufen der Seite wird ein Benutzername und Passwort abgefragt, um den Zugriff zu sichern.

🚀🚀🚀 Fertig, oder?

Wir sind fast durch, aber es gibt noch ein paar abschließende Dinge, die wir erledigen sollten. Als nächstes kümmern wir uns um die Überprüfung dieses Setup.

Bleib also dran, wir sind schon fast am Ziel!

9. Traefik-CrowdSec-Stack überprüfung

Natürlich sollten wir zwischendurch und gemäß dieser Anleitung immer wieder überprüfen, ob alles funktioniert, wie es sollte. Das tun wir jetzt nach all diesen Schritten.

Wir haben den Container ja bereits gestartet. Als erstes überprüfen wir, ob alle Container als „healthy“ (gesund) markiert sind:

cd /opt/containers/traefik-crowdsec-stack
docker compose ps

root@test-01:/opt/containers/traefik-crowdsec-stack# docker compose ps
WARN[0000] The "BOUNCER_KEY_FIREWALL" variable is not set. Defaulting to a blank string. 
NAME                       IMAGE                                       COMMAND                  SERVICE                    CREATED          STATUS                   PORTS
crowdsec                   crowdsecurity/crowdsec:latest               "/bin/bash /docker_s…"   crowdsec                   48 minutes ago   Up 5 minutes (healthy)   
socket-proxy               lscr.io/linuxserver/socket-proxy:latest     "/docker-entrypoint.…"   socket-proxy               48 minutes ago   Up 5 minutes (healthy)   
traefik                    traefik:3.1                                 "/entrypoint.sh trae…"   traefik                    48 minutes ago   Up 5 minutes (healthy)   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp
traefik_crowdsec_bouncer   fbonalair/traefik-crowdsec-bouncer:latest   "/app"                   traefik_crowdsec_bouncer   48 minutes ago   Up 5 minutes (healthy)   
root@test-01:/opt/containers/traefik-crowdsec-stack#

Wenn wir alles richtig gemacht haben, sind alle Container als „healthy“ markiert.

Dann rufen wir das Traefik-Dashboard mit der zuvor festgelegten URL auf. Das Dashboard sollte sich öffnen und auch ein valides LE-Zertifikat haben.

Beim Öffnen des Dashboards werden auch Logdateien erstellt, und diese überprüfen wir als nächstes:

cd /var/log/traefik
ls -all
cat traefik.log
cat access.log

Hier sollten wir idealerweise die Dateien traefik.log und access.log finden, und in beide sollte etwas geschrieben sein. Wenn die Datei access.log nicht vorhanden ist, ist das kein Beinbruch, sollte aber beobachtet werden.

Wenn das alles passt, betrachten wir mit dem Befehl:

docker exec crowdsec cscli metrics

die ganz oben stehenden Acquisition Metrics. Dort sollte nun mit der Zeit die access.log vorhanden sein.

10. Optional

Es gibt noch einige optionale Punkte. Diesen Bereich werde ich nach und nach erweitern bzw. auf vorhandene Anleitungen verweisen!

10.1. CrowdSec aktuell halten

Die aus dem CrowdSec Hub bezogenen COLLECTIONS, PARSERS, SCENARIOS, POSTOVERFLOWS und CONTEXTS werden größtenteils von der Community gepflegt und regelmäßig auf neue CrowdSec-Versionen angepasst. Um sicherzustellen, dass wir keine veralteten Versionen verwenden oder in Fehler laufen, ist es sinnvoll, diese Komponenten regelmäßig zu aktualisieren.

In der früheren Anleitung hatten wir dafür einen Cronjob eingerichtet, der das Update innerhalb des Containers ausgeführt hat. Allerdings ist dies in der aktuellen Form nicht mehr notwendig und wird auch nicht empfohlen. Stattdessen reicht es aus, den CrowdSec-Container gelegentlich neu zu starten. Besonders vor dem Ausführen von docker compose pull sollte sichergestellt werden, dass CrowdSec die neuesten Versionen aus dem Hub geladen hat.

Es ist dennoch denkbar, einen Cronjob einzurichten, der den Container regelmäßig neu startet:

Cronjob einrichten

Um einen Cronjob zu konfigurieren, der den CrowdSec-Container alle 3 Tage neu startet, bearbeite die Crontab-Datei:

crontab -e

Wir fügen den folgenden Eintrag hinzu:

0 3 */3 * * docker compose -f /opt/containers/traefik-crowdsec-stack/docker-compose.yml restart crowdsec

Dieser Cronjob startet den CrowdSec-Container alle 3 Tage um 3 Uhr morgens neu.

Wichtiger Hinweis:
Wir müssen dabei stets bedenken, dass ein automatischer Neustart auch Risiken birgt. Wenn wir unseren Server und das Setup nicht aktiv überwachen und beim Update von CrowdSec etwas schiefgeht, besteht die Gefahr, dass der Server oder die über Traefik laufenden Anwendungen nicht mehr erreichbar sind.

10.2. Traefik-CrowdSec-Stack Update

Um den Stack aktuell zu halten und Updates ordnungsgemäß durchzuführen, empfehlen wir die folgende Befehlsabfolge:

cd /opt/containers/traefik-crowdsec-stack/
docker compose restart crowdsec
docker compose down
docker compose pull
docker compose up -d

Erklärung der Schritte:

Verzeichnis wechseln: Wir wechseln in das Verzeichnis, in dem die Docker-Compose-Dateien des Stacks liegen.
CrowdSec neustarten: Dies aktualisiert die COLLECTIONS, PARSERS, SCENARIOS, POSTOVERFLOWS und CONTEXTS, um sicherzustellen, dass keine Fehler aufgrund von veralteten Versionen auftreten.
Stack herunterfahren: Dies sorgt dafür, dass der Stack sauber beendet wird, was langfristig hilft, unnötige Logdateien zu vermeiden.
Aktualisieren des Stacks: Mit diesem Befehl werden die neuesten Versionen der Docker-Images heruntergeladen.
Stack neu starten: Der aktualisierte Stack wird im Hintergrund wieder hochgefahren.

Durch diese Schritte wird der Stack regelmäßig aktualisiert und mögliche Probleme mit neuen Versionen von CrowdSec oder Traefik werden minimiert.

10.3. Erweiterung der Firewall (UFW bzw. IPTables und NFTables) mit CrowdSec

Jetzt erweitern wir unsere Firewall mithilfe des CrowdSec Firewall Bouncers, um unser System besser vor Angriffen zu schützen. In dieser Anleitung haben wir CrowdSec bereits über Docker in unser System integriert. Nun möchten wir den Firewall-Bouncer direkt auf unserem System installieren und ihn mit dem CrowdSec, das in einem Docker-Container läuft, verknüpfen. Dadurch können wir die Firewall effizient erweitern und Angriffe direkt auf Netzwerkebene abwehren.

10.3.1. Repository für CrowdSec Firewall Bouncer

Um den Firewall Bouncer zu installieren, müssen wir das entsprechende Repository einbinden. Auch wenn die Pakete in einigen Distributionen verfügbar sind, empfiehlt die Dokumentation von CrowdSec, das offizielle Repository hinzuzufügen. Wir führen den folgenden Befehl aus, um die benötigten Repositorys hinzuzufügen:

curl -s https://install.crowdsec.net | sudo sh

Dieser Befehl richtet die erforderlichen Repositorys auf unserem System ein.

10.3.2. Installation des Firewall Bouncers

Abhängig von der verwendeten Firewall (UFW, IPTables oder NFTables) installieren wir das passende Paket. Die Pakete für den CrowdSec Firewall Bouncer sind jetzt über unsere Repositories verfügbar.

UFW + IPTables:

apt install crowdsec-firewall-bouncer-iptables

NFTables:

apt install crowdsec-firewall-bouncer-nftables

10.3.3. Access Token generieren

Ähnlich wie im Schritt 7.3.6. API Key für den CrowdSec Bouncer für Traefik generieren benötigen wir nun ein Passwort für den CrowdSec Bouncer für die Firewall.

Der Access Token wird wie folgt generiert:

BOUNCER_PASSWORD=$(openssl rand -base64 48 | tr -dc 'a-zA-Z0-9!@#$%^&*()-_=+[]{}<>?|')
echo "BOUNCER_KEY_FIREWALL=\"$BOUNCER_PASSWORD\"" >> /opt/containers/traefik-crowdsec-stack/.env
echo "Generated BOUNCER_KEY_FIREWALL: $BOUNCER_PASSWORD"

Generated BOUNCER_KEY_FIREWALL: t/PCqkXRE7Qlm4kGCYUNEiW5LSLvobRMeZ00YN01zpXCHdlYK98ji3ZrGQNNc3H+
root@test-01:/opt/containers/traefik-crowdsec-stack#

Nun speichern wir uns den generierten Schlüssel noch kurz in einem Textdokument oder ähnlichem ab, da wir ihn in Schritt 10.3.4. wieder benötigen.

Damit haben wir unserem Stack den BOUNCER_KEY_FIREWALL hinzugefügt. Damit dieser vom Stack angenommen wird, müssen wir den Stack einmal neu starten:

cd /opt/containers/traefik-crowdsec-stack/
docker compose down
docker compose up -d

10.3.4. Bouncer konfigurieren

Um die Konfiguration des Bouncers anzupassen, öffnen wir die Konfigurationsdatei mit folgendem Befehl:

nano /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Die Datei sieht zunächst folgendermaßen aus:

api_url: http://127.0.0.1:8080/
api_key: <API_KEY>

Wir passen die Konfiguration an, indem wir die folgenden Werte eintragen:

api_url: http://172.31.127.254:8080/
api_key: t/PCqkXRE7Qlm4kGCYUNEiW5LSLvobRMeZ00YN01zpXCHdlYK98ji3ZrGQNNc3H+

Dabei ersetzen wir den Platzhalter t/PCqkXRE7Qlm4kGCYUNEiW5LSLvobRMeZ00YN01zpXCHdlYK98ji3ZrGQNNc3H+ durch den in Schritt 10.3.3. erstellten und gespeicherten Access-Token.

Hinweis: An dieser Stelle funktioniert der Docker Hostname von CrowdSec nicht, weshalb wir die IP-Adresse verwenden müssen. Dies ist einer der Gründe, warum wir die IP von CrowdSec im CrowdSec-Netzwerk explizit definiert haben.

10.3.5. CrowdSec Firewall Bouncer starten

Wir starten den Firewall Bouncer mit folgendem Befehl:

systemctl enable crowdsec-firewall-bouncer
systemctl restart crowdsec-firewall-bouncer

Um sicherzustellen, dass der Bouncer ordnungsgemäß läuft, überprüfen wir den Status mit:

systemctl status crowdsec-firewall-bouncer

Die Ausgabe sollte in etwa so aussehen:

root@test-01:/opt/containers/traefik-crowdsec-stack# systemctl status crowdsec-firewall-bouncer
● crowdsec-firewall-bouncer.service - The firewall bouncer for CrowdSec
     Loaded: loaded (/etc/systemd/system/crowdsec-firewall-bouncer.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2024-10-06 11:10:51 CEST; 25s ago
    Process: 1048574 ExecStartPre=/usr/bin/crowdsec-firewall-bouncer -c /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml -t (code=exited, status=0/SUCCESS)
    Process: 1048586 ExecStartPost=/bin/sleep 0.1 (code=exited, status=0/SUCCESS)
   Main PID: 1048580 (crowdsec-firewa)
      Tasks: 9 (limit: 9450)
     Memory: 47.1M
        CPU: 314ms
     CGroup: /system.slice/crowdsec-firewall-bouncer.service
             └─1048580 /usr/bin/crowdsec-firewall-bouncer -c /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Oct 06 11:10:51 test-01 systemd[1]: Starting The firewall bouncer for CrowdSec...
Oct 06 11:10:51 test-01 systemd[1]: Started The firewall bouncer for CrowdSec.
root@test-01:/opt/containers/traefik-crowdsec-stack#

Damit stellen wir sicher, dass der CrowdSec Firewall Bouncer erfolgreich gestartet wurde und aktiv ist.

Ein automatisches Starten des Bouncers bzw. ein Cronjob, der den Start des CrowdSec Firewall Bouncers verzögert, ist nicht mehr notwendig. Das Problem wurde mit dem Issue #216 gelöst, und ein Fix wurde hinzugefügt.

10.3.6. Anzeigen der CrowdSec Bouncer-Liste

Um sicherzustellen, dass unser Firewall Bouncer korrekt registriert ist, können wir uns die Liste aller registrierten CrowdSec Bouncer anzeigen lassen.

Dazu führen wir den folgenden Befehl aus:

docker exec crowdsec cscli bouncers list

Die Ausgabe sollte in etwa wie folgt aussehen:

root@test-01:/opt/containers/traefik-crowdsec-stack# docker exec crowdsec cscli bouncers list
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Name      IP Address      Valid  Last API pull         Type                       Version                                                                  Auth Type 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 TRAEFIK   172.31.127.252  ✔️     2024-10-06T09:15:41Z  Go-http-client             1.1                                                                      api-key   
 FIREWALL  172.31.64.1     ✔️     2024-10-06T09:16:51Z  crowdsec-firewall-bouncer  v0.0.31-debian-pragmatic-amd64-4b99c161b2c1837d76c5fa89e1df83803dfbcc87  api-key   
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
root@test-01:/opt/containers/traefik-crowdsec-stack#

Beachte, dass die in diesem Beispiel aufgeführten IP-Adressen individuell für unser Setup sind und bei dir möglicherweise andere Werte erscheinen.

Damit haben wir erfolgreich bestätigt, dass unser Firewall Bouncer in der Liste aufgeführt wird und korrekt funktioniert.

10.4. Logrotate für Traefik

Es ist bereits bekannt, dass die access.log-Datei sehr schnell wächst, insbesondere wenn das Debug-Level auf „info“ gesetzt ist. Das kann schnell zu Speicherplatzproblemen führen, wenn sie nicht gehandhabt wird. Traefik selbst bietet keine eingebaute Log-Rotation-Funktion, aber zum Glück gibt es eine Standardkomponente namens Logrotate in vielen Linux-Distributionen wie Ubuntu, die uns dabei helfen kann.

[ihc-hide-content ihc_mb_type=“show“ ihc_mb_who=“3,4″ ihc_mb_template=“1″ ]

Logrotate ist ein Systemdienst, der automatisch alte Logdateien löscht und neue erstellt. Es kann täglich, wöchentlich, monatlich oder wann immer der Logfile eine bestimmte Größe erreicht, ausgeführt werden.

Zunächst erstellen wir eine neue Konfigurationsdatei für Logrotate. Wir können nano verwenden, um die Datei zu öffnen:

nano /etc/logrotate.d/traefik

In dieser Datei fügen wir die folgende Konfiguration ein, passen den Pfad zu unserer traefik.log-Datei entsprechend an:

/var/log/traefik/access.log {
    daily
    missingok
    rotate 5 
    compress
    delaycompress
    notifempty
    create 0644 root root
    postrotate
       docker restart $(docker ps --no-trunc --filter name=^/traefik$ --quiet)
    endscript
}

Hier sind die einzelnen Zeilen erklärt:

/var/log/traefik/access.log {: Dieser Eintrag bestimmt, welche Logdatei rotiert wird. In diesem Fall ist es die Traefik-Logdatei.
daily: Diese Direktive gibt an, dass die Logdatei täglich rotiert werden soll.
missingok: Diese Direktive besagt, dass es in Ordnung ist, wenn die Logdatei fehlt und Logrotate beim Versuch, sie zu rotieren, keinen Fehler ausgeben soll.
rotate 5: Diese Direktive bestimmt, wie viele alte Logdateien aufbewahrt werden sollen. In diesem Fall werden fünf alte Logdateien aufbewahrt.
compress: Diese Direktive gibt an, dass alte Logdateien komprimiert werden sollen, um Speicherplatz zu sparen.
delaycompress: Diese Direktive bedeutet, dass die Kompression der Logdatei erst nach der zweiten Rotation erfolgt. Dies ist nützlich, wenn Programme noch auf die alte Logdatei zugreifen könnten.
notifempty: Diese Direktive besagt, dass die Logdatei nicht rotiert werden soll, wenn sie leer ist.
create 0644 root root: Diese Direktive erstellt eine neue Logdatei mit den angegebenen Berechtigungen und dem angegebenen Benutzer und Gruppenbesitzer nach der Rotation. In diesem Fall ist root sowohl der Benutzer als auch der Gruppenbesitzer, und die Berechtigungen sind auf 0644 gesetzt. Im Vorfeld habe ich mir mit ls -all /var/log/traefik angeschaut mit welcher Berechtigung die Datei geschrieben wird.
postrotate und endscript: Alles zwischen diesen beiden Direktiven wird nach jeder Rotation ausgeführt. In diesem Fall wird der Traefik-Docker-Container neu gestartet.
docker restart $(docker ps --no-trunc --filter name=^/traefik$ --quiet): Dieser Befehl wird nach der Rotation ausgeführt und startet den Traefik-Container neu. Der docker ps-Teil des Befehls filtert den Ausgabe der laufenden Docker-Container, um den Traefik-Container zu finden.

Die Klammer } am Ende markiert das Ende der Konfiguration für diese spezielle Logdatei.

Wir können die Log-Rotation auch basierend auf der maximalen Dateigröße anstelle des täglichen Zeitplans begrenzen. Hier ist die aktualisierte Konfiguration, die auf einer maximalen Dateigröße basiert:

/var/log/traefik/access.log {
    size 10M
    rotate 5 
    compress
    delaycompress
    missingok
    notifempty
    create 0644 root root
    postrotate
        docker restart $(docker ps --no-trunc --filter name=^/traefik$ --quiet)
    endscript
}

In dieser Konfiguration haben wir die Option size 10M hinzugefügt, um die maximale Dateigröße auf 10 Megabyte festzulegen. Sobald die Log-Datei diese Größe erreicht, wird sie rotiert.

[/ihc-hide-content]

10.5. Mailcow anpassen

In dieser Anleitung haben wir den Pfad der Zertifikatsdateien im Vergleich zu früheren Versionen geändert. Diese Änderung muss auch in der Mailcow-Konfiguration berücksichtigt werden. Der folgende docker-compose.override.yml zeigt, wie Mailcow in Verbindung mit Traefik und den neuen Zertifikatspfaden konfiguriert wird.

networks:
  proxy:
    name: proxy
    external: true

services:
  certdumper:
    image: ghcr.io/kereis/traefik-certs-dumper:latest
    restart: unless-stopped
    network_mode: none
    command: --restart-containers mailcowdockerized-postfix-mailcow-1,mailcowdockerized-dovecot-mailcow-1
    volumes:
      - /opt/containers/traefik-crowdsec-stack/data/traefik/certs:/traefik:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./data/assets/ssl:/output:rw
    environment:
      DOMAIN: ${MAILCOW_HOSTNAME}
      ACME_FILE_PATH: "/traefik/tls_letsencrypt.json"
    healthcheck:
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5

  nginx-mailcow:
    networks:
      proxy:
    labels:
      traefik.docker.network: proxy
      traefik.enable: "true"
      traefik.http.services.nginx-mailcow.loadbalancer.server.port: "80"
      traefik.http.routers.nginx-mailcow-euredomain_de-secure.entrypoints: websecure
      traefik.http.routers.nginx-mailcow-euredomain_de-secure.rule: "Host(`mail.euredomain.de`) || Host(`autodiscover.euredomain.de`) || Host(`autoconfig.euredomain.de`) || Host(`mta-sts.euredomain.de`) || Host(`imap.euredomain.de`) || Host(`pop3.euredomain.de`) || Host(`smtp.euredomain.de`)"
      traefik.http.routers.nginx-mailcow-euredomain_de-secure.service: nginx-mailcow
      traefik.http.routers.nginx-mailcow-euredomain_de-secure.tls: "true"
      traefik.http.routers.nginx-mailcow-euredomain_de-secure.tls.certresolver: tls_resolver
      traefik.http.routers.nginx-mailcow-euredomain_de-unsecure.entrypoints: web
      traefik.http.routers.nginx-mailcow-euredomain_de-unsecure.rule: "Host(`mail.euredomain.de`) || Host(`autodiscover.euredomain.de`) || Host(`autoconfig.euredomain.de`) || Host(`mta-sts.euredomain.de`) || Host(`imap.euredomain.de`) || Host(`pop3.euredomain.de`) || Host(`smtp.euredomain.de`)"

Wichtige Änderungen:

Der Pfad zu den Zertifikaten ist jetzt: /opt/containers/traefik-crowdsec-stack/data/traefik/certs/.
Der certdumper Dienst ist so konfiguriert, dass er die Zertifikate aus diesem neuen Pfad liest und in das benötigte Verzeichnis für Mailcow exportiert.
Das Volumen für die Zertifikate ist entsprechend dem neuen Pfad gesetzt: /opt/containers/traefik-crowdsec-stack/data/traefik/certs/:/traefik:ro.

Mit diesen Anpassungen ist Mailcow korrekt mit Traefik und den neuen Zertifikatspfaden konfiguriert.

Nun müssen wir noch die URLs anpassen. Dies könnt ihr von Hand machen oder mit folgendem Skript. Wichtig ist, dass ihr das Skript noch an eure Domain anpasst.

cd /opt/containers/mailcow
sed -i "s/euredomain.de/<DeineDomain>/g" docker-compose.override.yml  # Beispiel: sed -i "s/euredomain.de/goneuland.de/g" docker-compose.override.yml
sed -i "s/euredomain_de/<DeineDomain>/g" docker-compose.override.yml  # Beispiel: sed -i "s/euredomain_de/goneuland_de/g" docker-compose.override.yml

11. Neuen Container hinzufügen

Um einen neuen Container über Traefik verfügbar zu machen und gleichzeitig durch CrowdSec zu schützen, müssen wir in der zugehörigen docker-compose.yml die Ports entfernen und dem entsprechenden Container Labels hinzufügen. Hier ein Beispiel mit WordPress:

Dies ist die docker-compose.yml aus der WordPress-Dokumentation auf hub.docker.com:

version: '3.1'
services:
  wordpress:
    image: wordpress
    restart: always
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - wordpress:/var/www/html
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql
volumes:
  wordpress:
  db:

Dies wird dann zu folgender Konfiguration geändert:

version: '3.1'
services:
  wordpress:
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: exampledb
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_USER: exampleuser
    image: wordpress
    labels:
      traefik.docker.network: proxy
      traefik.enable: "true"
      traefik.http.routers.wordpress-secure.entrypoints: websecure
      traefik.http.routers.wordpress-secure.middlewares: default@file
      traefik.http.routers.wordpress-secure.rule: Host(`meinwordpress.de`)
      traefik.http.routers.wordpress-secure.service: wordpress
      traefik.http.routers.wordpress-secure.tls: "true"
      traefik.http.routers.wordpress-secure.tls.certresolver: tls_resolver
      traefik.http.routers.wordpress.entrypoints: web
      traefik.http.routers.wordpress.rule: Host(`meinwordpress.de`)
      traefik.http.services.wordpress.loadbalancer.server.port: "80"
    networks:
      default: null
      proxy: null
    restart: always
    volumes:
    - wordpress:/var/www/html
  db:
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: "1"
      MYSQL_USER: exampleuser
    image: mysql:5.7
    networks:
      default: null
    restart: always
    volumes:
    - db:/var/lib/mysql
networks:
  default:
  proxy:
    external: true
volumes:
  db:
  wordpress:

Als Multi-Domain sieht das dann so aus:

version: '3.1'
services:
  wordpress:
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: exampledb
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_USER: exampleuser
    image: wordpress
    labels:
      traefik.docker.network: proxy
      traefik.enable: "true"
      traefik.http.routers.wordpress-secure.entrypoints: websecure
      traefik.http.routers.wordpress-secure.middlewares: default@file
      traefik.http.routers.wordpress-secure.rule: Host(`meinwordpress.de`) || Host(`www.meinwordpress.de`)
      traefik.http.routers.wordpress-secure.service: wordpress
      traefik.http.routers.wordpress-secure.tls: "true"
      traefik.http.routers.wordpress-secure.tls.certresolver: tls_resolver
      traefik.http.routers.wordpress.entrypoints: web
      traefik.http.routers.wordpress.rule: Host(`meinwordpress.de`) || Host(`www.meinwordpress.de`)
      traefik.http.services.wordpress.loadbalancer.server.port: "80"
    networks:
      default: null
      proxy: null
    restart: always
    volumes:
    - wordpress:/var/www/html
  db:
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: "1"
      MYSQL_USER: exampleuser
    image: mysql:5.7
    networks:
      default: null
    restart: always
    volumes:
    - db:/var/lib/mysql
networks:
  default:
  proxy:
    external: true
volumes:
  db:
  wordpress:

Eine kurze Erklärung dazu: Die Ports müssen nicht mehr explizit freigegeben (exposed) werden, da dies nun Traefik übernimmt. Wir teilen Traefik lediglich über Labels mit, welcher Resolver verwendet werden soll und über welchen Port Traefik auf WordPress zugreifen kann. Zusätzlich muss dem WordPress-Container noch das Traefik-Netzwerk namens „proxy“ zugewiesen werden. Allerdings sollte dies nur dem WordPress-Container zugewiesen werden, da wir zwar die Datenbank gemeinsam mit WordPress im „default“-Netzwerk betreiben, die Datenbank jedoch nicht öffentlich zugänglich machen möchten.

11.1. TLS anstelle von HTTP

Wie der Name schon sagt: Nutzt mehr den tls_resolver und nicht den http_resolver. Traefik macht TLS möglich und am Ende ist es die modernere Variante!