I’m running Caddy as a reverse proxy right now. I run caddy as a docker container and so far, I’ve been able to achieve browsing to host.mydomain.com which resolves to a docker app running on one of my hosts - YAY!
Now I’m trying to add nextcloud into the mix. Actually, making nextcloud work behind a rev proxy is the whole reason I came to caddy, so cheers! I found this entry in the wiki and read it through. I’m pretty confused on a couple points though, and I’d love a walkthrough.
First, For my caddy docker compose, I have “80:80” and “443:443” which makes complete and total sense. However, for the caddy portion of the docker-compose in the wiki, it specifies under the ports section “8080:80” - why?
Second question concerns the wiki example’s caddyfile. The file begins with:
:80 {
Do I just append the entire caddyfile example to my caddyfile? My current caddyfile looks like this:
Again, my whole reason for coming to caddy was about nextcloud. Now that I’ve seen how dead-simple caddy is, I’m hooked. I do however need to understand this example better because once I have nextcloud up and running, I’ll want to add collabora to it and that’s where I got hung up with HAproxy.
There’s two different ways to run nextcloud. Either, you can use their nextcloud-apache image, which comes with a webserver bundled, or you can use their nextcloud-fpm image, which requires a server that can talk to it over fastcgi.
Both are things Caddy can do, but the approach with using the nextcloud-apache image is simpler to set up, because you simply need to reverse_proxy to the container and that’s about it.
The php-fpm approach requires also mounting the volume where the nextcloud code is stored to the Caddy image so that Caddy can serve nextcloud’s static files, and also detect which files are PHP scripts that it needs to run. This is what that wiki describes how to set up.
Both are valid and have pros and cons (I think the fpm approach may be faster because it cuts out apache as a middle-man, but the apache approach is simpler).
The wiki example is using 8080:80 as a “if you only need to use this locally” kind of solution, i.e. without a domain or TLS. Since you want to serve it on a domain, you’re already doing the right thing with 80:80 and 443:443.
The primary reason was to match the Docker Hub example as closely as possible.
8080:80 means that port 80 in the container is being forwarded to port 8080 on the host machine. If no other application is using port 80, then it’s okay to use 80:80. So why remap?
Let’s say you have two containers that use port 80 internally. Both can’t be forwarded to port 80 on the host machine. In this case, you need to remap at least one of those ports on to a different port on the host machine e.g. 8080:80 for one of the containers. Best practice is to avoid using low-order, well known ports on the host machine, which the host machine might want to utilise. Personally, I would remap both container ports to higher-order ports on the host e.g. 8080:80 and 8081:80.
I think what’s causing the confusion is not realising that there are actually two Caddy instances running, each with their own Caddyfile (at least that’s how I run it) - Caddy as a webserver to serve php files from the Nextcloud FPM instance, and Caddy running separately as a reverse proxy. The schematic in Case study: Variations in Caddyfile design for different Nextcloud builds will help you visualise what’s going on.
What is the impact of port remapping for Caddyfile on the reverse proxy?
If you were not remapping to a different host port in the compose file, your reverse proxy entry might be:
cloud.mydomain.com {
reverse_proxy http://192.168.1.205 # Port 80 implied
}
If you had remapped port 80 in the container to port 8080 on the host, your reverse proxy entry would instead look like:
Thanks for the input. So, I read about the two versions of Nextcloud, and since the apache version has apache built in -a web server- I thought I had to use the other one since Caddy IS a web server. So what you’re saying is that I can run either of the two versions, but the fpm image is more streamlined for my use case - understood. I’ll digest this tonight as I play with this. Thank you again.
Thank you for this write up. So I am completely understanding the port mapping portion of what you described. On the next part, are you saying you run two separate caddy docker containers?
That’s correct. The diagram in the wiki article Using Caddy as a reverse proxy in a home network will also help you visualise this. In the diagram, you’ll see a Caddy instance running as a reverse proxy. Behind it are a number of services. So, for example, Service A might be Nextcloud-FPM fronted with a Caddy webserver and service B might be Nextcloud fronted with an Apache webserver.