Reverse proxy

[Thechi2000]

We need to investigate which reverse proxy to use. Ideas:

• nginx
• Traefik
• Caddy

[Voxanimus]

I read some stuff about the 3 reverse proxy. It seems that caddy sounds to have very simple config file and handle automatically the certifications. As it's more like a server if we need to extend add functionality we won't had dependencies to other tools whereas traefik seems more inflexible.

[Thechi2000]

So I've been experimenting with Traefik, and here are my conclusions:
Pros:

• The use of labels on container is very dynamic
• The whole tool seems modular and powerful and could be great for future project on the server

Cons:

• The learning curve is very steep, I got a really hard time learning to setup even the most basic configuration, and I'm still stuck on simple problems
• I found the documentation hard to understand and it was not easy to find what I wanted
• Understanding the issues is not easy, as the logging (even in debug mode) is sparse
• It's not possible to reload the static configuration while the container is running, and restarting a docker swarm service is not something you should do

Overall, I think Traefik may be a bit too much for this server. We would loose much more time learning to use it and debug it than we would need to learn and setup other reverse proxies, like nginx.

I'm gonna have a look to Caddy this week-end

[mochiruntime]

Thank you for your research and valuable feedback! I agree, if the knowledge cost of Traefik is too high it's probably not worth it for our use case. I'm also curious about Caddy, since they market it as a very simple, low-config, production-ready reverse proxy. I'll be happy to read your opinion on it 👍

[Thechi2000]

I've tried a bit Caddy, and I'm not very happy. I've been struggling for the past 45 just trying to access the API when Caddy is in a container, and it's still not working.

The documentation sometimes has instructions about legacy behavior from Caddy 1, which makes it very annoying when you try to fix something and after 15 minutes you discover that environments variables are not used anymore (but the caddy executable still has an option to show them)

Furthermore, Caddy does not seem to be used in docker, a lot of things are done through the caddy command, thus requiring to be inside the docker (losing any other tools like vim or curl)

For now, I would suggest we use Nginx, as we are several to already have some experience with it. I will try to deploy it from a container on my setup. I might also give another try to Caddy in the meantime, if I have the time

[Thechi2000]

So I've tried Nginx inside a container, and there are no noticeable differences from the classic setup. I think we can go for this one

[mochiruntime]

Thank you for your work and your time! Sounds good to me, we can keep nginx as our reverse proxy for now.

[mochiruntime]

Bumping this thread, I've been using Caddy on my home lab and I really like its simplicity and sane defaults. In my opinion it would fit well with the "pit of success" approach we're trying to have in this project, I think it's more foolproof than e.g. nginx. For instance a Caddyfile can be as simple as:

clic.epfl.ch {
     reverse_proxy <container_name>:<port>
}

and SSL would be handled automatically by Let's Encrypt. Adding a certificate file is super easy as well:

clic.epfl.ch {
    tls cert.pem key.pem
    reverse_proxy <container_name>:<port>
}

I will add a working example to the repo in a PR