caddy 4all and everything https

Man kennt das ja – viele Docker Projekte strampeln sich einen ab wenn sie public und mit https laufen sollen – entweder komplizierte addons mit nginx etc. im docker-compose.yml oder nette Hinweise wie „wenn es public läuft kümmer Dich selber um einen reverse proxy“. Auftritt Caddy Docker Proxy von Lucas Lorentz (https://github.com/lucaslorentz/caddy-docker-proxy)

Die Idee ist caddy kümmert sich für jede Domain die auf Port 80/443 anlandet um SSL Zertifikate etc. pp. und die Projekte dahinter müssen nur das Netzwerk caddy joinen und ihre Spezialwünsche via Label mitteilen. Als Beispiel einmal ein voll funktionaler caddy reverse proxy via compose:

version: "3.7"services:  caddy:    image: lucaslorentz/caddy-docker-proxy:ci-alpine    ports:      - 80:80      - 443:443    environment:      - CADDY_INGRESS_NETWORKS=caddy    networks:      - caddy    volumes:      - /var/run/docker.sock:/var/run/docker.sock      - caddy_data:/data    restart: unless-stoppednetworks:  caddy:    external: truevolumes:  caddy_data: {}

wenn ich jetzt z.B. ein Ghost Blog betreiben und mit SSL absichern will brauche ich nur einen DNS namen a la „ghost.mydomain.com“ und ändere im docker-compose die Netzwerk Statements auf das Caddy Netzwerk.

Es ist nicht mehr nötig in den einzelnen Projekten Ports zu exposen da sie ja im Caddy Netzwerk erreichbar sind – Beispiel für ein ghost Blog:

version: "3"services:  ghost:    image: ghost:latest    environment:      url: https://blog.mydomain.com      database__client: sqlite3      database__connection__filename: "content/data/ghost.db"     volumes:      - ghost:/var/lib/ghost/content    restart: unless-stopped    labels:      caddy: blog.mydomain.com      caddy.reverse_proxy: "{{upstreams 2368}}"    networks:      - caddyvolumes:  ghost:networks:  caddy:    external: true

wichtig sind die zwei caddy label die einmal den Namen der Domain und damit des Zertifikates bestimmen und caddy noch sagen auf welchem Port der upstream ist (sofern er im container nicht auf 80 oder 443 stattfindet).

Ab hier muss man nichts mehr tun, beim ersten Zugriff auf den Domain-Namen via https erzeugt der caddy Container automatisch das LE Zertifikat und gibt die Requests danach an den Container weiter – und das funktioniert für alle Docker Projekte hinter diesem Caddy problemlos auch mit Spezialitäten (die man via Label dem proxy mitteilen kann.

Wie man ein „one-shot“ Seafile, awsome-ttrss oder nextcloud ohne Gefummel damit an den Start bringt folgt in späteren Blogs 🙂