Traefik web proxy for webapp class app - URL mapping to port in the web app config

[joe173]

Looking at how to expose a Dash dashboard to the web browser from a Jupyter notebook. In my local machine, I have my Jupyter notebook start the Dash app server with an app.run()

Are container web apps remapped from their true local ports to be exposed on port 10,000?

This document Reverse Proxy and Networking — NVIDIA AI Workbench User Guide says that a traefik configuration is updated for any webapp. I’m assuming it is the port setting in the webapp that is fed to traefik`. Is that correct?

The proxy remapping is from container localhost:nnnn to AI Workbench hostlocalhost:1000/projects/.... as defined in https://docs.nvidia.com/ai-workbench/user-guide/latest/reference/proxy.html#configuring-apps-to-work-behind-a-proxy

Could someone add a link in the docs here Reverse Proxy and Networking — NVIDIA AI Workbench User Guide from the term webapp to a glossary of application types supported. It looks like the two supported types are webapp and process

Thanks for putting this page Reverse Proxy and Networking — NVIDIA AI Workbench User Guide together. I don’t remember seeing that in the docs the last time I looked.

[edwli]

Hi Joe,

Thanks for reaching out.

Are container web apps remapped from their true local ports to be exposed on port 10,000?

In short, it depends. The way AI Workbench works is if you are working on your local location, all apps running locally (no matter the port) are routed using the following format on port 10000:

http://localhost:10000/project/project-name/application/application-name

This means for some app running on, say, port 3000, once added via AI Workbench it will be routed by the reverse proxy to port 10000 and differentiated by the project-name and application-name in the proxy prefix.

For remote locations, we follow the same logic, except the port number will change. For example, application X on remote location A could be accessible from:

http://localhost:10002/project/some-project/application/application-X

while application Y on remote location B could be accessible from:

http://localhost:10004/project/potentially-other-project/application/application-Y

This is how the reverse proxy differentiates between different apps running within different projects potentially across different locations. The local location is mapped to port 10000, and any remote locations are mapped to port 10002, 10004, 10006, and so on.

This is why the proxy prefix is important. By setting this value in the application, it can successfully run in such a way for AI Workbench to expose it properly. Provided is an example from the Hybrid RAG example project. If you can’t set this value, you also have the option to trim the proxy prefix before any requests are routed to the app.

Hope this helps!

This document says that a traefik configuration is updated for any webapp. I’m assuming it is the port setting in the webapp that is fed to traefik. Is that correct?

Your reasoning is accurate, when you add an app under Project Container > Applications > Add, you specify the port number that the app is expected to run on. This configuration for the webapp is forwarded and updated in traefik so it can handle routing the application properly.

Could someone add a link in the docs here from the term webapp to a glossary of application types supported

We can forward the request to our docs person. Thanks!

[joe173]

Does the topology look something like this? I’m tracking the ports and tunnels required and the general components. AI Workbench seems to have a generalized framework for doing remote data exploration with support for web GUIs. The docs are good, but I wanted a picture for a talk.

[amtorrico]

Hi, this is close but should be corrected a few ways:

1. The Developer Machine Workbench CLI sets up an SSH tunnel to the Remote Server Workbench Service for communication. The Workbench Service is what handles communciation with Docker through the Docker CLI. You may want to replace Workbench CLI with Workbench Service in the Remote Server instances. The Workbench CLI corresponds to the literal nvwb-cli program binary and the Workbench Service corresponds to the literal wb-svc program binary. A local Workbench installation will never directly use a remote Workbench CLI program, all coordination happens through the connection to the remote Workbench Service.
2. When accessing a Remote Server project application throught the Developer Machine Web Browser, the Web Browser receives the project through another SSH tunnel to the Traefik Proxy over the dedicated Docker Workbench bridge network.
3. The Developer Machine VSCode instance communicates with vscode-server in the Remote Server Docker project container through an SSH tunnel. It does not communicate through a vscode-server instance running in the Remote Server host environment.