DietPi-Software | Reverse proxy integration for web applications

[Gill-Bates]

Hey there,

I am using many Services on my Raspberry and have already a Zoo of different Ports that I need to use for a particular service.

To get rid of it, I did following:

• Installing nginx
• Setup nginx as a ReverseProxy
• Installl ufw and allow only inbound Traffic on Port 443, 80, 22
• Adding a record to my /etc/hosts file (using dietpi as local DNS-Resolver)

Now I can easily access:

http://adguard.lan.local
http://portainer.lan.local
etc... 

without struggeling with Ports. And I have secured my Installation. What do you think to make this Standard for Dietpi?

Example Config for nginx:

# docker.lan.local / Portainer
server {
        server_name ocker.lan.local;
        listen 80;
        listen [::]:80;

        location / {
            # Reverse Proxy
            proxy_pass http://127.0.0.1:9002;
            index index.html index.htm index.php;
            autoindex off;
        }
}

[Joulinar]

Basically this could be done with other web server as well. We might think on a documentation page on our online docs on how to setup a reverse proxy, rather than creating this as software option.

[MichaIng]

Generally I think it would be nice indeed to have some GUI wise reverse proxy setup. But I'm not sure whether this makes sense within dietpi-software or whether er should create an own script for this, like dietpi-proxy or so 😄.

What could be done is detecting installed web servers, load balancers (HAProxy) and other proxies, or allowing to install one if not available yet. Then detecting web applications with internal web server, respectively TCP or UNIX socket listener. Then allow to enable/disable a reverse proxy on a choosable URL path (does does not exist on the actual filesystem yet) for each web application. This would safe users quite same hassle I guess, especially when otherwise guides are followed to install dedicated proxy servers, even with a whole Docker daemon and container around, while a webserver is present already (also conflicting on the port) or lightweight and fast HAProxy is the much better alternative on a low RAM SBC.

[Joulinar]

this could be quite complex. Each software require a different proxy configuration, probably. We might need to keep templates for each software title individually. And this for all available proxy software/ web server.

[MichaIng]

Indeed, we'll likely not be able to implement every combination directly, probably we can ship it gradually.

[armchairancap]

this could be quite complex. Each software require a different proxy configuration, probably. We might need to keep templates for each software title individually. And this for all available proxy software/ web server.

I just looked at the Wiki contents for adding s/w. I'd like to propose an app that can be installed as container (much easier than installing the app on NodeJS). If docs to provide container images were available, that would be very convenient.

[Gill-Bates]

I would like to point you Guys to traefik -> https://github.com/traefik/traefik

It looks like a load-balancer and reverse proxy with autodetection :-)

[MichaIng]

Especially since it is a single standalone binary, what is the benefit or wrapping it into a container engine? In the end one can/needs to configure Traefik via traefik.toml, isn't it?

[armchairancap]

Especially since it is a single standalone binary, what is the benefit or wrapping it into a container engine? In the end one can/needs to configure Traefik via traefik.toml, isn't it?

Yes, you always need a config file for Traefik itself, but if it runs in a container environment, it can auto-configure itself based on what it sees around it. Say you have a Webmail container and label it like so (YAML example):

version: "3"
services:
  webmail:
    # ...
    labels:
      - traefik.http.routers.my-container.rule=Host(`webmail.mydietpi.dyndns.com`)

Now Traefik container with loaded Docker provider can create webmail.* for you, use Let's Encrypt to take care of TLS, etc.
Whereas with a stand-alone Traefik you'd have to mess around with both Traefik and Docker/container configuration.

I'm not saying containerized Traefik is "better", but it's more convenient for some cases.
As I mentioned in another comment on this page, it would be convenient if DietPi apps could also be submitted as containers, so that Traefik auto-configures them.
Then rather than figure out how to avoid port and other (NodeJS version, etc.) conflicts, the submitter only has to submit a generic app container and YAML/TOML/JSON config file template that loads the container, and that also can take care of reverse proxy config, TLS, etc.

Personally I find Traefik harder to understand (their docs seem hard to follow for me) than NGINX, but as "black box" Traefik is probably more effective, if containers are properly deployed so that the above-mentioned auto-configuration takes place.

[Joulinar]

I don't think we will provide any of our software title as individual container. Why? Because quite a larger number of software title have their own original container / docker image.

[armchairancap]

I don't think we will provide any of our software title as individual container. Why? Because quite a larger number of software title have their own original container / docker image.

I meant regarding this process.

Let's say there's an app that runs on NodeJS. The author also built a container.
Now he can choose to "add a new software title" or - assuming something like Traefik exists - just provide a Docker compose file with Traefik-related config details, so that DietPi users can easily load the app.

I think this containerized approach can be easier, more convenient and result in fewer DietPie software updates, but it relies on the assumption that Traefik is in place, or at least available (or Candy or some other reverse proxy.)

[MichaIng]

Where possible we provide bare metal installs. And for Traefik this seems to be pretty trivial. To me it looks like when using a container, you trade the one config file for another one, loose flexibility, add a lot of overhead and add another engine and point of failure. We had enough fun with Docker recently: #6126

It's nice for complex multi-process setups with strict module version requirements, like if you have frontend, middle-end and backend + database and in case a dedicated cache server and all needs to work with each other and in case specific versions of each are required. But for most other things ... I don't know how difficult it is to manually setup Traefik as reverse proxy, but when it is easier to do it with a Docker container including all the implications, it does something wrong.

However, the discussion here is not about Traefik anyway but about reverse proxies in general. And of course we'd implement the ones we do already have in our software catalogue first, i.e. HAProxy, frp, Nginx, Apache, Lighttpd.

[mews-se]

https://nginxproxymanager.com/ is my go-to for this - also worth a look!

[MichaIng]

But it is a little massive as whole container + AFAIK it cannot be automated to create proxy entries for all web applications. The goal here would be to use bare metal webserver/proxy applications and optionally create individual proxy configs as part of the dietpi-software install process, or a dedicated script.

And same as with Caddy, NPM is not an install option yet: #4417

Also Docker (container engines) does not run on RISC-V yet and there will always be individual new SBCs with vendor kernel builds which do not support Docker, like the Quartz64 until we added support recently. So we should avoid relying on Docker, if there are alternatives.

[Joulinar]

Theoretically it should be possible to create NPM configs from outside the container as well

root@DietPiProd:~# cat /mnt/dietpi_userdata/docker-data/volumes/npm_data/_data/nginx/proxy_host/1.conf
# ------------------------------------------------------------
# pi.hole
# ------------------------------------------------------------


server {
  set $forward_scheme http;
  set $server         "192.168.0.11";
  set $port           8080;

  listen 80;
listen [::]:80;


  server_name pi.hole;






  # Block Exploits
  include conf.d/include/block-exploits.conf;







  access_log /data/logs/proxy-host-1_access.log proxy;
  error_log /data/logs/proxy-host-1_error.log warn;







  location / {








    # Proxy!
    include conf.d/include/proxy.conf;
  }


  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}

root@DietPiProd:~#

[jalsco]

I would like to point you Guys to traefik -> https://github.com/traefik/traefik

Traefik does look pretty cool ! I been using Caddy for a few years and never had any problem with it on DietPi.

But Traefik looks awesome too 👍