Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated reverse proxy #225

Open
yajo opened this issue Nov 24, 2020 · 12 comments
Open

Automated reverse proxy #225

yajo opened this issue Nov 24, 2020 · 12 comments

Comments

@yajo
Copy link

yajo commented Nov 24, 2020

Hello! I love Yacht. I can see that it inherits some concepts from Portainer (actually it can use its templates), but sadly that seems to mean it's inheriting its flaws (or otherwise I haven't seen it so far). Essentially, that Portainer is an app for managing docker containers, while what the world needs is a framework to manage server-side apps. And one app is not only a container, and also it is not just a set of containers.

I think that the main point that would make Yacht simply rock and beat any other alternative out there would be out-of-the-box support for:

  1. Reverse proxy. See https://traefik.io/, which is FLOSS, connects to the docker socket, reads container labels and routes incoming TCP/HTTP/HTTPS requests.
  2. With HTTPS. Traefik can be configured to automatically download and renew certs from https://letsencrypt.org/
  3. With SSO. https://www.authelia.com/ can be used as a middleware on top of Traefik to handle both auth and 2FA.

(Notice that the specific choices are just suggested... alternatives are perfectly valid).

I invite you to have a look at https://caprover.com/ just to draw some inspiration. When deploying an app, you are asked whether you want to open its port as HTTP and/or HTTPS, and it automatically wires it to its internal nginx+certbot. See https://youtu.be/VPHEXPfsvyQ?t=321 for a quick overview.

If these 3 points are covered, then when the user deploys a new app:

  1. It can be optimized (you know, multiport apps, caching, websockets and all that stuff can be only properly achieved when using a properly configured inverse proxy).
  2. It can be secure (HTTPS is essential).
  3. It can be integrated (having a common SSO for all apps is the selfhoster nirvana, and possibly one of the main reasons why many people still prefer https://yunohost.org/ and similar).
@SelfhostedPro
Copy link
Owner

I definitely intend on building out automatons like this once Yacht is feature complete (as far as container management goes or seeing about building out a plugin framework so that users can build their own automatons (Would really prefer to go this way but I'll have to see how difficult it is).

I'll leave this open and once https://github.com/SelfhostedPro/Yacht/projects/3 is done I'll comment here with my thoughts and progress.

@ksurl
Copy link

ksurl commented Nov 27, 2020

I have created a yacht config for linuxserver/swag as a subdomain config.
https://github.com/linuxserver/reverse-proxy-confs/blob/master/yacht.subdomain.conf.sample

works pretty well. I think it's nicer to keep all https setup in one place than have to configure per container/app. you can choose not to expose the port and keep the 8000 port on the internal docker subnet. only containers on the same network should be able to access it.

@SelfhostedPro
Copy link
Owner

Yeah, so the idea is that with traefik any app you deploy can be configured with SSL at the click of a button. If you check out my redcloud repo, you can see how this would work if the user did this with templates.

I think this is more for having this setup through the yacht UI rather than the user needing to manually do it.

@yajo
Copy link
Author

yajo commented Nov 28, 2020

I think this is more for having this setup through the yacht UI rather than the user needing to manually do it.

Yes, that's it. I know you can do it today with just docker labels if deploying a Traefik service for example, but it's not user friendly.

However I'm thinking now if it would be better to just have a templates repo where this is supplied out of the box, so you just use Yacht to deploy from that repo, and then apps get working securly out of the box. 🤔

@SelfhostedPro
Copy link
Owner

I currently do manage a popular template repo so I could put that together. Do you think that would be better than a button in settings to deploy traefik and automatically forward ports (with a checkbox in the deploy form for each port you want accessible)?

@yajo
Copy link
Author

yajo commented Nov 28, 2020

I guess it would be easier to implement, not better. Possibly some integrated UI would be really better.

@ksurl
Copy link

ksurl commented Nov 28, 2020

I think a default template is better with maybe a note in documentation mentioning it. Less opinionated so anyone who wants to roll their own can

@SelfhostedPro
Copy link
Owner

Well, there's the recommended template which I manage. I'll look into getting a template for traefik together and adding labels to everything.

@yajo
Copy link
Author

yajo commented Nov 28, 2020

That'd be great!

@yajo
Copy link
Author

yajo commented Nov 28, 2020

Maybe you can try with a couple of services and we see how it goes.

@SelfhostedPro
Copy link
Owner

I'm going to go ahead and move this issue over to the template repo as it's related to that now. Still learning traefik v2.

@SelfhostedPro SelfhostedPro transferred this issue from SelfhostedPro/Yacht Feb 19, 2021
@doc4child
Copy link

The other option may be nginx proxy server and possibility of generating automated workflow for hosting websites with real domain names as described here

https://blog.ssdnodes.com/blog/host-multiple-ssl-websites-docker-nginx/

This should allow following variables defined in docker-compose and which inturn sets up nginx proxy.

expose:
  - 80
environment:
  VIRTUAL_HOST: app.example.com
  LETSENCRYPT_HOST: app.example.com
  LETSENCRYPT_EMAIL: foo@example.com

Hopefully this can be included as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants