I need help to convert this caddy v1 to v2

1. My Caddy version (caddy version):

2. How I run Caddy:

a. System environment:

b. Command:

It should support automatically generating a LetsEncrypt for the generated Azure domain name. This is the current part of the docker-compose.yml that pertains to Caddy that would need to be updated as well.

caddy:
image: abiosoft/caddy
restart: unless-stopped
depends_on:
- api
- web
- guide
ports:
- "80:80"
- "443:443"
command: -default-sni HOST_IP -conf /etc/Caddyfile
volumes:
- ./Caddyfile:/etc/Caddyfile
- ./volumes/caddy:/root/.caddy
- ./keys:/root/keys

c. Service/unit/compose file:

paste full file contents here

d. My complete Caddyfile or JSON config:

:80 {
    redir https://{host}{uri}
}
:443, https://HOST_IP {
    tls /root/keys/wildcard.crt /root/keys/wildcard.key
    proxy / web:80 {
        except /blob /graphql /kibana
    }
	proxy /blob api:9000
    proxy /graphql api:9000
    proxy /kibana api:9000
}
https://HOST_IP {
    tls /root/keys/wildcard.crt /root/keys/wildcard.key
    proxy / guide:80
}

3. The problem I’m having:

I was using version 1, so I need version 2 and I don’t know much about caddy

Welcome!

How far does this upgrade guide get you? Upgrading to Caddy 2 — Caddy Documentation

Thanks matt for your warmth welcoming, I’m great to be part of this community, and I would like to learn more about caddy, maybe this is the best opportunity that I have… I have gone through the guide, but I would like someone to take a look about my conversion of caddyfile v1 to v2 and tell me what am doing wrong.

Caddyfile V1

:80 {
redir https://{host}{uri}
}
:443, https://HOST_IP {
tls /root/keys/wildcard.crt /root/keys/wildcard.key
proxy / web:80 {
except /blob /graphql /kibana
}
proxy /blob api:9000
proxy /graphql api:9000
proxy /kibana api:9000
}
https://HOST_IP {
tls /root/keys/wildcard.crt /root/keys/wildcard.key
proxy / guide:80
}

Caddyfile V2
:80 {
redir https://{host}{uri}
}
:443, https://HOST_IP {
tls root*/keys/wildcard.crt root*/keys/wildcard.key
reverse_proxy / web:80 {
file_server /blob/* file_server /graphql/* file_server /kibana/*
}
reverse_proxy /blob/ api localhost:9000
reverse_proxy /graphql/ api localhost:9000
reverse_proxy /kibana/ api localhost:9000
}
https://HOST_IP {
tls root*/keys/wildcard.crt root*/keys/wildcard.key
reverse_proxy / guide:80
}

Please assist me in learning is this

Hi @larious4luv,

Firstly, you’ve got two separate sites with the site label https://HOST_IP. This won’t work, so strictly speaking neither of your given Caddyfiles (v1 or v2-attempted) are functional.

Following up on the v2 attempt:

I’m not sure why you removed the leading slash and added asterisks, these are not necessary for tls syntax. For your use case tls is identical from v1 to v2.

tls (Caddyfile directive) — Caddy Documentation

There is no file_server subdirective for reverse_proxy, and you can’t chain subdirectives on one line in this manner. The equivalent in your v1 Caddyfile is to except those paths, but that’s not actually how its done and it’s not even necessary at all, as far as I know.

reverse_proxy (Caddyfile directive) — Caddy Documentation

Each of these need to be wildcard-suffixed or they’ll be treated as exact paths, i.e. the first will reverse proxy requests to /blob/ but not /blob/foo.

api here appears to be the hostname that resolves to the API, going off your v1 Caddyfile. This doesn’t need to change and you don’t need to introduce localhost. Just use api:9000 like you did in v1.

Same issue here as above, this will reverse proxy literally / but not e.g. /foo.

You can change the path matcher to *, or remove it entirely.


Here’s my untested take on your Caddyfile:

:80 {
  redir https://{host}{uri}
}

:443, https://HOST_IP_1 {
  tls /root/keys/wildcard.crt /root/keys/wildcard.key
  reverse_proxy web:80
  reverse_proxy /blob* api:9000
  reverse_proxy /graphql* api:9000
  reverse_proxy /kibana* api:9000
}

https://HOST_IP_2 {
  tls /root/keys/wildcard.crt /root/keys/wildcard.key
  reverse_proxy guide:80
}

I have renamed your https://HOST_IP to two separate labels here as, again, they won’t work if you try to define two different sites with the same site label.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.