
Running VSCode in Docker - binalpatel
https://binal.pub/2019/04/running-vscode-in-docker/
======
marcus_holmes
> Last - and most important for me - in industries like my own (healthcare),
> you work with highly regulated data that has to be stored securely, where
> having multiple copies of data on multiple laptops can pose an unacceptably
> large risk.

um... please tell me devs don't have access to production data in a healthcare
environment (of all places!).

I mean, I understand the need for a representative dataset to develop and test
against, but this is people's lives they're playing with!

And, you know, if you had a decent set of anonymised or fictitious customer
data to work with, you wouldn't need to run your IDE in docker, and there
would be less surface area for attackers to get to the data.

~~~
kuzehanka
> um... please tell me devs don't have access to production data

If developers don't have access to production data, then the solution is
useless. How do people not understand this in 2019?

Millions of dollars have been dumped into various products centred around the
idea of synthesizing 'production-like' data and all have failed. Because
synthesizing fake data destroys the signal that makes the original data useful
in the first place. If the engineers don't have access to it, then they can't
extract the value from it, then what the hell are you doing in the first
place?

You think if you give engineers a synthetic dataset and they build a blind
solution around it, that the users will be extract value out of that data?
That myth was dispelled a decade ago and there doesn't exist a single
synthetic data success story since then.

I've had clients coming to us with the notion that they can give us fake
imaging data and we can generate diagnostic insights from it. This crap needs
to stop. If you can't trust engineers with your data to extract value out of
it, then go ahead and munge it in excel.

~~~
MuffinFlavored
> If developers don't have access to production data, then the solution is
> useless. How do people not understand this in 2019?

... what?

~~~
jldugger
Think machine learning.

~~~
inetknght
I am thinking machine learning. I am thinking I don't want a developer to run
machine learning algorithms in a (unsanitized) development environment with
access to production data.

~~~
kuzehanka
How do you train validate and market test an ml model without access to
production data? Please teach us all, this is literally a billion dollar
industry question.

~~~
ggregoire
You duplicate the data in dev but remove the names, SSNs, emails, addresses,
phone numbers, etc?

~~~
jldugger
That's not enough even, in previous cases we've seen researchers augment
datasets with other data to de-anonymize. [https://www.wired.com/2007/12/why-
anonymous-data-sometimes-i...](https://www.wired.com/2007/12/why-anonymous-
data-sometimes-isnt/)

But I think in general the idea OP was dismissing was generating synthetic
data rather than attempting to anonymize prod data. In that case you have a
risk of modeling the generator rather than your users.

------
laughingman2
People who want to work on remote access with restricted setups, checkout
Emacs. Tramp mode allows you to edit files over ssh, docker, adb etc without
you worrying about anything.

And if you haven't tried about Org Mode, it is not exaggeration if I say it is
life changing. It can help you organize notes, todos, agendas etc.

~~~
nine_k
Emacs is great in many ways; I'm saying it as an avid user.

For ultimate multi-workplace setup, you can run Emacs in server mode on a
cloud instance, and allow network connections to it, or port-forward to its
Unix socket via SSH.

Now you can run Emacs in client mode from whatever machine you may have,
several of them, or ssh to the cloud box and run Emacs in terminal mode in a
crunch. All your sessions will share the same set of files, but workspace
layout is per client, so you can work comfortably both from an 11" laptop
screen and from a 27" 4K screen.

As said above, you can use tramp to access whatever other remote files
accessible via ssh, and also run a decent (though a bit limited) terminal
right from Emacs, to say nothing of running REPLs of all kinds directly, and
excellent git integration with Magit.

This can even give you a sort of VPN-like access, when the cloud box where the
Emacs server runs has access to machines that are not directly accessible to
you from the machine you're connecting from.

OTOH VS Code likely can be run in a similar setup.

In general I very much like the modularization of IDEs: instead of a monolith
form 1990s you can mix and match your favorite editor with language servers,
REPLs, build servers, etc, all separate and in many cases running remotely.

~~~
jacobush
For me (20 years of Emacs), Emacs + Keybase has been what made it into a bit
of a productivity tool for me, instead of just an editor.

------
banana_giraffe
I was just playing with Coder's VS Code fork (what this solution uses for VS
Code) the other day [1]

I want to love it. It makes a very specific use case I use much nicer. I can
leave code on a remote server with all the compute power I need to build and
run my project, and edit the file I'm working on with VS code's editor without
having to sync files around. It does, however, have a few big caveats that
killed it for me.

It doesn't block any of the browser things that would leave the webpage.
Notably, if you hit Ctrl-W to close a file tab because of muscle memory,
you'll close the browser tab. Also, if you hit back on accident like I
apparently do all the time, you'll go back to the blank tab page. In both of
these cases, you'll lose any unsaved state.

Also, the extension repo it's pointing at isn't MS's live repo. There are
apparently reasons for this, but it means you don't get the latest version of
extensions, which was annoying for a specific extension I've gotten used to.

I also had issues with VS Code getting confused about state when my connection
to the remote box was less than ideal.

All in all, I really wanted to like it, but for truly remote cases, I'm back
to using Mosh to interact with the remote box, and a simple tool I wrote ages
ago to handle rsyncing the local files to the remote box to build and run them
there.

[1] [https://coder.com/](https://coder.com/)

~~~
larrywright
I played with this too, and was really excited about it... until I discovered
that it doesn't work on the iPad Pro (known issue with one of VS Code's core
components).

