search

YuukanOO / seelf

Lightweight self-hosted deployment platform written in Go
https://yuukanoo.github.io/seelf/
GNU General Public License v3.0
214 stars 7 forks source link

Ability to run without Traefik? #58

Closed fbartels closed 1 month ago

fbartels commented 7 months ago

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?

YuukanOO commented 7 months 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 ☺️

fbartels commented 7 months ago

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

cretudorin commented 4 months ago

@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

1fexd commented 3 months ago

I'd also be interested in running seelf without Traefik, since I'm currrently using nginx-proxy

YuukanOO commented 3 months ago

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?

cretudorin commented 3 months ago

IMO if you choose to configure manually seelf should no longer care, no more joining the docker network, you are on your own.

YuukanOO commented 3 months ago

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!

YuukanOO commented 2 months ago

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 :)

YuukanOO commented 2 months ago

:tada: This issue has been resolved in version 2.4.0-next.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

YuukanOO commented 2 months ago

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 :)

YuukanOO commented 1 month ago

:tada: This issue has been resolved in version 2.4.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: