
Traefik V3: Installation, Konfiguration und CrowdSec-Security
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
- Versionierung
- WICHTIG!
- 0. Testing
- 1. Zielsetzung
- 2. Voraussetzung
- 2.1. Hinweis
- 3. Grundlage: Netzwerke in Docker
- 3.1. Private Adressbereiche in IPv4
- 3.2. Adressbereiche in Docker
- 3.3. Verständnis der Netzwerkproblematik
- 3.4. Lösung
- 4. Netzwerke konfigurieren
- 4.1. Vorbereitung
- 4.2. Docker Konfigurieren anpassen
- 4.3. Ergebnis
- 4.3.1. IPv6-Konfiguration
- 5. Überblick über die Systeme
- 5.1. Traefik
- 5.2. Docker-Socket-Proxy
- 5.3. CrowdSec
- 5.4. CrowdSec Bouncer
- 6. Stack vorbereiten
- 6.1. Hauptverzeichnis erstellen und in das Verzeichnis wechseln
- 6.2. Dateien erstellen und Berechtigungen setzen
- 6.3. Überprüfung
- 7. Stack konfigurieren
- 7.1. docker-compose.yml-Datei
- 7.2. compose-Dateien
- 7.3. DOTENV anpassen
- 7.3.1. Allgemeine .env-Datei
- 7.3.2. .env-Datei für CrowdSec
- 7.3.3. .env-Datei für den Socket-Proxy
- 7.3.4. .env-Datei für den CrowdSec Bouncer für Traefik
- 7.3.5. .env-Datei für Traefik
- 7.3.6. API Key für den CrowdSec Bouncer für Traefik generieren
- 7.4. Traefik konfigurieren
- 7.4.1. Konfiguration der traefik.yml
- 7.4.2. Konfiguration von TLS
- 7.4.3. Konfiguration von http.middlewares.default.yml
- 7.4.4. Konfiguration von http.middlewares.traefik-dashboard-auth.yml
- 7.4.5. Passwort für Traefik-Dashboard festlegen
- 7.4.6. Konfiguration von http.middlewares.traefik-bouncer.yml
- 7.4.7. Integration des Bouncers in traefik.yml
- 7.5. CrowdSec konfigurieren
- 7.5.1. Acquisition anpassen
- 8. Dienst starten
- 8.1. Checkliste
- 9. Traefik-CrowdSec-Stack überprüfung
- 10. Optional
- 10.1. CrowdSec aktuell halten
- 10.2. Traefik-CrowdSec-Stack Update
- 10.3. Erweiterung der Firewall (UFW bzw. IPTables und NFTables) mit CrowdSec
- 10.3.1. Repository für CrowdSec Firewall Bouncer
- 10.3.2. Installation des Firewall Bouncers
- 10.3.3. Access Token generieren
- 10.3.4. Bouncer konfigurieren
- 10.3.5. CrowdSec Firewall Bouncer starten
- 10.3.6. Anzeigen der CrowdSec Bouncer-Liste
- 10.4. Logrotate für Traefik
- 10.5. Mailcow anpassen
- 11. Neuen Container hinzufügen
- 11.1. TLS anstelle von HTTP
- 99. Anleitung in 2 Minuten
- Hinweis zu Kommentaren
- Author: Psycho0verload
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 istroot
sowohl der Benutzer als auch der Gruppenbesitzer, und die Berechtigungen sind auf0644
gesetzt. Im Vorfeld habe ich mir mitls -all /var/log/traefik
angeschaut mit welcher Berechtigung die Datei geschrieben wird.postrotate
undendscript
: 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. Derdocker 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!
No Comment! Be the first one.