Caddy als Reverse Proxy für Docker Compose Container
Heute beschreibe ich was ein Reverse Proxy ist und warum er in deiner Docker Landschaft nicht fehlen darf. Nachdem ich mehrere Jahre lang sowohl Traefik, als auch den Nginx Proxy Manager als Reverse Proxy für meine Docker Container genutzt habe, bin ich nun bei Caddy gelandet. Am Nginx Proxy Manager störte mich, dass zur Konfiguration ausschließlich die Web UI zur Verfügung steht. Das hat mich in Backup/Restore Szenarien öfter an die Grenzen gebracht, was zum Schluss dazu führte jedes Mal aufs neue eine Klickorgie zu veranstalten. An Traefik störte mich wiederum die aufgeblähte Konfiguration, sowie die vielen Labels die an jedem zu berücksichtigenden Container ergänzt werden müssen. Caddy bietet mit einer CLI und einer API, die gewünschte Flexibilität und lässt sich auch einfach sichern/wiederherstellen.
Warum ein Reverse Proxy für Docker Container?
Die Nutzung eines sogenannten Reverse Proxies für die eigene (Docker) Container Landschaft soll zum einen Flexibilität als zum anderen auch erhöhte Sicherheit bieten. Das (virtuelle) Netzwerk der Container wird in verschiedene Zonen aufgeteilt, so dass z.B. Datenbankinstanzen nicht direkt aus dem Internet erreichbar sind. Auch können so z.B. mehrere WordPress Installationen parallel betrieben werden, ohne dass sie sich irgendwie in die „Quere“ kommen. Beides wird in folgender Darstellung illustriert:
Außerdem soll der Zugriff auf die selbst gehosteten Webseiten auschließlich über das verschlüsselte HTTPS Protokoll funktionieren. Die dafür benötigten Zertifikate verwaltet und aktualisiert eine moderne Rerverse Proxy Lösung für uns voll automatisch.
Wie installiere und betreibe ich Caddy als Reverse Proxy?
Zunächst richten wir und ein dediziertes Netzwerk für Caddy und die Container die öffentlich erreichbar
sein sollen unter einem gewünschten Namen (hier „Caddy“) mit folgendem Befehl ein: docker network create caddy .
Diesen Namen siehst nur du in deinen Konfigurationsdateien und in Docker.
Caddy selbst stellen wir ebenfalls über einen Docker Container zur Verfügung, auf dem wir die Ports 80 und 443 exponieren. Eine mögliche Docker Compose Datei „compose.yml“ dazu kann so aussehen:
1services:
2 caddy:
3 container_name: caddy
4 image: caddy:latest
5 restart: unless-stopped
6 ports:
7 - "80:80"
8 - "443:443"
9 - "443:443/udp"
10 volumes:
11 - ./Caddyfile:/etc/caddy/Caddyfile
12 - ./site:/srv
13 - ./caddy_data:/data
14 - ./caddy_config:/config
15 logging:
16 options:
17 max-size: "10m"
18 max-file: "3"
19 networks:
20 - caddy
21volumes:
22 caddy_data:
23 caddy_config:
24networks:
25 caddy:
26 external: true
Bevor wir den Container starten, legen wir im gleichen Verzeichnis eine Datei „Caddyfile“ an. Diese musst du auf deine Bedürfnisse anpassen und orientiert sich hier am oben gezeigten Beispiel:
1{
2 # TLS Options
3 email deine.email@provider.com
4}
5
6(wordpress) {
7 header {
8 Cache-Control "public, max-age=3600, must-revalidate"
9 }
10}
11
12quickscot.de, www.quickscot.de {
13 import wordpress
14 reverse_proxy wordpresscontainer1:80
15}
16
17niklas-stephan.de, www.niklas-stephan.de {
18 import wordpress
19 reverse_proxy wordpresscontainer3:80
20}
Nun können wir den Container mit folgendem Befehl starten: docker compose up -d.
Falls irgendetwas nicht funktioniert hilft eine Überprüfung der Logdatei mit: docker compose logs .
Bei Problemen hilft auch ein Blick in die Caddy Community, die viele Problembehandlungen und Konfigurationsbeispiele bereitstellt: https://caddy.community/.
Falls ihr Änderungen/Ergänzungen an dem Caddyfile vornehmt müsst ihr nicht jedes Mal den kompletten Container durchstarten und könnt so Dowtimes durch folgenden Befehl, der die Konfiguration live neu läd, aktualisieren:
1docker compose exec -w /etc/caddy caddy caddy reload
Nun gilt es noch unsere Applikationen im Caddy Netzwerk sichtbar zu machen. Hier ein Beispiel einer WordPress Installation in der der Applikationsserver von Caddy aus erreicht werden kann, aber nicht der Datenbankserver:
1services:
2 wordpresscontainer1:
3 container_name: wordpresscontainer1
4 depends_on:
5 - wordpresscontainer1-db
6 image: wordpress:latest
7 logging:
8 options:
9 max-size: "10m"
10 max-file: "3"
11 volumes:
12 - ./data:/var/www/html
13 - /etc/localtime:/etc/localtime:ro
14 restart: unless-stopped
15 environment:
16 WORDPRESS_DB_HOST: wordpresscontainer1-db:3306
17 WORDPRESS_DB_USER: EUERUSER
18 WORDPRESS_DB_PASSWORD: EUERSUPERPASSWORT
19 networks:
20 - default
21 - caddy
22 wordpresscontainer1-db:
23 container_name: wordpresscontainer1-db
24 image: mysql:5.7
25 logging:
26 options:
27 max-size: "10m"
28 max-file: "3"
29 volumes:
30 - ./db:/var/lib/mysql
31 restart: unless-stopped
32 environment:
33 MYSQL_ROOT_PASSWORD: ROOTSUPERPASSWORT
34 MYSQL_DATABASE: wordpress
35 MYSQL_USER: EUERUSER
36 MYSQL_PASSWORD: EUERSUPERPASSWORT
37 networks:
38 - default
39volumes:
40 data:
41 db:
42networks:
43 caddy:
44 external: true
Fazit
Bis jetzt ist Caddy genau der Kompromiss nach dem ich suchte. Die Konfiguration über eine einzelne Datei lässt sich super einfach sichern und bei Bedarf wiederherstellen. Bei Wunsch nach mehr, stellt Caddy alternativ auch die Konfiguration über eine API als Option bereit. Ein Blick in die technische Dokumentation unter https://caddyserver.com/docs/ offenbart, dass Caddy auch noch viel mehr kann als das gezeigte. Noch nicht herausgefunden habe ich, ob ich ähnlich wie bei Traefik auch zusätzliche Module/Plugins wie Crowdsec, für eine erweiterte Sicherheit aktivieren kann. Generell würde ich nie wieder zurück zum Nginx Proxy Manager wechseln, halte aber Traefik bei komplizierteren Szenarien, evtl. für die bessere Wahl. Für den Hobby Fullstack Entwickler wie mich, ist Caddy aber erstmal eine beinah rundum glücklich Lösung.
Update 12.03.2025
Ich nutze immernoch Caddy und bin nach wie vor absolut damit zufrieden. Ein wechsel z.B. zu Traefik ist auch nach vielen Monaten nicht nötig.