mijolabs / tailscale-caddy-docker

Secure access to Vaultwarden and other self-hosted containerized services with Tailscale and Caddy.
8 stars 0 forks source link

Caddy reverse proxy not working #2

Closed czar-labs closed 6 months ago

czar-labs commented 6 months ago

Hello, first of all many thanks for the tutorial, it perfectly fits my condition where I would like to have reverse proxy without exposing the port.

I am a bit new to docker containers and I have followed your tutorial, without Tailscale docker since I already have it running. However, still it does not work for me. Could you please help?

Below are my configurations

1. Cloudflare API Token

2. Caddy Configuration

.env file


# Cloudflare API token should be scoped:
# - Zone.Zone: Read
# - Zone.DNS: Edit
CF_API_TOKEN="PnBBlb**HIDDEN**A6KaCt"

docker-compose.yml file


services:
  docker-proxy:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: caddy
    restart: unless-stopped
    env_file: .env
    ports:
      - 80:80
      - 443:443
    networks:
      - caddy-network
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/data/caddy
      - ./config:/config/caddy
    deploy:
      labels:
        caddy.email: "HIDDEN@gmail.com"
        caddy: "*.HIDDEN.my.id"
        caddy.tls.dns: "cloudflare $CF_API_TOKEN"

volumes:
  data: {}

networks:
  caddy-network:
    external: true

Dockerfile file ->did not change anything


FROM --platform=linux/arm64/v8 caddy:builder-alpine AS builder

RUN xcaddy build \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/caddy-dns/cloudflare

FROM caddy:alpine

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

CMD ["caddy", "docker-proxy"]

3. Gitea Configuration


services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    restart: always
    environment:
      - USER_UID=1000
      - USER_GID=1000
    networks:
      - caddy-network
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    labels:
      caddy: "*.HIDDEN.my.id"
      caddy.2_handle: "@gitea"
      caddy.2_@gitea: "host git.HIDDEN.my.id"
      caddy.2_handle.reverse_proxy: "{{upstreams 3000}}"
      caddy_2_handle.reverse_proxy_0: "{{upstreams 2222}}"

networks:
  caddy-network:
    external: true
  1. Local DNS on Pihole I have put wildcard address in my pihole.

I expect I can access gitea from git.HIDDEN.my.id. But can't access it Many thanks for your support

czar-labs commented 6 months ago

Hello, I got it working with your method.

I have question, your method is using labels inside the containers, not using Caddyfile. How do you manage reverse proxy for other host? for example proxmox, or jellyfin that runs in baremetal that have dedicated IP Address?

mijolabs commented 6 months ago

Hi there, glad you got it working.

As you saw in my setup I have a wildcard DNS for my domain (*.mydomain.com), i.e. my self-hosted Caddy instance is the default host for my domain. Then as my guide shows we can just specify any subdomains for each service using docker-compose.yml files, and caddy-docker-proxy will reverse-proxy to that service. This is a nice and simple way to manage it.

But configuring the setup to route to a different host isn't straight-forward. I remember looking into it and decided it was more simple to just create a separate DNS entry in Cloudflare for any specific subdomain that I want routed to a different host. So accessing different-host.mydomain.com will go to that other host, while any other subdomain will fall under the wildcard DNS entry that is managed by caddy-docker-proxy. I think this is a fairly simple workaround that is still manageable.

However, I would prefer to manage the entire setup in one same place with Caddy instead of having some parts outsourced to the Cloudflare dashboard. But as mentioned if I remember correctly it wasn't so straight-forward, or it might've not even have been possible. I don't remember if the limitation was with Caddy or due to the caddy-docker-proxy setup being used. Maybe this has changed since I last checked though, so please let me know if you figure something out.