Proposal: serving rack-ui on the same HTTP port

[Ptival]

@glguy and I have been investigating what it would require to avoid port proliferation in our images.

Right now, we serve rack-ui solely on port 8050.

By simply adding the following snippet to /etc/nginx/sites-available/default:

location /rackui/ {
    proxy_pass http://localhost:8050
}

We can make it so that, externally, we can hit localhost:8080/rackui to reach the RACK UI.

This does require a small change in rack-ui/app.py, so that all URLs are prefixed with /rackui/:

app = Dash(
    __name__,
    external_stylesheets=[dbc.themes.BOOTSTRAP],
    background_callback_manager=background_callback_manager,
+   url_base_pathname="/rackui/",
)

We think this would be nice to avoid having to forward port 8050->8050 when booting the Docker image, on top of the already existing 8080->80 redirect.

@tuxji This feels like it's in your territory, what do you think?
@weisenje Any objection on your end?

[tuxji]

I don't see any technical objection on my end, but I will defer to @weisenje. If you go ahead and make this change, you will need to send a RACK pull request touching many places and also update the RACK wiki:

• rack-box/scripts/install.sh (to add the snippet to /etc/nginx/sites-available/default)
• rack-ui/app.py (to define url_base_pathname)
• all the places where "8050" occurs in RACK files
• all the places where "8050" occurs in the RACK wiki

interran@GH3WPL13E:~/ARCOS/RACK$ rg -w 8050
rack-box/rack-box-virtualbox.json
34:        ["modifyvm", "{{.Name}}", "--natpf1", "rackUi,tcp,,8050,,8050"],

rack-box/Docker-Hub-README.md
26:docker run --detach -p 3030:3030 -p 8050:8050 -p 8080:80 -p 12050-12091:12050-12091 gehighassurance/rack-box:v11

rack-box/GitHub-Release-README.md
10:3. Type `docker run --detach -p 3030:3030 -p 8050:8050 -p 8080:80 -p 12050-12091:12050-12091 gehighassurance/rack-box:v11`

cli/docker_start.sh
42:            -p 8050:8050 \
interran@GH3WPL13E:~/ARCOS/RACK$ cd ../RACK.wiki/
interran@GH3WPL13E:~/ARCOS/RACK.wiki$ rg -w 8050
_Welcome.md
22:- [RACK-UI](http://localhost:8050)

04-Getting-Started.md
12:* <http://localhost:8050>

02-Run-a-RACK-Box-container.md
77:docker run --detach -p 3030:3030 -p 8050:8050 -p 8080:80 -p 12050-12091:12050-12091 gehighassurance/rack-box:v11
115:docker run --detach -p 3030:3030 -p 8050:8050 -p 8080:80 -p 12050-12091:12050-12091 -e WEB_HOST=192.168.1.151 gehighassurance/rack-box:v11

[tuxji]

Note that @weisenje has a branch, dev-test, which the CI treats specially for testing purposes. If she agrees, you could force push the master branch to dev-test (wiping out the old branch), make your changes in the dev-test branch, and the CI will automatically build a Docker image with the dev-test tag. You can pull gehighassurance/rack-box:dev-test and test it as much as you need to verify that your changes work as expected before you submit a pull request merging dev-test into master.

[weisenje]

Would the proposed solution cover the VM as well as the Docker image?

If so, then my main concern is for local deployments, where the SemTK web server on 8080 should not be made aware of the RACK UI or 8050. I believe this means that for local deployments, we’d have to hit the RACK UI at 8050 instead of 8080/rackui. This may be possible (not sure), but would likely lead to some code diverging which we’ve been trying hard to minimize.

If the above is correct, then personally I would prioritize keeping things uniform across all 3 deployments (Docker, VM, local) over the port consolidation.

[Ptival]

I think the Virtualbox VM would just need the exact same change in its nginx configuration.

At that point, users who expose port 8050 could access the UI through that, as well as through :8080/rackui.

The internal links in the UI should be relative, and thus oblivious to the change: they would preserve whichever context the page was initially requested from, though I'd have to double-check that it works. I will do a little more testing, and propose a PR only if I feel like it is robust across all setups.

[glguy]

@weisenje Could you remind me how we serve SparqlGraph in the standalone deployments? I've been using the docker deployments for so long that I don't remember how that works.

[weisenje]

@weisenje Could you remind me how we serve SparqlGraph in the standalone deployments? I've been using the docker deployments for so long that I don't remember how that works.

We use an Apache Tomcat web server running on port 8080.

[weisenje]

Addressing this issue may introduce more risk than warranted - suggest dropping it unless someone feels strongly