Using Visual Studio Code inside a job

Visual Studio Code is a powerful and popular file editor and Jupyter notebook engine, among other features. It has the capability to connect to servers and work remotely with ease.

But...

Warning

By giving Visual Studio Code access to a cluster, you could inadvertently grant access to other entities. This can happen by cloning a malicious GitHub project or installing a malicious Visual Studio Code extension.

Therefore, exercise caution when using Visual Studio Code. You could potentially compromise your laptop, your account on the clusters, and any computer you have SSH access to.

Additionally, the SSH extension of Visual Studio Code is very resource-intensive. It continuously monitors the files in the current workspace, consuming a significant amount of memory and performing extensive disk activities. On a cluster, unlike on a laptop, this can significantly slow down the entire system.

It is therefore important that Visual Studio Code is used inside a job allocation, and uses files stored in a local filesystem, or in a memory filesystem. See this document for information about filesystems on the clusters. The remainder of this document describes how to use Visual Studio Code within a job allocation.

There are multiple ways to achieve this goal; the method proposed here offers a balance between automation and control.

The procedure will involve submitting a job with tailored resource requests and a pre-defined name. That job will start an SSH server dedicated to the user. Then, the SSH client on the laptop will be configured with a “pseudo-server” that will refer to, and connect to, the SSH server started in the job. Finally, in Visual Studio Code will connect to the “pseudo-server”.

Mise en place

Before you set this up, here are the things you need to decide on:

  • name of the job (e.g. tunnel) : Must be only one running job with that name under your user
  • port for sshd (e.g. 2222) : Must be above 1024, and must be unique among users using the same setup on the same compute node
  • an SSH key to use: The private part must be in your SSH agent and the public part on the clusters in ~/.ssh/authorised_keys

Configure a “pseudo-server” in ~/.ssh/config. In the example below, it is named lm4-job. This SSH host will point to the compute node that is running the tunnel job. For instance, for Lemaitre4:

When you start working

  1. Submit a job with the proper name and resources, that will start a custom SSH server under your user, in the job’s environment :
  1. Start VSCode and connect to the “pseudo-server” lm4-job
../../_images/vscode.png

Final notes

Please take note of the following aspects of this recipe:

  • the submission of the job is not automatic, nor is job cancelling
  • all vscode instances started to the same cluster will share the same job
  • using SSH from within the job is nice to have all environment properly setup (including modules, slurm job id, etc.)
  • the SSH agent must be running and forwarded