Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

51–60 of 234 posts

Re: VSCode, Dev Containers and Docker

#51

Earlier quoted context omitted.

Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.

> Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?

But you can easily switch projects in-company, take a look at the one next cubicle etc. You switch machines. You decide work from home etc.

Re: VSCode, Dev Containers and Docker

#52

Earlier quoted context omitted.

Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.

> Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?

It depends on how large your organization is and what specific quirks need to be configured to do your work.

Its not unusual for large organizations to have internally hosted registries (Artifactory), source control and network proxies. This usually requires setting up different config files (.npmrc for Node.js/NPM), installation of custom root certificates, ssh keys, etc. None of that includes project/team specific configurations and workflows.

Take all that and multiply it by thousands of developers and you have a recipe for an endless stream of Slack chats, email chains, and Teams messages repeating the same config questions and answers.

If you can reduce all that down to a single docker pull, while making sure everyone's development environment is consistent, it can be a big win.

Re: VSCode, Dev Containers and Docker

#53
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…

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.

Re: VSCode, Dev Containers and Docker

#54

Earlier quoted context omitted.

Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.

> Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?

> I see this brought up a lot as an argument. So why do we want this? How often do people switch companies?

It's not about you. The people coming in generally need confirmation and help when setting up their environments. Someone there would have to take time out of their day to help you. A few hours, a few days, a few weeks, a few deleted companies (https://news.ycombinator.com/item?id=11496947).

Here's an even more fun one: https://news.ycombinator.com/item?id=14476421

Re: VSCode, Dev Containers and Docker

#56
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 are confusing two different things.

One is using Docker as a deployment packaging method. The other is using Docker only for development and still deploying traditionally. Sure you can do both, but it doesn't have to be this way.

>when I use Docker, I pretend it's a VM

Also check anti-patterns 1 and 4 here

https://codefresh.io/containers/docker-anti-patterns/

Re: VSCode, Dev Containers and Docker

#57
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.

In my experience, Docker on Windows with WSL 2[1] has been pretty snappy.

[1] https://docs.docker.com/docker-for-windows/wsl/

Re: VSCode, Dev Containers and Docker

#58
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.

The Azure Codespaces VMs were awfully slow on IOs. It was not a great experience at all.

If you want decent IOs, better than an old notebook, Azure is extremely expensive.

Re: VSCode, Dev Containers and Docker

#59

Earlier quoted context omitted.

Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.

> Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?

It depends on your context. I've worked places that onboard new team members every few years, and I've worked places that onboard new team members every few weeks.

On larger teams, setting up a consistent environment like that also makes it easier for developers to collaborate. I've had experiences where attempts to pair program or share utility scripts generally stumbles and fails due to everyone's environment being a special snowflake.

Re: VSCode, Dev Containers and Docker

#60

Earlier quoted context omitted.

Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.

> Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?

It can be much more complicated than that.

* You want means to keep all of the dev environments in sync so you don't get "works on my machine" problems.

* If you update something, then you need a way for everyone to have their environment reconfigured.

* As the number of projects/stacks/developers scales this becomes a bigger and bigger issue.

I've used some Anisble in combination with a shell script wrapper to handle some of this kind of stuff. Even still, it takes a lot of hands on support to make it all work. So, if you can get something like this to scale, it might be a big win ... if...

(edit formatting.)

Post reply on HN