Run Visual Studio Code In Docker



The Docker extension makes it easy to build, manage, and deploy containerized applications from Visual Studio Code.

Debug containerized apps. With version 0.9.0 and later, the Docker extension provides more support for debugging applications within Docker containers, such as scaffolding launch.json configurations for attaching a debugger to applications running within a container. The Docker extension provides a docker debug configuration provider that manages how VS Code will launch an application and/or. Install Docker on your machine and add it to the system path. On Linux, you should also enable Docker CLI for the non-root user account that will be used to run VS Code. To install the extension, open the Extensions view (Ctrl+Shift+X), search for docker to filter results and select Docker extension authored by Microsoft. Editing Docker files #.

Download

This page provides an overview of the Docker extension capabilities; use the side menu to learn more about topics of interest. If you are just getting started with Docker development, try the Docker tutorial first to understand key Docker concepts.

Installation

Install Docker on your machine and add it to the system path.

On Linux, you should also enable Docker CLI for the non-root user account that will be used to run VS Code.

To install the extension, open the Extensions view (⇧⌘X (Windows, Linux Ctrl+Shift+X)), search for docker to filter results and select Docker extension authored by Microsoft.

Editing Docker files

You can get IntelliSense when editing your Dockerfile and docker-compose.yml files, with completions and syntax help for common commands.

In addition, you can use the Problems panel (⇧⌘M (Windows, Linux Ctrl+Shift+M)) to view common errors for Dockerfile and docker-compose.yml files.

Generating Docker files

You can add Docker files to your workspace by opening the Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)) and using Docker: Add Docker Files to Workspace command. The command will generate Dockerfile and .dockerignore files and add them to your workspace. The command will also query you if you want the Docker Compose files added as well; this is optional.

