Here be tips for using VS Code as a collaborative cloud-friendly editor, in several senses.
“Remote”
Remote edits code in particular environments from a local VS Code instance - including spinning up containers or SSH sessions, so that your editor and execution environments can be different. The remote execution environments can be elsewhere on the internet, or they can be local VMs, which is why I have “scare quotes” around the word “remote”. VS Code tries hard to make this rather different configuration be seamless, installing some helper files on the remote side that interact smoothly with the local side. Occasionally some extensions will not work gracefully across the barrier between local and remote, but for most of my workflows the problem does not arise. This is generally the easiest and most mainstream option for editing remote stuff for jupyter, and I use it all the time.
Use in practice is best explained by using the tutorial examples.
Tutorial | Description |
---|---|
Remote via SSH | Connect to remote and virtual machines with Visual Studio Code via SSH. |
Work in WSL | Run Visual Studio Code in Windows Subsystem for Linux. |
Develop in Containers | Run Visual Studio Code in a Docker Container. |
GitHub Codespaces | Connect to a codespace with Visual Studio Code. |
Also I wrote one about getting remote debugging for python working in a fiddly environment, see below.
Pro tip: remote editing via unreliable or intermittent network connection can be a drag. There is no universal persistent SSH session solution at time of writing. It would be nice if it worked over eternal terminal but it does not. However, Christopher LaPointe’s solution using tmux provides a bandaid solution.
Points of friction: Jupyter Notebook can interact badly with VS code remote, losing data if there is a buggy extension installed. (See also.)
tl;dr:
{
"terminal.integrated.profiles.linux": {
"tmux": {
"path": "/usr/bin/tmux",
"args": [
"new-session",
"-A",
"-s",
"vscode-${workspaceFolderBasename}"
],
},
},
"terminal.integrated.defaultProfile.linux": "tmux",
"remote.SSH.defaultForwardedPorts": [
{
"localPort": 9002,
"remotePort": 9002,
"name": "SA"
}
],
}
VS Code server
Slightly weirder, although still supported: run a server process that makes VS Code accessible to you in a browser. No local copy of VS Code is required; you use a browser window for everything.
I have not had need of this yet, because any scenario where I have HTTPS browser access to a remote server, I have also had SSH access and so it has been easier to use the VS Code Remote setup.
However, a completely browser-based IDE might be useful in some circumstances: in exotic devops scenarios, through painful firewalls, when working from a thin client, something like that?
There are at least two forks of VS code designed to be a server-side editor.
Code-server by Coder: The Developer Workspace Platform seems actively maintained and popular. AFAICT it is Linux-only.
Alternatively, gitpod-io/openvscode-server seems very similar and has an explanatory blurb:
VS Code has traditionally been a desktop IDE built with web technologies. A few years back, people started patching it in order to run it in a remote context and to make it accessible through web browsers. These efforts have been complex and error prone, because many changes had to be made across the large code base of VS Code.
Luckily, in 2019 the VS Code team started to refactor its architecture to support a browser-based working mode. While this architecture has been adopted by Gitpod and GitHub, the important bits have not been open-sourced, until now. As a result, many people in the community still use the old, hard to maintain and error-prone approach.
At Gitpod, we’ve been asked a lot about how we do it. So we thought we might as well share the minimal set of changes needed so people can rely on the latest version of VS Code, have a straightforward upgrade path and low maintenance effort.
Google Cloud
Does this use the same stack as the previous ones? Maybe. GoogleCloudPlatform/cloud-code-vscode: Cloud Code for Visual Studio Code: Issues, Documentation and more
Cloud Code for VS Code brings the power and convenience of IDEs to cloud-native Kubernetes and Cloud Run application development. Cloud Code works with Google’s command-line container tools like
skaffold
andkubectl
under the hood, providing local, continuous feedback on your project as you build, edit, and run your applications locally or in the cloud.
Google Colab
Distinct, both in billing and API, from generic google cloud.
Case study: Remote python debugger
Having said that everything is seamless, there are in fact edge cases where there divide between what is here on the client and what is there on the remote server, becomes important. One of those cases is interactive debugging.
Here is a worked example of what I needed to do to get a remote python debugger working from my local machine. Finding out why code that works locally does not work in the actual target deploy environment.
First need to install the debugpy package in our project. How to install depends how we are managing your python environment, but it will probably be one of these:
pip install debugy ## 👈🏻 this one for me
conda install debugpy
poetry add debugpy
Now I choose a network port for the debugger.1 This port needs to be unique to me (in the sense that no-one else on the remote machine should be using it) and it should be between 1024 and 65535. For simplicity’s sake I will assume the port is 48888, but I would recommend against that number for you because someone else might have copy-pasted these instructions and got there first, if you are using a shared machine. (Although not me; I use different port numbers in reality, this is just a tutorial example).
Next, we do a one-time setup of VS Code to know that it should look for that port by finding the debug tab in VS Code and adding a configuration.
This will open launch.json
into which we can add a configuration for a remote attach debugger:
{
"name": "Attach",
"type": "python",
"request": "attach",
"connect": {
"host": "127.0.0.1",
"port": 48888
},
"pathMappings": [
{
"localRoot": "${workspaceFolder}",
"remoteRoot": "."
}
]
}
This part is clunky, but after one-time setup everything goes smoothly. VS Code will do all the remaining necessary networking by magic.
So NOW WE ARE READY TO DEBUG. Almost. We still need to load up our code on the server to USE the debugpy module. Two options here.
Firstly, we could invoke the code from the vs code terminal like this:
python -m debugpy --listen 0.0.0.0:48888 ./myscript.py
Alternatively, we could load and execute the debugging system inside myscript.py
:
import debugpy
debugpy.listen(('0.0.0.0', debug))
debugpy.wait_for_client()
Either way, VS code will detect what I am doing and magically open up an SSH tunnel from here to there.
Now, if you did the wait_for_client
thing, the code will pause and wait for a debugger connection.
OK great, so now I select that debug configuration I created earlier in order to get my debugger to connect
I was stuck for ages on this. but now I ALSO NEED TO CLICK THE GREEN TRIANGLE or it doesn’t start. And then… That’s it. we are done.
The debugger will show what is happening in general, but it is especially useful when
- we hit a line that raises an exception, or
- the code hits the line
breakpoint()
which will cause the debugger to drop into the code right there.
How does the debugger work? I do not need to explain because microsoft has already done that. But tl;dr there is now a lot of information about my running code, a graph of the current call stack, a little tab to inspect the current value of variables etc.
Firewall rules we need
Pro tip. for use behind a firewall, requires the following whitelist exceptions:
For github copilot:
vscode-auth.github.com
api.github.com
copilot-proxy.githubusercontent.com
In addition it will be easier to install extensions with the following exceptions
marketplace.visualstudio.com
vscode.blob.core.windows.net
*.vo.msecnd.net
*.gallerycdn.vsassets.io
download.microsoft.com
(only some extensions)download.visualstudio.microsoft.com
(only some extensions)
*.online.visualstudio.com
*.liveshare.vsengsaas.visualstudio.com:443
A list of miscellaneous URLS that the VSCode likes includes
update.code.visualstudio.com
- Visual Studio Code download and update servercode.visualstudio.com
- Visual Studio Code documentationgo.microsoft.com
- Microsoft link forwarding servicevscode.blob.core.windows.net
- Visual Studio Code blob storage, used for remote servermarketplace.visualstudio.com
- Visual Studio Marketplace*.gallery.vsassets.io
- Visual Studio Marketplace*.gallerycdn.vsassets.io
- Visual Studio Marketplacerink.hockeyapp.net
- Crash reporting servicebingsettingssearch.trafficmanager.net
- In-product settings searchvscode.search.windows.net
- In-product settings searchraw.githubusercontent.com
- GitHub repository raw file accessvsmarketplacebadges.dev
- Visual Studio Marketplace badge serviceaz764295.vo.msecnd.net
- Visual Studio Code download CDNdownload.visualstudio.microsoft.com
- Visual Studio download server, provides dependencies for some VS Code extensions (C++, C#)vscode-sync.trafficmanager.net
- Visual Studio Code Settings Sync servicevscode-sync-insiders.trafficmanager.net
- Visual Studio Code Settings Sync service (Insiders)vscode.dev
- Used when logging in with GitHub or Microsoft for an extension or Settings Syncdefault.exp-tas.com
- Visual Studio Code Experiment Service, used to provide experimental user experiences
Technically we need to choose a port on the local AND remote machine, and these can be different, but why do that?↩︎
No comments yet. Why not leave one?