"Whenever you can, share. You never know who all will be able to see far away standing upon your shoulders!"
I write mainly on topics related to science and technology.
Sometimes, I create tools and animation.
May 28, 2021
Author - manisar
Visual Studio Code has emerged as a mighty flag bearer of Microsoft in the field of free IDEs. The elegance, light footprint, flexibility - everything is awesome about it, and great thanks to Microsoft for developing such a beauty.
The icing on the cake has been the inclusion of remote development on Linux machines from Windows via WSL (or Remote-SSH for non-WSL Linux machines) and Docker extensions in VS Code, and dev-containerization.
Given below is a quick understanding and reference for setting up VS Code for remote development on WSL Linux machine, and using dev-containerization as well if we want.
On the same lines, it is possible, as explained below, to remotely develop on a real or virtual Linux machine (non-WSL) - by using the Remote-SSH extension.
Note: You may skip this section if you are connecting to a non-WSL Linux machine (from Windows). In that case, just focus on the Remote-SSH part.
Windows Subsystem for Linux (version 2) is a groundbreaking new feature in Windows. It basically allows Linux layers (docker-like) to run on a common Linux kernel provided by Windows. So, in effect, we can have different Linux distros on a Windows machine without having to create a virtual machine for each.
On a side note, Docker (i.e. the Docker for Desktop SW) itself can use this kernel for building and running Linux containers and we can have docker containers taking advantage of WSL2.
Given below is how I went about setting up VS Code for using WSL2 and docker containers from scratch. If you follow these, you may have to include or exclude a few extra steps depending upon your Windows version and Linux distro. I tried to be succinct for the sake of avoiding clutter. Also, WSL and WSL2 are different, and the steps below relate strictly to WSL2.
/etc/bash.bashrc (as Debian doesn't come with this feature enabled).Using WSL extension for remote development
/root.code . (in the Linux CLI). This starts VS Code on Windows.In the instructions above, we were able to run code . on the Linux CLI and it started a VS Code on the Windows host simply because WSL provides inherent connection to the host Windows machine.
If our code resided on a real Linux remote machine (or on VM that is not WSL-powered), Remote - SSH extension would have done this job for us (and we would not need the Remote-WSL extension). More detail are here.
Basically, we need to:
This extension will take care of both:
code . from the WSL CLI)Remote - SSH extension is similar to the Remote - WSL extension in that both of them start a VS Code server on the remote machine so that the coding experience you get on your local machine is not inferior to what you would have got had you been coding on remote machine itself!
Note: With Remote - SSH extension, for added security, you may create an SSH tunnel between local and remote and use that for attaching VS Code debugger to the remotely running program. Check Remote script debugging with SSH for more details.
An important thing to note is that we'll have to install the required extensions such as Python (along with Pylance and Jupyter) on the container (or remote host) specifically (through VS Code itself). But, note: do not install the extensions on the Linux (WSL) container or remote machine if you intend to further dev-containerize your code from within this container - see below.
Thus we have a full-featured VS Code at our disposal now with features such as linting, autocompletion, intellisense etc. This VS Code is connected to the code on a Linux machine (container, VM or real).
Before I knew of this extension, I used to mount the Linux directory on my Windows host, and open this mounted folder in VS Code. That's it. In order to see cross references and definitions etc. for third party libraries (such as Django and other packages), I used to download the Windows version of the libraries in Windows somewhere and point the environment in VS Code to those libraries. It was quite convoluted and painstaking. This is no longer needed.
Now, there appears an icon Remote Explorer in VS Code, and we see something like this there for 'WSL Targets'. That is, we see available WSL targets, and active folders in them, if any.
Note that in the screenshot, we also see the docker-desktop container (used by Docker for Desktop), as that is also a WSL target.
Using remote container extension for developing within dev-containers
So far so good - we have a Linux machine (container), and we have some code residing there which we can connect to using VS Code and and we can develop or code as if that complete codebase along with its SW stack was on Windows. What else would we need?
We don't need anything else unless we want to be even more formal with development.
Yes, developing on a Linux machine makes sense if your real-world host is going to be a Linux machine - it's the only possibility mostly, and we expect to see real-world issues that we may face. But, there is a caveat.
The testing we are going to do in our Linux (WSL) container (or real or virtual machine) is still not going to truly reflect or mimic the runs executed on the production machine - for the simple inevitable reason that we installed development tools (such as so many VS Code extensions) on it. We can never be sure about anything not breaking on the production host unless we install the same development tools there and that will be a waste of resources and mostly money.
Here comes the idea of Dev Containers! With dev containers, VS Code creates a container on the fly (which is persistent though), and lets us develop our code in that container without needing to install the extensions and plugins etc. on the actual Linux container (or the real Linux host whatsoever).
Thus, we get two machines - one for development and the other for testing.
The former is the dev-container, and the latter is what we had initially set up on the WSL machine.
Thus we get a damn-real separation of roles. Development happens in an isolated machine and testing can be done on a production like machine! To make it even more ideal, while cloning the git (or setting up any source control SW) on the Linux container, we should create appropriate branch(es) and then dev-containerize those branches as per the steps given below.
The above adds the file .devcontainer/devcontainer.json file to the project. The VS Code window will reload and start building the dev container. A progress notification provides status updates. You only have to build a dev container the first time you open it; opening the folder after the first successful build will be much quicker.
Another thing to note is that our code on the Linux (WSL) container is bind-mounted into the dev-container. A quick excerpt on bind mount - While using this approach to bind mount the local filesystem into a container is convenient, it does have some performance overhead on Windows and macOS. There are some techniques that you can apply to improve disk performance, or you can open a repository in a container using a isolated container volume instead.
If you want to use a Docker host that is remote (i.e. not running on your local machine), see the Advanced Containers Configuration article.
Lastly, there remains another very useful extension to be installed on VS Code - VS Code Docker extension. This extension adds the functionality to build, manage, and deploy containerized applications from inside VS Code (remember that you will need the Remote-Container extension to actually use the container as your dev environment).
\\wsl$\ share, but you wouldn't have access to features such as autocomplete, debugging, or linting.
Return to Coding and Development - Reference and Tools