Closed fbartels closed 3 weeks ago
Not at the moment. seelf assumes it has to manage services exposure to prevent name conflicts across targets and make the local -> remote transition almost transparent. However, having an nginx service on a specific stack is totally feasible right now. It will receive all traffic from <app name>.<target url>
forwarded by traefik. Maybe I should make an example about such stack.
I'm curious and would like to know more about your use case thought.
Anyway, thanks for your feedback ☺️
Yes, I can understand that reasoning.
Maybe I am old school by wanting to manually configure my Reverse Proxy. My use case would an existing deployment that I just want to enhance by automating its updates. Say you are running something like https://github.com/nextcloud/all-in-one/blob/main/compose.yaml, which comes with a reverse proxy configured.
https://github.com/nextcloud/all-in-one/blob/main/compose.yaml
@YuukanOO would it be complicated to disable the Traefik part? My use case is that I use tailscale with magic dns and I don't have (and want) an actual FQDN.
I guess it could also work with http://app.docker.localhost
I'd also be interested in running seelf without Traefik, since I'm currrently using nginx-proxy
It would be feasible, maybe with a toggle on the target side, something like Configure the proxy manually but in this case, you will be in charge for everything.
If the proxy is not handled by seelf, services should still join a network
shared with the proxy but how should it be configured? Should it be seelf's responsibility or every compose
file deployed should contains a reference to the network
?
IMO if you choose to configure manually seelf should no longer care, no more joining the docker network, you are on your own.
When opting for a manual configuration, I guess the target's url
is no longer necessary since seelf doesn't know where services are made available.
I will get back working on seelf next month so stay tuned!
I'm almost done on it (need more unit tests + docs) but I didn't have that much time this week to do a pre-release.
If you really want to try it out, you can with:
git clone -b feat/manual-proxy-configuration https://github.com/YuukanOO/seelf
cd seelf
make build
./seelf serve
Or wait for next week :)
:tada: This issue has been resolved in version 2.4.0-next.1 :tada:
The release is available on:
v2.4.0-next.1
Your semantic-release bot :package::rocket:
A pre-release version has been published!
You can easily test it locally with:
docker run -d --rm \
-e "ADMIN_EMAIL=admin@example.com" \
-e "ADMIN_PASSWORD=admin" \
-v "/var/run/docker.sock:/var/run/docker.sock" \
-p "8080:8080" \
yuukanoo/seelf:next
Let me know if it works for you :)
:tada: This issue has been resolved in version 2.4.0 :tada:
The release is available on:
v2.4.0
Your semantic-release bot :package::rocket:
Hi, I found your project on Reddit and like the idea.
I have a few stacks that are already managing their their reverse proxy/ingress. Is there a possibility to not start traefik and instead have the deployed stack manage their own exposure?