Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

81–90 of 234 posts

Re: VSCode, Dev Containers and Docker

#81

Slightly off-topic, it really irks me when people take about reproducible builds/environments while using docker, while having something along the lines of apt-get update/pip install in their dockerfile. Like that completely destroys the reproducibility of your container!

The industry seems to have adopted “hermetic” as a word that describes truly reproducible builds, while “reproducible” has a lower standard. In many cases, it seems to be used to mean “not dependent on local build environment”.

Re: VSCode, Dev Containers and Docker

#82

As amazing and convenient as Docker is in practice, containers hide the inherent mess that is modern computing, and the more they are used, the less chance is that this mess is getting cleaned up... ever. Ultimately this is another dependency, complexity hidden by another layer...

I feel like calling modern computing a mess is harsh. Modern computing encompasses a plethora of applications, to a point where we can model most if not all workflows. It's the product of millions of humans working together for half a century in a very large graph with little connection between each clusters.

Nothing at that scale is a "mess". It's simply what was created by our collective distributed system of humans and we should appreciate that it's not really a problem that can be solved instead of talking about it as if we could "fix" it.

Re: VSCode, Dev Containers and Docker

#84

Slightly off-topic, it really irks me when people take about reproducible builds/environments while using docker, while having something along the lines of apt-get update/pip install in their dockerfile. Like that completely destroys the reproducibility of your container!

I never understood why commands like apt-get don't take a version with the dependency name.

As far as I'm aware it's supported (something like `apt-get install virtualbox=5.0.18-dfsg-2build1 -V`). It's just not commonly used because you usually just choose a distro with the desired update granularity (whether you want to the newest version out there or a consistent version with backported security fixes, or something in between).

Re: VSCode, Dev Containers and Docker

#85

Earlier quoted context omitted.

All of those benefits were solved problems with VM based workflows using something like Vagrant long before Containers started gaining traction (IMO). Don't get me wrong, I am a fan of containers (in particular LXC), but I wouldn't list those benefits as if they are unique or novel to container based workflows. Edit: To be clear, there _are_ benefits to containers over VMs, just not the things you listed above from m…

Schlepping around and running a whole VBox/Vagrant VM is heavy enough that I will be motivated to see if I can’t get it working under MacOS. Running a container is less offensive.

Is not docker server running inside a VM though ? You could also run Xserver (available on both Mac and Windows) and ssh -X into a VM to run GUI apps inside the VM.

Re: VSCode, Dev Containers and Docker

#86
post #43

Earlier quoted context omitted.

Have you tried docker on Windows? It's even worse. On OSX I only had problems with GUI running in docker. I was used to sharing X between linux host and docker container also running linux. For some projects, the only working solution I found was to run a VNC server in docker. Specific example: in a docker container, run a GUI built with Kivy and view the window on the OSX host. If anyone manages to do this without V…

> Have you tried docker on Windows? It's even worse. I've been running Docker on Windows since Windows 10 17.09 or roughly the time WSL 1 came around. That's since October 2017. It's been really fast and stable here and now with WSL 2 it's even better. There hasn't been a single Flask, Rails, Phoenix or Webpack related project I've developed in the last 3+ years where I felt like Docker was slowing me down[0]. I'm us…

The problem is "technically" still there in Windows it's just that Microsoft decided to push things along by creating WSL which essentially puts Linux (with Linux Containers) on Windows.

The Windows solution is the equivalent of Smart Hulk figuring out time travel.

I'm not saying it's not good, because it is.

Re: VSCode, Dev Containers and Docker

#87
post #38

Earlier quoted context omitted.

To make it workable I had to just give up on the local host file integration. I basically used the container like a VM. Configured it with all the tools I normally use (e.g. OhMyZsh, etc) and had it constantly running in the background. I would use VS Code as a front end and work directly inside the container (cloning repos and pushing commits). It had its quirks but the main benefit was that my local machine was no…

What would be the advantage of this setup over a traditional VM where you presumably have more portability of the stateful image?

To be perfectly honest, in this scenario, there isn't much of an advantage.

The container approach is lighter weight, and I found it easier to manage the configuration via Dockerfiles. Managing a full VM with the OS install is a bit of a pain.

That being said, I worked at an organization that did the VM approach using Vagrant. It wasn't as nice as the VS Code/Docker approach, but the results were similar.

Re: VSCode, Dev Containers and Docker

#88

Earlier quoted context omitted.

I use vscode to connect to a a cloud vm. VSCode is surprisingly good at this. Client is local and connects to an vscode server over ssh. Granted I work on Azure and the cost of the vm is not something I have to worry about.

I do this, but with a Linux VM running in Parallels on my Mac. Uses about 1/10 the CPU that Docker on Mac uses for the containers I run.

Same here, but with Hyper-V on Windows.

Originally I did this because of bad performance and bugs in WSL 1. I hear WSL 2 is better but I already have it all set up and it works great for me so I've just kept it.

Re: VSCode, Dev Containers and Docker

#89

I understand this can be done. And this post explains how it's done. I still don't get why it should be done? What's the advantage of running your dev environment in a container?

At the agency where I work we have about 40-50 somewhat active projects at any time. Any given week I work with maybe 3 to 10 of them.

It saves so much time to just pull down the repo, run "docker-compose up" and have everything running, almost exactly the way it's running in production. With the right node or php version, databases, Elasticsearch, Redis etc.

Re: VSCode, Dev Containers and Docker

#90

Earlier quoted context omitted.

npm / webpack: That's not Docker's fault - that's node/JS's fault. Having to touch thousands and thousands of files is expensive. This is why I've come to loath web frontend development.

> I've come to loath web frontend development. Well, we don't have to do things this way just because everybody else does... developing "vanilla" Javascript is actually a pleasure especially with tools like Chrome's debugger. In my experience, front-end "frameworks" like Angular and React provide very little value and tons of unnecessary overhead.

Show me the team that's using vanilla JS, I'd like to sign up.
Post reply on HN