Limited Port Access in Compute Containers Prevents Use of Additional Development Servers

[alanlujan91]

Description

SciServer Compute containers currently only expose port 8888 (Jupyter Lab) through the proxy system, which prevents users from accessing additional development servers running inside their containers. This limitation affects modern development workflows that rely on tools running local web servers on various ports.

Current Behavior

When users run development servers in the Jupyter Lab terminal (e.g., myst start, streamlit run app.py, python -m http.server), these servers start successfully within the container but are not accessible from the browser because:

1. Only port 8888/tcp is bound in the Docker container configuration across all ExecutableManager implementations:

   • DefaultExecutableManager.java (lines 206-208)
   • NvidiaExecutableManager.java (lines 183-184)
   • NvidiaExecutableManager2.java (lines 189-190)
   • DsAppsExecutableManager.java (lines 192-194)

2. Kubernetes-based deployments similarly expose only port 8888:

   • KubernetesExecutableManager.java (line 60: servicePort = 8888)
   • KubernetesExecutableManager2.java (line 63: servicePort = 8888)

3. The proxy configuration in DockerBaseExecutableManager.java (line 58) and RegistryImpl.java (line 553) only forwards traffic to http://127.0.0.1:<assigned_port>, which maps exclusively to port 8888 inside the container

Expected Behavior

Users should be able to access web services running on additional ports within their compute containers, enabling modern development workflows.

Use Cases Affected

• MyST Markdown: Documentation live preview servers
• Streamlit: Data science apps (typically port 8501)
• Dash/Plotly: Dashboard applications (typically port 8050)
• Gradio: ML model interfaces (typically port 7860)
• Bokeh Server: Interactive visualizations (typically port 5006)
• FastAPI/Flask/Django: Custom API/web application development
• Panel/Voilà: Jupyter-based dashboards
• RStudio Server: R development (if installed)

Proposed Solutions

Option 1: Jupyter Server Proxy Integration (Recommended)

Integrate jupyter-server-proxy into SciServer compute images. This extension proxies arbitrary ports through Jupyter Lab's existing port 8888 infrastructure without requiring additional port bindings.

Advantages:

• Minimal infrastructure changes
• Leverages existing authentication and proxy architecture
• Battle-tested solution used by Binder, JupyterHub, and other platforms
• Provides intuitive UI for launching applications
• No changes needed to ExecutableManager implementations

Implementation:

• Add jupyter-server-proxy to container images
• Configure proxy rules for common tools
• Users can add custom proxies via configuration

Option 2: Multiple Port Binding

Extend container configuration to expose a range of additional ports (e.g., 8000-8010) with corresponding proxy rules.

Considerations:

• Requires modifications to all six ExecutableManager implementations
• Needs HttpProxyClient interface extensions
• Port allocation management per user
• More complex infrastructure changes

Option 3: Dynamic Port Registration API

Implement an API allowing users to request port forwarding during their session.

Considerations:

• Most complex implementation
• Requires new API endpoints and UI
• Dynamic proxy reconfiguration

Current Workarounds

Users can currently:

1. Generate static HTML files and view them through Jupyter Lab's file browser (loses live-reload functionality)
2. Download files locally for preview (negates integrated development environment benefits)

These workarounds significantly reduce productivity and limit the appeal of SciServer for modern development workflows.

Impact

This limitation affects data scientists, researchers, and developers using modern Python development tools.

[jzeltne1]

+1 for this improvement. Something like this is necessary for teaching purposes as well. - Jane Zeltner, TA for 180.369

[amitschang]

Thanks for creating the issue!

Your request as I understand is indeed supported in SciServer - and you have correctly identified preferred option - 1, using the jupyter server proxy for compute sessions that are using Jupyter as an interface.

The SciServer software only really imposes compute containers to have a known http port of entry, but beyond that we do not place restrictions, so for example we do have some containers that run an nginx reverse proxy that forwards requests to that port (8888) to any number of listening applications also on the container. In the SciServer system, these container images are separate from the source code here to provide such flexibility.

For this reason, I think it is not particularly beneficial to implement anything opening other ports to the containers. All applications already need to operate behind path rewrite rules, so there wouldn't be benefit from the url perspective either.

I believe your issue is not just pertaining to the software system, but to the compute capabilities made available at SciServer@JHU (https://apps.sciserver.org). If there are issues specific to that, it is probably best to open a help-desk ticket from the links therein.

I will however note that some images there already to have the server-proxy running, for example "SciServer Essentials 4.0" has the proxy - you can access services via {base-url}/proxy/{port}/! As mentioned above, this is implemented in the image, so it might not be supported in all images.

Please let us know if this is helpful