Simple Caddyfile example map microservice name to port

1. Caddy version (caddy version):

2.4.6

2. How I run Caddy:

docker compose

a. System environment:

ubuntu 2004, docker

b. Command:

command: [ "caddy", "run", "--config", "/config/Caddyfile" ]

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

mydomain.io {
handle_path /microserviceA/* {
reverse_proxy localhost:8080
}
handle_path /microserviceB/* {
reverse_proxy localhost:8081
}
handle_path /microserviceC/* {
reverse_proxy localhost:8082
}
}

3. The problem I’m having:

Try to find a valid configuration example for Caddyfile for a simple common scenario.

4. Error messages and/or full log output:

ssl error/ timeout

5. What I already tried:

I have a very easy container group, like:
microserviceA → accessible via container port 8080
microserviceB → accessible via container port 8081
microserviceC → accessible via container port 8082

Now, I want to serve these microservices with automatic https and port mapping for the microservices/name using a Caddyfile.

For example, when someone calls the URL mydomain.io
caddy should resolves the right port to the docker container, which will be localhost:8080 in this example.

I’ve tried something like:

mydomain.io {
handle_path /microserviceA/* {
reverse_proxy localhost:8080
}
handle_path /microserviceB/* {
reverse_proxy localhost:8081
}
handle_path /microserviceC/* {
reverse_proxy localhost:8082
}
}

and I tried:

mydomain.io {
reverse_proxy /microserviceA/* localhost:8080
reverse_proxy /microserviceB/* localhost:8081
reverse_proxy /microserviceC/* localhost:8082
}

What’s wrong with that?
Can somebody please give an example of a valid Caddyfile for this easy scenario?

6. Links to relevant resources:

Well, you haven’t told us what’s not working. What symptoms are you seeing? What’s in your logs? What kinds of errors? What do you see in Caddy’s logs? Please be as detailed as possible.

For your microservices, do you need that path prefix to be kept when the request is proxied, or do you need it to be stripped? That’s the main difference between the two you posted, using handle_path will remove that matched path segment from the start of the URL before proxying, whereas just using a matcher on reverse_proxy will not strip the path.

Keep in mind that if these microservices aren’t under your control, you might need to use subdomains for each of them instead of subpaths. See this article which explains why:

1 Like

What do you mean with “from the start of the URL”? Must I use a subdomain?

Yes, I want to remove the matching path, so I’m using the caddyfile-configuration from described in d.

I want to point internally to “localhost:8082/swagger/index.html” for example when
https://mydomain.io/microserviceC/swagger/index.html
is called.

But what I get is a HTTP ERROR 404 - not found

The log on my caddy-container says:

{"level":"info","ts":1641309213.7765582,"msg":"using provided configuration","config_file":"/config/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1641309213.7810256,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
{"level":"info","ts":1641309213.782977,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000222620"}
{"level":"info","ts":1641309213.7840042,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1641309213.784042,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1641309213.7860777,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
{"level":"info","ts":1641309213.7862577,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["mydomain.io"]}
{"level":"info","ts":1641309214.0090578,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1641309214.0709708,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1641309214.0710132,"msg":"serving initial configuration"}

In that case you do need handle_path, since you want the path prefix to be stripped (i.e. /microserviceC to be removed from the start of the request path)

That’s just the startup logs, there’s no errors there.

The 404 must be coming from your upstream app. You’ll need to dig into that app and see why it’s responding with a 404.

you are right - it seems to be an error with my swagger configuration

Thank you very much Francis!

1 Like

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