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!
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
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>
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;
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
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"
}
}
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 -
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!
Top comments (0)