Open edevosc2c opened 7 months ago
Could it be possible to use http and not https with it ? Is it configurable ?
It will be nice to have a solution to the SSL certificate issue, nice proposal. I'll try it ASAP (can't today).
I'm wondering if this one would justify a communication on the mailing list. A priori, this shouldn't matter a great deal to change the reverse-proxy technology. But maybe some people have the docker compo in production and would have some unforeseen impact.
Thanks for the proposal Emilien. Had not expected this and didn't know Caddy at all ;-)
"Caddy shines in its simplicity, automatic HTTPS, and intuitive configuration syntax, making it great for beginners and small to medium-sized projects. On the other hand, Traefik excels in its dynamic configuration capabilities, extensive plugin ecosystem, and strong community support, making it more suitable for larger and complex containerized environments." from https://stackshare.io/stackups/caddy-vs-traefik
Also saw a YT video showing Traefik outperformed Caddy in a test.
Apart from that, I'm a bit sad to see traefik go away. Loved it !
Also saw a YT video showing Traefik outperformed Caddy in a test.
I'm not sure we care about performance, for the docker-compose. It's not the advised production setup anyway
Apart from that, I'm a bit sad to see traefik go away. Loved it !
Will you really be missing the configuration ? I quite like Traefik, once configured, but hate the config part. More seriously, I had gotten used to it and I'm rather bothered by having to learn yet another similar tool. But if it can help solve the SSL certificate issue for local deployments, I'm in.
But... I'm thinking, if the aim is to generate self-signed certificate on startup, it should be fairly easy to replace the traefik-me-certificate-downloader service by a service that would auto-generate the certificates. And keep traefik. What do you think ?
I also believe it should be possible to simplify our configuration for traefik. It should be possible to get something simpler for the routing at least, I don't like the way we list all possible services, it doesn't match with Traefik phylosophy)
I want to remind everyone that I'm using a project built on top of caddy called https://github.com/lucaslorentz/caddy-docker-proxy. This project has existed for almost 6 years now and is here to stay: lucaslorentz/caddy-docker-proxy/releases?page=4.
But this is because I have wanted to keep the same ability to configure the web server from docker labels.
It may not be what we really want, maybe a simple file would be much better. We would just use the containers names for configuring where to send the requests to, that would work too.
I'm wondering about that because docker labels are not necessary the ideal way to configure a web server and can make the configuration more difficult to work with.
But... I'm thinking, if the aim is to generate self-signed certificate on startup, it should be fairly easy to replace the traefik-me-certificate-downloader service by a service that would auto-generate the certificates. And keep traefik. What do you think ?
Sure, but "one off" containers in docker has always been the source of confusion or problems, it's not supported by Docker.
You need to hack a logic to check that everything went well, otherwise the container will keep repeating the same actions once the full docker composition is restarted. Sometimes this hack doesn't work well, so the container keep doing the same actions over and over anyway.
I also believe it should be possible to simplify our configuration for traefik. It should be possible to get something simpler for the routing at least, I don't like the way we list all possible services, it doesn't match with Traefik phylosophy)
You can't really change how traefik was made, in my opinion the configuration is awful to work with.
But this is because I have wanted to keep the same ability to configure the web server from docker labels.
It may not be what we really want, maybe a simple file would be much better. We would just use the containers names for configuring where to send the requests to, that would work too.
I'm wondering about that because docker labels are not necessary the ideal way to configure a web server and can make the configuration more difficult to work with.
Indeed. In the end, how many services are configured behind the proxy ? Only security-proxy and static ? (What is the purpose of the static container BTW ? It looks like it has added a lot of extra complexity in the reverse-proxy config)
We are not really using the dynamic service discovery thing, actually, are we ? Static config could probably do the job
I had some time to tackle this PR again! I have taken into account the feedback.
public
path!/favicon.ico
, /crossdomain.xml
and /robots.txt
now works out of the box!.envs-common
and this gets propagated to every service including the web server.A
grade! If your client asks you to get compliant with the latest requirements for the TLS security, you can say to him that the job is already done!Please give me some feedback about these new changes. I'm confident that it's these were the remaining changes to greatly improve the docker composition of geOrchestra.
I was wondering if I should write a migration guide? A basic one for people that already have the docker composition for geOrchestra 23 with Traefik. Or if we don't care because we consider that this docker composition is for development only.
Thanks for this great contribution Emilien. It is indeed a clear improvement over the previous option.
CAn you please also remove the 2 traefik*.yml files in resources/ ?
Resources removed.
It seems like caddy trust does not work in Chrome. I have to check what's going on.
Or propose an alternative solution like how to trust the certificate generated by caddy. Or have a small script for that.
First test :
Firefox + Security proxy seems to work fine. As you said, it isn't working out of the box with Chrome when using ./caddy trust
so for me it's a no go.
As it's planned to be with geOrchestra 24, I think we can get rid of the old header. By default it's redirecting to it and t's a little bit confusing.
I'll do more tests with Gateway
Second test :
FF + Gateway : Some config needs to be updated, still can't login by now
Introduction
Traefik has been the source of multiple problems, #214 in particular, and is not a friendly web server to work with.
This pull request propose to switch from Traefik to Caddy webserver: https://caddyserver.com/
Caddy by itself is mature and has existed since 2015, the same year when Traefik launched.
Also, Caddy is so much simpler to work with, take a look at the documentation: https://caddyserver.com/docs/quick-starts/caddyfile
Benefits of this pull request
Overall: Way simpler docker-compose.yml and fewer services to run!
docker-compose.override.yml
file, overall easier maintainability. Caddy is so much simpler to configure than Traefik, take a look at their tutorial: https://caddyserver.com/docs/quick-starts/caddyfileThis drops the automatic traefik.me certificate component and uses a self-signed TLS certificate.
caddy trust
. It is documented through this PR. Fixes https://github.com/georchestra/docker/issues/219file_server
./favicon.ico
,/crossdomain.xml
and/robots.txt
works out of the box!.envs-common
and this gets propagated to every service including the web server.On ssllabs.com you get an
A
grade!What this pull request does not change
And there is no need to add complicated stuff in the Traefik for Let's Encrypt to be activated, Caddy will try Let's Encrypt out of the box.
(potential) downsides of this pull request
caddy trust
! It is documented in this PR.TODO (missing)