September 19, 2017

Pi3 nGinx Reverse Proxy

So … you’ve got a Pi3 running as a Docker host with some services that you want your buddies to have access to. You could try and get them to SSH into your home network; just like you could type all your programs with a touchscreen.

I’m going to use nGinx to setup a reverse-proxy from my real-Pi3 to various Docker containers based on URL rewriting.

I’m doing something else (of course) I’m setting up (what I call) name-based-virtual-hosting.

Name-Based Virtual Hosting / Proxy Pass

Most web-server programs support a trick to check the URL and do something with it based on a matching expression. Most also support some method of “proxying” passing the web page request off to another server somewhere else.

Traditionally, proxies were developed so that everyone could access the web through them and the servers could cache things to avoid “dialling out” excessively. Later on, “reverse proxies” became a common way to use a single front-facing web-server handle requests and pass them off to different internal services.

So, I (am now|will be|do want) using Docker to run;

Gogs
Jenkins
SonarQube
Payara
Conan.io
SeaFiles
Nexus

Likely; these will all want to play their own way, so nGinx to the rescue!

nGinx Installation

I installed nGinx on the “real host” rather than in a Docker container.

peter@superpi3:~$ sudo apt-get install nginx

I … actually, can’t remember why. Next time; I’ll try a container … maybe …

If you’re following these instructions, then check that it works by browsing to http://localhost/

nGinx Setup

nGinx (like Apache before them) stores website configurations in /etc/nginx/sites-available/ and creates symlinks in /etc/nginx/sites-enabled/ to activate them,. To disable the “default” site you can …

peter@superpi3:~$ sudo rm /etc/nginx/sites-enabled/default

… and the original will remain behind if you want to check on it. We/I am going to use a brand new site doki-full-stak so (for now) create the site configuration like this;

peter@superpi3:~$ sudo su
root@superpi3:~$ cat > /etc/nginx/sites-available/doki-full-stak <<HEREEOF
server {
    listen 80;
    server_name superpi3.gpechorin.x64;

    # fallback to the nginx default site
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
HEREEOF
root@superpi3:~$ exit
peter@superpi3:~$

… then, enable an empty site configuration with …

peter@superpi3:~$ sudo su
root@superpi3:~$ ln /etc/nginx/sites-available/doki-full-stak /etc/nginx/sites-enabled/doki-full-stak
root@superpi3:~$ exit
peter@superpi3:~$

… and we’re ready to setup bits for specific web-apps!

Every time that you change this file, you’ll need to tell nGinx to reload peter@superpi3:~$ sudo service nginx reload

nGinx Gogs

Okay … so the fast answer is to read the Gogs FAQ but that’s probably not why you’re here.

Gogs is actually pretty simple to setup, there are two concerns;

Gogs expects the URLs to be “rewritten”
Gogs needs to be configured with the root_url

The first concern is dealt with by using the proxy_pass option in the site configuration, so add this to the middle of /etc/nginx/sites-available/doki-full-stak and move on.

    location /doki/gogs/ {
        proxy_pass http://localhost:3000/;
    }

The second concern dictates that one must update gogs/conf/app.ini (wherever that is) and set …

...
ROOT_URL = http://superpi3.gpechorin.x64/doki/gogs/   
...

… or whatnot to get the intended result.

Finally; tell nGinx to reload peter@superpi3:~$ sudo service nginx reload and you should be able to browse to your Gogs instance. I needed to tell Gogs what the new URL was BEFORE I could use it. I had assumed that the URL was only used for interface things, BUT, looks like it’s used for determining which path is being whatnot’ed under the hood.

Sweet; so you/I now have a functioning nGinx reverse proxy to reach Gogs! It doesn’t seem to like super-big git+http:// with lots of binary files … there’s an FAQ fix. I set it to client_max_body_size 4096m; and placed it outside of any location{...} block - worked fine. I’d preffer one of these “SSH-Gateway” solutions but they seem beyond me at the moment.

Result

I now have my tools being served from a real-boy webserver who hides my byzantine Docker setup. This works quite well for me. I’m going to re-post this post when/if I get more stuff installed and working.