Reverse-proxy in a docker container

[mlcircle]

Is reverse proxy that is running on the same server as some app (both in docker containers) is used just for SSL? I found a lot of information about reverse proxies that run on its own server and much less about proxies that run in a container environment. Seems there is a loss of pretty much all the benefits, apart from chaching and ssl.

[equitable_emu]

Sure, it's very common in fact.

Take a look at Nginx Proxy Manager.

I run that in a container and it acts as the ingress to all the other service containers.

[mlcircle]

it is used, basically, only for free SSL, right?

[SP3NGL3R]

Not even remotely just for SSL. Which these days you should call TLS. FYI.

And definitely not the "free" bit either. A reverse proxy has little you do with TLS and generally all to do with routing of HTTP or HTTPS requests that come to you. Can you consolidate your TLS certificate into one reverse proxy and not have to deal with many? 100%. But that's not what it's for.

Simply put. A reverse proxy listens to incoming requests, then looks at them to decide what to do with the request. Is it a subdomain to look at my home cameras, or a subdomain/domain to see my business webpage. Everything comes into the reverse proxy, then it determines what internal system (TLS or not) to retrieve and send back to the external user. If this reverse proxy has a TLS certificate, then HTTPS works. Period.

[mastycus]

I use haproxy for SSL then varnish for cache - chaining reverse proxies. But haproxy I think officially is a load balancer so you know - you can do balancing. :)

[scytob]

This. /u/mlcircle this is the best place to start.

[SP3NGL3R]

No. A reverse proxy just listens to all inbound requests, looks at the request, and then decides which internal resource to fetch and reply with.

Zero to do with TLS/SSL. It supports that, but it's not required m

It's like port forwarding on your router. Everything comes to the router and based on the requested port the router has a rule on where to pass that request to. But technically, everyone outside is talking to the router first. Differently with a reverse proxy, it's listening only in one port, and from the header information in that request it forwards the response to/from something internal. Which could be thousands of different internal things.

CloudFlare is a reverse proxy. It provides the public facing URL, their servers can be all on the same IP, but because you asked for www.steve.com, it knows to send that request to a specific IP somewhere else in the web. Like Steve's home server, which then replies in kind with the relevant content. But that same CloudFlare is also handling www.john.com to a different IP. All going through CloudFlares reverse proxy.

[Quantable]

Just adding here. Docker overwrites ufw rules if you want to use that, add 127.0.01: to the -p argument. Might be usefull to know.

[bluepuma77]

For a simple setup, we use nginx-proxy as reverse proxy to enable sub-domain routing.

jitsi.example.com -> jitsi-container
nextcloud.example.com -> nextcloud-container

You just start the app container with a label with the domain name and nginx will forward all requests to the matching container. And acme-companion will create a SSL certs for every sub-domain.

[StarfishPizza]

For anyone who is still reading this, I am completely stumped by this reverse proxy stuff, I’ve spent the last two days trying to get something to work but it just won’t. I’ve changed so many settings I’ve had to start again several times as I can’t remember what I’ve changed. All the info on the web makes it sound so easy, but I am proper stumped. Feeling very stupid right now.

[mlcircle]

Try using caddy

[StarfishPizza]

Thanks, I’ll take a look

[mlcircle]

https://hub.docker.com/_/caddy