Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

41–50 of 234 posts

Re: VSCode, Dev Containers and Docker

#41
post #23

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?

What exactly is diffucult to understand about the value proposition? Seems pretty obvious to me... If you mean why use dev environments in containers: 1) reproducibility, 2) re-use of container creation scripts for different environments, 3) isolation from your actual OS, 4) ability to run the same OS/libs/etc as the final deployment, 5) tons of base images with different environments already configured - from LAMP t…

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 my perspective.

Re: VSCode, Dev Containers and Docker

#42
One slight problem I had with .devcontainer in VS Code was running the devcontainer on a remote ssh server.

Remote SSH works. Local devcontainer works. But mixing the two requires configuring the docker engine settings to point to the remote. This forces other projects to also run on the remote machine.

This was a problem as of 2 months ago.

Re: VSCode, Dev Containers and Docker

#43
post #8

Doing any sort of development with Docker on OSX can be painfully slow if you have a lot of files that change frequently. There are a few projects to improve it but they quite aren't there yet. It's my least favourite aspect of modern web work.

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 using a desktop workstation with parts from 2014 too (i5 3.2ghz, 16gb of memory and a 1st gen SSD). About a month ago I made a video showing what the dev experience is like with this hardware while using Docker[1].

Code changes happen nearly instantly, live reloading works and even Webpack happily compiles down 100s of KBs of CSS and JS in ~200ms (which could further be improved by using Webpack cache).

[0]: The only exception to this is invalidating cached Docker layers when you install new dependencies. This experience kind of sucks, but fortunately this doesn't happen often since most changes are related to code changes not dependency changes.

[1]: https://nickjanetakis.com/blog/for-the-time-being-16gb-of-ra...

Re: VSCode, Dev Containers and Docker

#44
post #8

Doing any sort of development with Docker on OSX can be painfully slow if you have a lot of files that change frequently. There are a few projects to improve it but they quite aren't there yet. It's my least favourite aspect of modern web work.

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.

Re: VSCode, Dev Containers and Docker

#45

Earlier quoted context omitted.

If you have projects with different versions (python2/3, Java5/8, node8/11 etc) you don't need to bother with version managers and package managers anymore. Just launch the respective container and you are good to go.

for python, why cant you use use virtualenv with pyenv?

So, speaking as a data scientist, the dependencies run deeper than Python kernels and libraries. For something like TensorFlow, you need to account for specific versions of Nvidia drivers and CUDA/CUDnn. Using something like the Nvidia container runtime for model development allows me to essentially version my entire development environment.

Re: VSCode, Dev Containers and Docker

#46

Does this deprecate my vim/gcc/gdb/make (in general "CLI driven workflow") which I have assigned so much time to, to have a nice vender/IDE-independent solution for development? I'm curious to know the answer in an honest/practically-speaking sense not ideologically. IMO, the downside of this container/web-app solution is the memory size that all the SDKs would need and this would add up eventually. But I'm not sure…

If needed, you could probably containerize that workflow as well. Conversely, if someone shared their containerized environment with you, you don't necessarily need to use VSCode. You can still just attach to the container directly using Docker.

Re: VSCode, Dev Containers and Docker

#47

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?

It depends on what the environment is for. Your company work, or individual projects?

If you're an individual, then it would benefit someone who has multiple devices and/or multiple operating systems and doesn't want to manage their environment across all those devices and operating systems. For example, I personally have OSX, Windows, and several different Linux distributions on my laptop itself. My desktop also runs several operating systems.

Managing software across all of those is a pain. With Docker, I only have to manage the containers, and just have Docker installed on all the operating systems. Instead of managing like 50 different dependencies across 7 systems (think 7x50), I only have to manage Docker inside each system.

If you're working for a company, they will have their own dev environment. Instead of setting up and troubleshooting all their dependencies on your computer, you can just use their containers.

Re: VSCode, Dev Containers and Docker

#48
post #8

Doing any sort of development with Docker on OSX can be painfully slow if you have a lot of files that change frequently. There are a few projects to improve it but they quite aren't there yet. It's my least favourite aspect of modern web work.

the solution to this is to enable NFS for your volumes. The default volume configuration is a huge bottleneck for docker on macos

Re: VSCode, Dev Containers and Docker

#49

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?

If your project is targeting an environment you don't control, and doesn't behave exactly like an environment you have exclusive access to, your code won't run the same way in the production environment as it does on your machine. There are different strategies for dealing with this, but Docker seems to be the sweet spot for making it easier. You use Docker to create a container that mimics the production target, and then use that container to develop in.

You could reconfigure your laptop to look exactly like the production target, but then you have to keep doing that every time you change projects.

Before Docker, I used VMs for this, but VMs have certain disadvantages that Docker addresses. Like size, and documentability. Every time someone wanted me to look at a project, we had to figure out a way to transfer and store a copy of a 20+ GB VM. And they couldn't tell me everything they did to create that VM from scratch, because VMware doesn't do that and neither does Hyper-V. With Docker it is just a small text file that describes everything it takes to create what was previously a massive, undocumented VM image. It forces you to document how to create the environment, and it saves on the space and time of transferring VMs around.

Re: VSCode, Dev Containers and Docker

#50

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 mean in a sense, the fucked up behavior of system package managers relative to the actual concerns of building and distributing software to the masses is the reason we need Docker to sandbox environments in the first place. It's 2021, there is next to no reason why the default behavior is installation to /usr/lib with shared objects that are rarely shared, with global access when installed for one application used by one user, and linked dynamically when the object never changes over the lifetime of the running application.

For all its warts this is something that npm gets right. Package management is a tool for software development, not software distribution to end users.

Post reply on HN