Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

Post reply on HN
Print view View original

181–190 of 234 posts

Re: VSCode, Dev Containers and Docker

#181

Post by RyEgswuCsn »

nickjj wrote: post #43
lpasselin wrote: post #30

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…

I have been using Docker powered desktop environment for development on WSL2. Didn't have any issue except that I couldn't access the containers via their internal IPs inside WSL2.

Re: VSCode, Dev Containers and Docker

#182

Post by d3nj4l »

rusticpenn wrote: post #177
scruple wrote: post #176

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

Of course, you could use a version management tool like nvm/rvm/asdf etc, but I think containerisation is also a neat alternative, as you would be able to use multiple versions for languages/tools and libraries within those languages for which a version management tool doesn't exist.

Re: VSCode, Dev Containers and Docker

#183

Post by millstone »

rusticpenn wrote: post #177
scruple wrote: post #176

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

"3 versions of a framework" is quite vague. Are those versions Linux/Windows/Mac? Because then Docker is not very useful.

Docker is not a general solution to this problem because it ties you intimately to Linux, whether directly, or through VMs, or compat layers.

Re: VSCode, Dev Containers and Docker

#184

Post by laurencerowe »

scruple wrote: post #176

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

Working with a team on a project with a moderately complex build process (say python and node), it soon becomes a painful to onboard new team members and get their dev environments set up.

Even assuming they have the same version of macOS, homebrew constantly evolves so getting everyone developing with the same version of dependencies as you use in prod is super painful. If they’re on Linux they likely don’t run the exact same distribution as prod.

Even if all that is the same, maybe they have to work on multiple projects simultaneously with different dependencies.

Re: VSCode, Dev Containers and Docker

#185

Post by millstone »

hctaw wrote: post #163
FuckButtons wrote: post #154

Earlier quoted context omitted.

Except that - Linux distributions aren't solely tools for developing software, and their package managers are intended for all their end users.

That's not my point - dependency resolution is a build time requirement, not an install-time one. Requiring the user's machine to resolve dependencies to install your software is fragile, bug prone, and harms the user experience. Like it or not, users don't care if your software has interchangeable parts. They care if it runs on their system. The only sane way to guarantee a piece of software runs outside your develo…

No thanks. Apps like Firefox should use the libraries - windows, menus, etc. - installed on my system. Please don't ship your own libraries for this stuff.

Containers are an even more insane approach, so maybe we are in violent agreement.

Re: VSCode, Dev Containers and Docker

#186

Post by bloody-crow »

millstone wrote: post #183
rusticpenn wrote: post #177

Earlier quoted context omitted.

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

"3 versions of a framework" is quite vague. Are those versions Linux/Windows/Mac? Because then Docker is not very useful. Docker is not a general solution to this problem because it ties you intimately to Linux, whether directly, or through VMs, or compat layers.

Let's say you maintain or occasionally code several big webapps in Ruby. One uses Ruby 2.4 and Ruby-on-Rails 3.2, another uses Ruby 2.6 and Ruby-on-Rails 5.2, and the last one is bleeding edge using Ruby 3.0 and Rails 6.1

Having all versions of you language and framework installed top level is a huge pain in the ass, since they inevitably will interfere with each other. Having separate containers with all necessary dependencies in it for each app is a lot more manageable.

Re: VSCode, Dev Containers and Docker

#187

Post by fnord123 »

laurencerowe wrote: post #184
scruple wrote: post #176

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

Working with a team on a project with a moderately complex build process (say python and node), it soon becomes a painful to onboard new team members and get their dev environments set up. Even assuming they have the same version of macOS, homebrew constantly evolves so getting everyone developing with the same version of dependencies as you use in prod is super painful. If they’re on Linux they likely don’t run the…

Python and node are probably the easiest to get setup. With Python you have venvs which do a lot of the heavy lifting required.

The issue becomes when you are on a non Linux environment for development and deploy to Linux in containers. If you build your code locally then you are debugging $DESKTOP issues which might not be the same as Linux.

Also languange environments with poor dependency management (e.g. C, C++) benefit from having an installable system.

> Even assuming they have the same version of macOS, homebrew constantly evolves so getting everyone developing with the same version of dependencies as you use in prod is super painful.

If someone is using homebrew for their development dependencies, unless they are targeting a release to homebrew, kindly ask them to stop doing this.

Re: VSCode, Dev Containers and Docker

#188

Post by shadowgovt »

Shicholas wrote: post #171
shadowgovt wrote: post #6

Earlier quoted context omitted.

Probably not, but your vim/gcc/gdb/make flow doesn't scale to other developers. If it works for you, by all means keep using it.

you can still have a shared base Image for your teammates, then use that base image to create a new image just for your .vimrc etc.

I meant more that by modern standards, vim/gcc/gdb/make is a very labor-intensive toolchain to write applications with.

"Doesn't scale" in the sense of "other developers are pretty unwilling to learn that chain of they didn't grow up with it."

Re: VSCode, Dev Containers and Docker

#189

Post by girvo »

scruple wrote: post #176

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

My team uses macOS, windows and Linux. Dev Containers not only allow us to have our dev envs and prod environment as close as possible, as well as making all our dev envs identical, it makes working cross platform really straightforward.

Re: VSCode, Dev Containers and Docker

#190

Post by millstone »

gspr wrote: post #34

A little bit off-topic, but I hope it's relevant enough: can someone who's well-versed in Docker give me some pointers as to how I can use it in a better way? Let me elaborate. I'm a bit of an old fart when it comes to software development. I prefer stable, slowly evolving solutions. I am a fan of the role of classical distributions. I abhor bundling every piece of software with all its particular versioned dependenc…

You have an increasingly rarefied perspective, and you should hang onto it.

Docker is a treadmill. Docker leads to Docker Compose leads to Kubernetes leads to whatever. It's a lot of noise and motion; you will increasingly encounter engineers who grew up on this stuff and assume it as a prerequisite, and are eager to climb the treadmill, thinking it's a ladder. You know about other options, and can decide when to stop.

Post reply on HN