VS Code en tu laboratorio
Un notebook Jupyter sirve para explorar datos y probar ideas. Cuando el trabajo pasa a ser un paquete con módulos, pruebas y git, un editor completo ayuda: explorador de archivos, terminal, depurador, extensiones. Hay dos formas de tener VS Code contra tu laboratorio y las dos trabajan sobre los mismos volúmenes que tus notebooks.
- VS Code en el navegador: un notebook más, con el mismo formulario y el mismo presupuesto de la talla. No instalas nada.
- Tu VS Code de escritorio conectado por túnel: tu editor local, con tus extensiones y ajustes, editando y ejecutando dentro del notebook.
Lo que VS Code no es: una máquina aparte. Corre dentro del laboratorio, con los recursos que pidas al crearlo, y lo que guardes fuera del volumen se pierde al reiniciar, igual que en cualquier notebook (ver Qué sobrevive a un reinicio).
Camino 1: VS Code en el navegador
Es un tipo de notebook. Se crea desde el panel del laboratorio con el mismo formulario que un notebook Jupyter.
-
Abre Notebooks y pulsa New Notebook.
-
Elige el entorno VisualStudio Code.
-
Rellena CPU / RAM, GPUs, Workspace Volume y Data Volumes como en Crear un notebook. Deja el volumen montado en
/home/jovyan. -
Pulsa LAUNCH y, cuando el estado sea verde, CONNECT.
Abre en una pestaña del navegador con explorador de archivos, terminal integrada (Ctrl+` ), extensiones y git.
Ver los archivos de otro notebook
Los volúmenes del laboratorio se pueden montar en varios notebooks a la vez. Para trabajar desde VS Code sobre los archivos de un notebook Jupyter del mismo laboratorio, en Data Volumes usa Attach existing volume, elige el volumen <nombre>-workspace del otro notebook y móntalo en una carpeta dentro de /home/jovyan (por ejemplo /home/jovyan/jupyter). Verás los mismos archivos en los dos entornos, y lo que guardes en uno aparece en el otro.
Camino 2: tu VS Code de escritorio conectado al laboratorio
Para quien prefiere su editor local. Funciona con la función Remote Tunnels de VS Code: desde una terminal del notebook descargas el CLI de VS Code, inicias sesión con una cuenta de GitHub o Microsoft y abres un túnel con nombre. Después entras a ese túnel desde tu escritorio.
No hace falta pedir nada al administrador ni abrir puertos: el túnel es tráfico saliente del notebook.
Abrir el túnel desde el notebook
- Abre una terminal en el notebook (Jupyter o VS Code en el navegador).
- Descarga el CLI en
/home/jovyan, no en/tmp: fuera del volumen se borra al reiniciar. - Inicia sesión y abre el túnel. Nombra el túnel por el laboratorio (
lab-fugas), no por la persona.
cd /home/jovyan
curl -sSL -o vscode_cli.tar.gz 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64'
tar -xzf vscode_cli.tar.gz
./code tunnel user login --provider github
./code tunnel --accept-server-license-terms --name lab-fugas
El comando de inicio de sesión imprime To grant access to the server, please log into https://github.com/login/device and use code XXXX-XXXX. Abre esa dirección en tu navegador, escribe el código y autoriza. Con --provider microsoft el flujo es el mismo con una cuenta Microsoft.
El último comando deja el proceso corriendo e imprime la URL https://vscode.dev/tunnel/lab-fugas. Mientras ese proceso viva, el túnel está abierto.
Conectar desde tu escritorio
Dos opciones, con la misma cuenta que autorizó el túnel:
- En tu VS Code de escritorio, instala la extensión Remote - Tunnels y ejecuta Remote-Tunnels: Connect to Tunnel. Elige
lab-fugas. - En el navegador, abre
https://vscode.dev/tunnel/lab-fugas.
Al entrar, VS Code pregunta si confías en la carpeta. Es tu propio volumen: acepta, o la terminal y las tareas no funcionan. En la barra de estado aparece el nombre del túnel.
Quién puede entrar
La cuenta de GitHub o Microsoft que autorizó el túnel decide quién puede conectarse a él. No es la cuenta de Studio, y compartir el laboratorio no comparte el túnel: solo esa cuenta lo ve. Si otra persona del laboratorio quiere su propio acceso, abre su propio túnel con su cuenta y otro nombre.
Mantener el túnel vivo
El túnel muere cuando cierras la terminal que lo lanzó y cuando el notebook se detiene o reinicia. Para que sobreviva al cierre de la terminal, lánzalo en segundo plano:
nohup ./code tunnel --accept-server-license-terms --name lab-fugas > tunnel.log 2>&1 &
Tras un reinicio del notebook hay que relanzarlo. Como el CLI queda en /home/jovyan, basta con volver a ejecutar esa línea; si vuelve a pedir el código de dispositivo, autoriza otra vez. Guárdala en un script tunel.sh en el volumen y ejecútalo una vez por sesión. No la pongas en ~/.bashrc: cada terminal nueva lanzaría otro proceso con el mismo nombre.
Para dar de baja el túnel:
./code tunnel unregister
Una sola GPU por laboratorio
Un laboratorio tiene un presupuesto de GPU y un notebook con GPU lo ocupa entero. Si pides un segundo notebook con GPU mientras otro corre, el nuevo se queda sin arrancar con un mensaje de cuota excedida. Es el mismo caso que El notebook no arranca y El laboratorio excede su cuota.
En la práctica:
- Si quieres VS Code con GPU, detén primero el notebook Jupyter, o usa VS Code como tu único notebook: con la extensión de Jupyter también abre y ejecuta archivos
.ipynb. - Un VS Code sin GPU (Number of GPUs: None) convive con el Jupyter que tiene la GPU. Si le montas el volumen del otro notebook, ves sus archivos: sirve para editar, revisar y usar git mientras el otro entrena.
Lo que no hay: SSH
Los notebooks no exponen SSH y no se puede pedir. Todo lo que harías por SSH tiene equivalente:
| Por SSH harías | En el laboratorio |
|---|---|
| Editar y depurar código | Cualquiera de los dos caminos de esta página. |
| Abrir una terminal | La terminal integrada de JupyterLab o de VS Code. |
| Copiar archivos | El explorador de archivos de JupyterLab o VS Code, o el explorador del volumen en Volumes. |
| Dejar corriendo algo largo | Lánzalo como pipeline o entrenamiento. No dependas de una terminal abierta: muere con el notebook. |