External access to Containers
Researchers working with containers may at times need to remotely access the container. Some examples:
- Using a Jupyter notebook that runs within the container
- Using PyCharm to run python commands remotely.
- Using TensorBoard to view machine learning visualizations
This requires exposing container ports. When using docker, the way Researchers expose ports is by declaring them when starting the container. Run:ai has similar syntax.
Run:ai is based on Kubernetes. Kubernetes offers an abstraction of the container's location. This complicates the exposure of ports. Kubernetes offers several options:
|Port Forwarding||Simple port forwarding allows access to the container via local and/or remote port.||None|
|NodePort||Exposes the service on each Node’s IP at a static port (the NodePort). You’ll be able to contact the NodePort service from outside the cluster by requesting ||None|
|LoadBalancer||Exposes the service externally using a cloud provider’s load balancer.||Only available with cloud providers|
See https://kubernetes.io/docs/concepts/services-networking/service for further details on these options.
Version 2.9 and up
Version 2.9 introduces Workspaces which allow the Researcher to build AI models interactively.
Workspaces allow the Researcher to launch tools such as Visual Studio code, TensorFlow, TensorBoard etc. These tools require access to the container. Access is provided via URLs.
Run:ai uses the Cluster URL provided to dynamically create SSL-secured URLs for researchers’ workspaces in the format of
While this form of path-based routing conveniently works with applications like Jupyter Notebooks, it may often not be compatible with other applications. These applications assume running at the root file system, so hardcoded file paths and settings within the container may become invalid when running at a path other than the root. For instance, if the container is expecting to find a file at
/etc/config.json but is running at
/project-name/workspace-name, the file will not be found. This can cause the container to fail or not function as intended.
To address this issue, Run:ai provides support for host-based routing. When enabled, Run:ai creates workspace URLs in a subdomain format (
https://project-name-workspace-name.<CLUSTER_URL>/), which allows all workspaces to run at the root path and function properly.
To enable host-based routing you must perform the following steps:
- Create a second DNS entry
*.<CLUSTER_URL>, pointing to the same IP as the original Cluster URL DNS.
Obtain a star SSL certificate for this DNS.
Add the certificate as a secret:
- Create the following ingress rule:
<CLUSTER_URL> as described above.
- Edit Runaiconfig to generate the URLs correctly:
Once these requirements have been met, all workspaces will automatically be assigned a secured URL with a subdomain, ensuring full functionality for all researcher applications.
- To learn how to use port forwarding see the Quickstart document: Launch an Interactive Build Workload with Connected Ports.
- See CLI command runai submit.