DEV Community

loading...
Cover image for How to run VS Code as a Container for Remote Development
Quant ONE

How to run VS Code as a Container for Remote Development

sar profile image Sar Malik Originally published at quant.one Updated on ・5 min read

Launch your own Code Server container with preloaded dev tools (SDKs, npm packages, CLIs etc) for an efficient and securely accessible Web IDE in your homelab or private cloud!

vs-code-server

Why VS Code in a Container?

Remote development has taken the world by storm, it's not just a trend but here to stay as a new way that delivers on the promise of work-life balance.

Teams need to adapt rapidly and deploy out infrastructure which enables developer productivity and one of the best ways we've found is - speed to onboarding.

Getting up and running is simple as scaling containers with all the tooling and personalized preferences ready to go. Writing code has never been easier, anywhere and on any device powered by your own cloud.

Getting Started

We've provided the full code samples used in this guide, checkout our Github repository to get started.

👉 Clone the repo
📜 Create an .env file
🔒 Generate SSL certificates
🐳 vi dockerfile with your own scripts
🚀 Launch the stack with docker-compose up!

Clone the repo on a host server with docker or podman configured. It's recommended to attach mount points for storing your codebase isolated from the container runtime for redundancy and failover management.

$ git clone https://github.com/DigitalTransformation/vs-code-container-with-ssl.git
Enter fullscreen mode Exit fullscreen mode

Next, we'll setup the required environment variables and data paths using the included .env.template replicated as .env (note: it's excluded by default in .gitignore).

Persistent storage for extensions and vscode settings can also be enabled by mapping HOST_* variables for convenience against container restarts and rebuilds. Otherwise you'll be quite unhappy to see all the preferences wiped out!

The popular vs code extension settings-sync is also another great way to backup preferences onto private gists but does require reinstalling extensions on every new image build.

Here's an example of what you'll need to define in .env:

VIRTUAL_HOST=10.0.0.1
VIRTUAL_PORT=8555

HOST_CONFIG_PATH=./config
HOST_LOG_PATH=./logs

HOST_CODE_PATH=/mnt/codebase
CODE_PATH=/code

TZ=America/New_York
PASSWORD=<PASSWORD>
SUDO_PASSWORD=<SUDO_PASSWORD>
Enter fullscreen mode Exit fullscreen mode

Nginx is used to reroute traffic from [::]:80 to upstream HTTPS port [::]:8443 with self-signed SSL certificates. Checkout and run the generate_certs.sh script to emit the required certificates with signing key using openssl.

Place both the nginx.conf and certs under the paths defined in code-server.yaml.

listen [::]:443 ssl default_server;
        ssl_certificate /etc/nginx/certs/ssl.crt;
        ssl_certificate_key /etc/nginx/certs/ssl.key;
        ssl_protocols TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DHE+AES128:!ADH:!AECDH:!MD5;
Enter fullscreen mode Exit fullscreen mode

Finally, deploy the container stack on the docker host using the command docker-compose -f code-server.yaml up. It may take 15-20 minutes depending on your hardware and network bandwidth for the initial build. The dockerfile pre-configures a number of devtools and updates the base image packages.

To comply with Docker CIS, resource limits are defined on each of the containers but can be customized to your hardware in the compose code-server.yaml file.

Pre-Installed Dev Tools

Here's a quick overview of what the dockerfile does to extend the linuxserver/code-server base image. This allows containers to be rapidly deployed and scaled up for usage on dev teams with tooling ready to go.

The output image includes SDKs for cloud native app development workloads such as React, Node, C#, AWS and Azure Cloud CLIs.

* AWS CLI Tools
    * aws-shell
    * amplify cli
* Azure CLI
* Netlify CLI
* NPM packages
    * yarn (upstream)
    * gatsby-cli
    * gulp
    * create-react-app
* .NET Core SDK and Runtime
    * 5.0.0
    * 3.1.0
    * 2.1.0
* Python global env
    * python3 python3-pip python3-dev
* Ubuntu apt packages
    * Networking
        * wget
        * apt-transport-https
        * libssl-dev libffi-dev
    * Tools
        * ranger
        * tree
        * unzip
        * ansible
        * vim
        * htop
        * iputils-ping
    * OS/Misc
        * systemd
        * build-essential
        * ffmpeg
        * youtube-dl
        * chromium-browser
    * Default shell --> zsh/oh-my-zsh
        * zsh-syntax-highlighting
        * zsh-autosuggestions
        * zsh-completions
        * history-search-multi-word
Enter fullscreen mode Exit fullscreen mode

Refer to the Dockerfile for image layers. Our build image size was well over 6.5GB but can be as minimal as your requirements for dev tools.

Remote Debugging

By default the dockerfile and code-server.yaml are set to expose port ranges 5000-5010 and 8000-8010 commonly used for web app development. Customize this for your workload such as React, Gatsby, Angular, Django, etc. to allow for remote debugging HTTP instances that are running inside the container.

To allow external access on node frameworks that depend http-server (instantiated with npm or yarn) you may need to also update your package.json and bind the runtime to the host ip instead of localhost.

Here are a few common examples:

{
    "scripts": {
        "ng:start": "ng serve --host 0.0.0.0",
        "npm:start": "http-server --host 0.0.0.0",
        "gatsby:start": "gatsby develop --host 0.0.0.0"
    }
}
Enter fullscreen mode Exit fullscreen mode

Alternatively, if you'd prefer not to expose ports, check out the vscode-browser-preview extension which enables chromium based inspection and debugging within the container itself.

Security Considerations

As the base image extends ubuntu:18.04, additional steps have been taken to add security measures with hosts file, fail2ban and clamav packages preloaded. These are precautionary against attacks but insufficient against (un)known breaches.

Log Analytics

It's strongly recommended to configure a remote syslog daemon for log analytics with auditd enabled, here's our guide on using solutions such as Graylog2.

Ports

There's a wide range of tcp ports exposed and mapped directly to the host for remote debugging apps running inside the container. By default, only the code-server is allocated on ports 8443 and localhost:8080.

$ netstat -tnlp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      299/node            
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      -     
Enter fullscreen mode Exit fullscreen mode

For dev workloads outside of a homelab or private cloud behind firewalls, using an nginx reverse proxy with HTTPS and auth redirects is vital to preventing sensitive code exposure.

What's next?

Deploying VS Code Server in a container is a great way to provide for flexible development infrastructure in your home lab or for your team.

Paired with VPN access and all your custom settings, Web IDEs make for the future of remote coding. It's rapidly scalable, gets you to coding a lot quicker, and on any device.

Be sure to checkout the Github repository where we've provided the full code samples that can be used to deploy your own code-server in minutes.

I've been using it as my primary development environment and after tweaking vscode settings and extensions, there's no going back. The speedup of compiling code on a dedicated server alone is worth the change.

Let me know if you like this homelab setup and what you think!

Discussion

pic
Editor guide