It's promising, but it's got a little ways to go.

------
batmansmk
Interesting case for cloud based IDEs.

I really don't understand the localhost use case though. I'm on MacOS. Why
would I spawn a VM (docker for macos) with limited access to my system
(container promise) to run an editor already running in a VM?

I only end up having a resources and disk space hungry, slow and inconvenient
editor?

------
alias_neo
The title of the article is ever so slightly misleading.

It would lead one to believe that VSCode and thus by extension VSCodium could
be run in Docker and accessed from a web browser

In fact, you can run "Coder" ([https://coder.com/);](https://coder.com/\);) a
product, which according to their GitHub had some non-trivial effort put into
it to make it run as such.

Not least of all, looking through their issue list, is the fact they compile
extensions themselves and they are therefore somewhat outdated (according to
issue comments from their users).

It's nice, but it's not VSCode per-se and sadly means no dice for Codium
users.

------
cheesedoodle
I'd love to use the VSCode IDE launched from the host and compile C++ code
within docker. Is this possible? Currently, I write code in the IDE and
compile in the container from the terminal. Imagine that, cross compile from
any host in a contained c++ environment. :)

Edit: I use CMAKE_TOOLCHAIN_FILE to describe the target env.

~~~
nacs
Code-server, which OP is building on, should support any language.

I've only used it briefly for some node.js work but as the whole thing is just
sitting in a normal linux docker container, you should be able to do anything
docker/linux can do.

[https://github.com/codercom/code-server](https://github.com/codercom/code-
server)

------
paulcarroty
Flatpak is much more interested than docker for GUI apps, especially for his
sandbox features.

------
znpy
Didn't anyone know it is possible to run a full blown Eclipse in the browser?

[https://www.eclipse.org/che/](https://www.eclipse.org/che/)

------
quaffapint
Whats the 'best' way people are using to have a total portable development
environment that I can reach from home or work? Meaning having vs code, node,
all the various cloud local emulators/etc that you would normally install for
doing that kind of dev work.

~~~
laughingman2
Emacs has tramp, which will allow you to remote edit files through ssh with
your own setup. You have emacs installed in your computer and you can open any
file in any system with ssh authentication inside it.

I am running emacs with spacemacs.org

~~~
irth
I think they meant the other way - accessing the editor/IDE remotely?

edit: or even not necessarily remotely - just a way to have the same setup
everywhere you go

------
jlu
Does the keyboard shortcuts for vscode still work inside browser?

~~~
horyzen
Those that do not conflict with the browser still works. e.g. 'Ctrl + `' to
open terminal, 'Ctrl + p' quick open. I'm using Firefox and 'Ctrl + Shift + p'
will open a new private browsing page instead of the command palette.

~~~
jlu
Thanks, glad to know that!

------
herohamp
This seems very promising. With C9 being moved to AWS soon, I might look into
building an internal version of it powered by launching VSCode instances.

------
black-tea
Why on earth would you do this? Docker is such a misunderstood technology.

~~~
reilly3000
From Coder.com

    
    
      Code on your Chromebook, tablet, and laptop with a consistent dev environment.
    
      If you have a Windows or Mac workstation, more easily develop for Linux.
    
      Take advantage of large cloud servers to speed up tests, compilations, downloads, and more.
    
      Preserve battery life when you're on the go.
    
      All intensive computation runs on your server.
    
      You're no longer running excess instances of Chrome.
    
    

I imagine not everybody is going to want to run this on some Kubernetes
cluster. The ability to do this locally seems that it could be really
productive, actually. And having it in Docker can provide snapshotting via
`docker commit` as well as the ability to cap its cpu/ram resources.

I might actually try this and a Docker registry to get some semblance of an
editor per project. In some contexts I want to run many, many extensions,but
for other work I'd rather not have that bloat to contend with. Also I've been
really feeling the pain of navigating a PC running Unraid (lots of bare metal
VMs) and a Mac laptop, trying to do development on each. My desktop is beefy,
but I need to work on the go sometimes, and at times I need to use a Windows
box. Right now they all have different VSCode setups. I've been meaning to get
around to setting up some scheme of making my config portable, but with
different paths across Ubuntu, MacOS, and Windows that seems a bit daunting to
get all of my dep paths straight, like eslint and phpcs.

Okay, enough comment writing, I'm giving this a go.

~~~
reilly3000
Some updates for those who are interested:

1\. I first tried to install this on my Win10 VM, which needed to have Docker
installed. That was a terrible idea. I completely broke my VM as Docker tried
to enable Hyper-V. Friends don't let friends attempt nested virtualization. I
should have just run the container on the host instead, which it supports
quite well.

2\. The repo worked as the blog post described on my mac. Its quick and has
been able to run some tricky extensions. I need to experiment with running
some external dependancies still.

3\. Docker commit worked nicely, making a layer for the changes I made. Still
playing with this, but wow that could be very productive if it enabled me to
roll back to a tested base environment, or share a full IDE image with
somebody on my team.

~~~
dalore
Docker for windows uses hyper-v for it's virtualization. It works.

But if you're running win10 virtually then it's not going to be able to run
hyper-v, that's a limitation of window and hyper-v and not docker.

But if you're running win10 via a vm why don't you just already have the host
start a linux docker vm instead of hyper-v in hyper-v?

