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

151–160 of 234 posts

Re: VSCode, Dev Containers and Docker

#151

Post by bergie »

chrisjc wrote: post #119
ducktective wrote: post #5

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…

I don't think so. If fact you could just package your "CLI driven workflow" up into a docker image and now you can instantly move it between machines, peers, etc... Furthermore you could version and manage the evolution/drift of your workflow as underlying components change/get updated.

Exactly: I have CI produce a Docker image from my dotfiles repo https://bergie.iki.fi/blog/docker-developer-shell/

Re: VSCode, Dev Containers and Docker

#153

Post by GordonS »

Lendal wrote: post #49
marcus_holmes wrote: post #10

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…

I use Windows 10 as my daily driver, and often work on projects using Postgres, RabbitMQ, Redis, nginx and others.

Until Docker came along, it was a royal PITA. I always dreaded getting a new laptop or something breaking, as it took forever to set everything back up again, and it was never quite the same.

Docker changed all that. It forces you to configure everything in a reproducible way in a Dockerfile - and it's much simpler than trying to come up with scripts to install and configure everything in Windows, and I'd say it's also quicker than trying to come up with scripts for a Linux VM, just because you can spin containers up and down so quickly.

Docker has been a game changer for dev/test.

Re: VSCode, Dev Containers and Docker

#154

Post by FuckButtons »

hctaw wrote: post #50
dhruvrrp wrote: post #22

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…

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

Re: VSCode, Dev Containers and Docker

#155

Post by GordonS »

mbreese wrote: post #104
gshulegaard wrote: post #41

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…

Overhead... it's all overhead. Starting and connecting to a VM isn't nearly as streamlined as connecting to a Docker container (even if it is also running in a VM). Even the hurdle of SSH'ing to a VM is more cumbersome than `docker run`. Certainly this could be automated and scripted, but the Docker solution is so... streamlined. And I say this as someone that used to use Vagrant. With smaller installs available (suc…

Yes, a lot of containers start in less than 1 second. With SSDs it's not as bad as it used to be for VMs, but it's still a lot longer than a container.

I also find the workflow of creating Dockerfiles to be much smoother than cobbling together scripts for a VM.

Plus Vagrant was a real PITA to get working on Windows (at least it used to be - I think I eventually gave up trying to get something running on Windows 7).

Re: VSCode, Dev Containers and Docker

#156

Post by misiti3780 »

pilotneko wrote: post #45
misiti3780 wrote: post #17

Earlier quoted context omitted.

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.

good point.

Re: VSCode, Dev Containers and Docker

#157

Post by coldtea »

gshulegaard wrote: post #41
coldtea wrote: post #23

Earlier quoted context omitted.

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 m…

>All of those benefits were solved problems with VM based workflows using something like Vagrant long before Containers started gaining traction (IMO).

Well, VMs are like overweight containers. Containers make "all of those benefits" easier, more performant, and more ligherweight.

Re: VSCode, Dev Containers and Docker

#158

Post by coldtea »

z3t4 wrote: post #85
closeparen wrote: post #53

Earlier quoted context omitted.

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.

>Is not docker server running inside a VM though

No, docker server runs directly on top of the OS as a native program.

As for Docker containers managed by the Docker server, they are runing on top of a supervisor - not in a full VM.

Re: VSCode, Dev Containers and Docker

#159

Post by teddyfrozevelt »

IggleSniggle wrote: post #109
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…

Try thinking of it as `git` but for an entire OS instead of merely a filesystem, and that you have multiple branches of your git tree opened simultaneously in different locations. Or think of it as a set of databases that include the combination of the current state and the code ("migrations") to achieve that state, while allowing those databases to share the same history. In other words, containers are a solution to…

So, like ostree? https://ostreedev.github.io/ostree/

Re: VSCode, Dev Containers and Docker

#160

Post by NashHallucinate »

dhruvrrp wrote: post #22

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!

Not if you specify the versions to install, at least
Post reply on HN