Horror with Docker & Reverse Proxy because of all the paths

[ramon-kramer]

hey guys, it's very hard to configure a reverse proxy with docker because nearly every function in papermerge has it's own path (/upload/, /static/, /nodes/ etc.). It's even harder if you are running other apps that shares a path with papermerge like /upload/.

My Apache Config looked like:

ProxyPass /papermerge/ http://127.0.0.1:8000/ retry=0
ProxyPassReverse /papermerge/ http://127.0.0.1:8000/

ProxyPass /alltags/ http://127.0.0.1:8000/alltags/ retry=0
ProxyPassReverse /alltags/ http://127.0.0.1:8000/alltags/

ProxyPass /automate/ http://127.0.0.1:8000/automate/ retry=0
ProxyPassReverse /automate/ http://127.0.0.1:8000/automate/

ProxyPass /breadcrumb/ http://127.0.0.1:8000/breadcrumb/ retry=0
ProxyPassReverse /breadcrumb/ http://127.0.0.1:8000/breadcrumb/

ProxyPass /browse/ http://127.0.0.1:8000/browse/ retry=0
ProxyPassReverse /browse/ http://127.0.0.1:8000/browse/

ProxyPass /upload/ http://127.0.0.1:8000/upload/ retry=0
ProxyPassReverse /upload/ http://127.0.0.1:8000/upload/

...

And some functions still doesn't work. Best solution would be a top-level path like /papermerge/ and then sub-paths for all other functions. This makes Reverse-Proxy configs very easy with 2 lines like this:

ProxyPass /papermerge/ http://127.0.0.1:8000/papermerge/ retry=0
ProxyPassReverse /papermerge/ http://127.0.0.1:8000/papermerge/

I have tested this with many other apps, some of them support Docker Environment Variables to configure this path.

regards

[whysthatso]

i'm curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it's being run as an application server via mod_wsgi-express? in the latter case i don't know, in the former case i'm not sure why you would need all these routes?

tbh i don't know the apache setup, the corresponding nginx vhost for my setup looks like that:

  upstream papermerge_server {
    server app.example.net:42551 fail_timeout=0;
  }

  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name papermerge.example.net;

  <snip ssl stuff>

    client_max_body_size 20M;
    keepalive_timeout 5;
    root /var/www;
    try_files $uri/index.html $uri.html $uri @app;

    location @app {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_pass http://papermerge_server;
    }

}

[ramon-kramer]

i'm curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it's being run as an application server via mod_wsgi-express? in the latter case i don't know, in the former case i'm not sure why you would need all these routes?

tbh i don't know the apache setup, the corresponding nginx vhost for my setup looks like that:

  upstream papermerge_server {
    server app.example.net:42551 fail_timeout=0;
  }

  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name papermerge.example.net;

  <snip ssl stuff>

    client_max_body_size 20M;
    keepalive_timeout 5;
    root /var/www;
    try_files $uri/index.html $uri.html $uri @app;

    location @app {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_pass http://papermerge_server;
    }

}

This only happens if running reverse-proxy without using a subdomain (mydomain.com/papermerge/ instead of papermerge.mydomain.com)

[whysthatso]

ah right, that makes sense.

to be honest, i've never really understood the idea of separating services by means of path rather than subdomain. i strictly follow the principle: one service = one subdomain, and i think that was the actual intention of the domain name structure; which by its virtue avoids complexities like these kind of routing issues. maybe a way to go after all?

i do understand that there are limitations in choice and amount of subdomains depending on the dns provider situation, maybe a good reason to switch :)

[ramon-kramer]

the main issue is that you will need a ssl-cert that is valid for every subdomain. using letsencrypt means you have to set an a-record for each subdomain and then issue a cert. i'm using univention corporate server with its built in letsencrypt-app and it's much more comfortable to setup a new service there with just a new apache config file than all the other steps needed for the way with subdomains. with a path it is also possible to deploy this as a docker based app with just a click in different systems like univention corporate server, nas-systems etc. because nothing outside the docker host has to be configured (like a-records or new certs). so i always prefer the path-based-way if possible :)

[whysthatso]

i understand your use case, of course. just for sake of completeness:

• letsencrypt offers wildcard certificates
• one would probably prefer cname records over a records, but that depends on the underlying infrastructure

and - of course - one avoids a bunch of "horrible" routing issues :D

but i do acknowledge that there are different scenarios.

[ciur]

Is this ticket still relevant ? Can I close it ?

[ramon-kramer]

hi, as this is more a feature-request than an issue, you can close this. but still would be nice to have this option for deployment :)