The extension recognizes workspaces that use most popular development languages (C#, Node.js, Python, Ruby, Go, and Java) and customizes generated Docker files accordingly.

Docker Explorer

The Docker extension contributes a Docker Explorer view to VS Code. The Docker Explorer lets you examine and manage Docker assets: containers, images, volumes, networks, and container registries. If the Azure Account extension is installed, you can browse your Azure Container Registries as well.

The right-click menu provides access to commonly used commands for each type of asset.

You can rearrange the Docker Explorer panes by dragging them up or down with a mouse and use the context menu to hide or show them.

Docker commands

Run Visual Studio Code In Docker

Many of the most common Docker commands are built right into the Command Palette:

You can run Docker commands to manage images, networks, volumes, image registries, and Docker Compose. In addition, the Docker: Prune System command will remove stopped containers, dangling images, and unused networks and volumes.

Using image registries

You can display the content and push/pull/delete images from Azure Container Registry, Docker Hub, GitLab, and more:

An image in an Azure Container Registry can be deployed to Azure App Service directly from VS Code; see Deploy images to Azure App Service page. For more information about how to authenticate to and work with registries see Using container registries page.

Debugging services running inside a container

You can debug services built using .NET (C#) and Node.js that are running inside a container. The extension offers custom tasks that help with launching a service under the debugger and with attaching the debugger to a running service instance. For more information see Debug container application and Extension Properties and Tasks pages.

Azure CLI integration

You can start Azure CLI (command-line interface) in a standalone, Linux-based container with Docker Images: Run Azure CLI command. This allows access to full Azure CLI command set in an isolated environment. See Get started with Azure CLI page for more information on available commands.

Docker Compose

Docker Compose lets you define and run multi-container applications with Docker. You can define what shape these containers look like with a file called docker-compose.yml.

Visual Studio Code's experience for authoring docker-compose.yml is also very rich, providing IntelliSense for valid Docker compose directives and it will query Docker Hub for metadata on public Docker images.

  1. Create a new file in your workspace called docker-compose.yml
  2. Define a new service called web:
  3. On the second line, bring up IntelliSense by pressing ⌃Space (Windows, Linux Ctrl+Space) to see a list of all valid compose directives.
  1. For the image directive, you can press ⌃Space (Windows, Linux Ctrl+Space) again and VS Code will query the Docker Hub index for public images.

VS Code will first show a list of popular images along with metadata such as the number of stars and description. If you continue typing, VS Code will query the Docker Hub index for matching images, including searching public profiles. For example, searching for 'Microsoft' will show you all the public Microsoft images.

Next steps

Read on to learn more about

As mentioned in the last post I want to write about remote working inside a docker container. But at first, we should get an idea about why we should ever remote work inside a docker container.

Why should I do that?

One of our customers is running an OpenShift/Kubernetes cluster and also likes to have the technology-specific development environments in a container that runs in Kubernetes. We had a NodeJS development container, a Python development container, and so on... All the containers had an SSH server installed, Git, the specific SDKs, and all the stuff that is needed to develop. Using VSCode we connected to the containers via SSH and developed inside the container.

Having the development environment in a container is one reason. Maybe not the most popular reason. But trying stuff inside a container because the local environment isn't the same makes a lot of sense. If you want to debug an application in a production-like environment makes absolute sense.

Docker Container Visual Studio Code

How does it work?

VSCode has a great set of tools to work remotely. In installed Remote WSL (used in the last post), Remote SSL was the one we used with OpenShift (maybe I will write about it, too), and with this post, I'm gonna use Remote Container. All three of them will work inside the remote explorer within VS Code. All three add-ins will work pretty similarly.

If the remote machine doesn't have the VSCode Server Installed, the remote toll will install it and start it. The VSCode server is like a full VSCode without a user interface. It also needs to have add-ins installed to work with the specific technologies. The local VSCode will connect to the remote VSCode server and mirrors it in the user interface of your locally installed VSCode. It is like a remote session to the other machine but feels local.

Setup the demo

Visual Studio Code Docker Debug

I created a small ASP.NET Core MVC project:

Than I added a dockerfile to it:

If you don't have the docker tool installed, VSCode will ask you to install it as soon you have the dockerfile open. If it's installed you can just right-click the dockerfile in the VSCode Explorer and select 'Build image...'.

This will prompt you for an image name. You can use the proposed name which is 'remotedocker:latest' in my case. It seems it uses the project name or the folder name which makes sense:

Select the Docker tab in VSCode and you will find your newly built image in the list of images:

You can now right-click the tag latest and choose 'Run Interactive'. If you just choose 'Run' the container stops, because we commented out the entry point. We need an interactive session. This will start-up the container and it will now appear as a running container in the container list:

You can browse and open the files inside the container from this containers list, but editing will not work. This is not what we want to do. We want to remotely connect VSCode to this Docker container.

Connecting to Docker

This can be done using two different ways:

  1. Just right-click the running container and choose 'Attach Visual Studio Code'
  1. Or select the Remote Explorer tab, ensure the Remote Containers add-in is selected in the upper-right dropdown box, wait for the containers to load. If all the containers are visible, choose the one you want to connect, right-click it and choose 'Attach to container' or 'Attach in New Window'. It does the same thing as the previous way

Now you have a VSCode instance open that is connected to the container. You now can see the files in the project, you can sue the terminal inside the container and you can now edit the files inside the project.

You can see that this is a different VSCode than your local instance by having a look at the tabs on the left side. Not all the add-ins are installed on that instance. In my case, the database tools are missing as well as the Kubernetes tools and some others.

Working inside the Container

Since we disabled the entry point in the dockerfile we are now able to start debugging by pressing F5.

This also opens the local browser and shows the application that is running inside the container. This is really awesome. It feels like really local development:

Let's change something to see that this is really working. Like in the last demo, I'm going to change the page title. I would like to see the name 'Remote Docker demo':

Just save and restart debugging in VSCode:

That's it.

Conclusion

Isn't this cool?

You can easily start docker containers to test, debug and develop in a production-like environment. You can configure a production-like environment with all Docker containers you need using docker-compose on your machine. Then add your development, or your testing container to the composition and start it all up. Now you can connect to this container and start playing around within this environment. It is all fast, accessible, and on your machine.

This is cool!

I'd like to see this is also working if the containers running on Azure. I will try it within the next weeks and maybe I can put the results in a new blog post.