A reverse proxy is a server that forwards requests from clients to one or more upstream servers. It receives requests from clients, processes them, and then forwards the requests to the appropriate upstream server. The upstream server returns the response to the reverse proxy, which then sends the response back to the client.
In AI Workbench, we utilize a reverse proxy to direct your web browser’s requests to Project containers and the applications within them. This design choice simplifies connecting to remote Locations by requiring only a single SSH tunnel for accessing all projects and apps running in a particular Location.
Traefik is used as the reverse proxy for AI Workbench. It runs in a container automatically when the AI Workbench server starts.
All Project containers run in a custom bridge network called workbench. Because of this network configuration, and how AI Workbench starts Project containers, you cannot connect directly to the apps running in these containers. However, the proxy runs on the bridge and is port mapped to port 10000 on the host. This means that you can talk to the proxy from your host, which routes to apps in the isolated project containers as needed.
The proxy is available on localhost only, without a SSL/TLS configuration. Remote Locations automatically use and SSH tunnel to access the proxy securely.
Only webapp class Apps use the Reverse Proxy.
The Traefik proxy configuration is dynamically managed by AI Workbench automatically. This means that you, as a user, do not have to worry about configuring Traefik manually. Each “webapp” class app will get routed through the proxy based on its configuration in the Workbench Project specification file, ensuring that your applications are properly routed and accessible.
When you start a webapp class app, AI Workbench will write a configuration file for Traefik in the directory $HOME/.nvwb/traefik-configs. This file contains the necessary configuration details for Traefik to properly route your application. Traefik will detect any changes in the configuration files and automatically reload and adjust routing.
Depending on your app, you may need additional configuration to make it work behind a proxy
The environment variable
PROXY_PREFIXis available for use. It contains the route that that app will be running on. This follows the format/projects/<name of project>/applications/<name of application>.Apps have the “trim prefix” option. If enabled, the proxy will strip off the
PROXY_PREFIXbefore routing to the app. This is very useful for things like APIs that don’t expect a prefix.
If your webapp needs to “know” the route at which it will be run to function properly, the environment variable PROXY_PREFIX is always injected into app process when started. This environment variable follows the format /projects/PROJECT_NAME/applications/APP_NAME.
Additionally, you can enable the “trim prefix” option for your app. This option instructs the proxy to strip off the PROXY_PREFIX value before routing to the app, which is useful for things like APIs that don’t expect a prefix.
For example, if your app is named “myapp” and it’s in a project named “myproject”, the app would be available at http://localhost:10000/projects/myproject/applications/myapp. If the “trim prefix” option is enabled, the proxy will remove projects/myproject/applications/myapp before routing the request to your app.