amdresearch/aup-learning-cloud/expose-aup-learning-cloud

Expose AUP Learning Cloud

Take a deployment from the local NodePort/local-path defaults to a real network and storage posture: choose how the proxy is reached (NodePort, LoadBalancer, or ingress + TLS), tell the Hub about externally-terminated TLS, set CORS origins, and move persistent data onto shared NFS.

Edit a values overlay and re-apply with Helm / the installer. NFS, ingress, and TLS are opt-in — the checked-in defaults are a plain HTTP NodePort. The full value blocks, the NFS provisioner setup, and troubleshooting are in [reference.md](reference.md).

Prerequisites

• A running AUP Learning Cloud and helm + kubectl (or ./auplc-installer).
• For ingress/TLS: an ingress controller in the cluster, a DNS record for the

hostname, and a certificate source (cert-manager issuer or a TLS secret).

• For NFS storage: an NFS server/export reachable from every node.

The defaults you are changing

The checked-in runtime/values.yaml is local-oriented: proxy.service.type: NodePort on 30890, ingress.enabled: false, hub.db.pvc.storageClassName: local-path, singleuser.storage.dynamic.storageClass: local-path. Treat NFS, ingress, and TLS as deliberate additions.

Pick the exposure path

Workflow

1. Read current state. Note proxy.service, ingress, the two

storageClassNames, and whether TLS is terminated by the chart or upstream.

1. Set exposure in the overlay (one path above). For ingress, set the host

and the TLS config; point DNS at the controller.

1. Handle TLS termination. If TLS terminates outside the chart (LB or

external proxy), set custom.security.publicScheme: "https" so the Hub marks _xsrf cookies secure and builds correct https URLs.

1. CORS / embedding (only if needed). Add origins to

custom.hub.allowedOrigins (Hub CORS) and/or custom.notebook.allowedOrigins (single-user server args). Leave empty unless something embeds the Hub.

1. Storage (multi-node / production). Move the Hub DB and user PVCs to

nfs-client: install nfs-subdir-external-provisioner against your NFS export, then set both storageClassNames. Provisioner setup is in reference.md.

1. Pre-flight the render. `helm template jupyterhub ./runtime/chart -f

runtime/values.yaml -f <overlay>` must succeed.

1. Apply with helm upgrade --install … -n jupyterhub (or rt upgrade

single-node) and verify:

``bash kubectl get svc,ingress -n jupyterhub kubectl get storageclass kubectl get pvc -A ``

Then load the public URL over HTTPS, log in, and confirm a spawned pod's PVC binds on the new storage class.

code-server exposure safety

code-server resources run code-server --auth none on port 8888 and are safe only behind the JupyterHub proxy's auth boundary. Never expose that pod port directly via NodePort, LoadBalancer, or ingress. Only the JupyterHub proxy service should be public.

Safety

• Changing storage class does not migrate existing data. Switching

storageClassName affects new PVCs; the Hub DB PVC and user homes do not move automatically. Plan a migration/backup before changing it on a live Hub — confirm with the user.

• Editing `/etc/exports` + restarting `nfs-kernel-server` is disruptive;

gate it (see deploy/troubleshoot skills for the NFS host side).

• Exposing to the internet raises the stakes — pair with HTTPS, a real auth

mode (configure-auth), and never expose code-server's raw port.

• A helm upgrade restarts the Hub pod (brief login blip).
• Never commit TLS private keys or put them in tracked values; use a K8s secret.

Reference

NodePort/LoadBalancer/ingress value blocks, TLS + cert-manager options, publicScheme/allowedOrigins, the NFS provisioner install and default-class patch, and troubleshooting: reference.md.