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

91–100 of 234 posts

Re: VSCode, Dev Containers and Docker

#91

Post by treis »

IggleSniggle wrote: post #61
adamkl wrote: 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?

Since they're lighter weight it's easier to run more of them. Think of a place with 7-8 different applications, a few different DBs to support them, redis, elastic search, etc. You can spin up a mirror of your production environment with one command. Theoretically you can do the same with VMs but it will consume a lot more resources.

Re: VSCode, Dev Containers and Docker

#92

Post by taeric »

This feels like a case study in how to take an anti fragile system, and just make it fragile.

As much as it is a bunch of small paper cuts to support varied developers, you are more resilient to a big shift.

Re: VSCode, Dev Containers and Docker

#93

Post by ihuman »

onion2k wrote: 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.

Isn't Docker using virtual machines on macos?

Re: VSCode, Dev Containers and Docker

#94

Post by umvi »

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!

We don't rebuild image every time. We store images in GitLab registry. Also, just because we use apt-get to install python3 doesn't mean build isn't reproducible. The actual toolchain and sysroot are highly version controlled and python is just used to kick off the build script so it almost doesn't really matter which version python is as long as it's backwards compatible with the build script.

Re: VSCode, Dev Containers and Docker

#95

Post by potta_coffee »

nickjj wrote: post #29
misiti3780 wrote: post #17

Earlier quoted context omitted.

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

I wrote this article a while back that compares setting up a Python development environment for web development with and without Docker: https://nickjanetakis.com/blog/setting-up-a-python-developme... The TL;DR is there's a lot of things to set up yourself without Docker in order to run a typical web application and it's different depending on what OS / version you use. Some of these things are unrelated to Python to…

A couple of years ago I got your Docker course and I learned a lot from it, been doing Docker chores for my teams ever since. Anyway, good course!

Re: VSCode, Dev Containers and Docker

#96

Post by jayd16 »

mosselman wrote: post #39
lpasselin wrote: post #16

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 also makes it easy to make changes and get it out to everyone on the team in an automated way.

Re: VSCode, Dev Containers and Docker

#97

Post by moistbar »

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…

Both apt and yum support installing to whatever directory you like as long as you have write permissions there.

Re: VSCode, Dev Containers and Docker

#98

Post by mbreese »

mosselman wrote: post #39
lpasselin wrote: post #16

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 like the fact that I can switch to/from different computers quickly. I have a desktop and a laptop that I routinely use. If I change something in a devcontainer[1], then I can move between the two easily. This actually happened to me earlier in the week.

[1] syncing the changes is left as an exercise to the reader, but I use a common git repository.

Re: VSCode, Dev Containers and Docker

#99

Post by gingerlime »

cpuguy83 wrote: post #44
onion2k wrote: 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.

We also use remote dev boxes, but can VSCode connect to a remote server and connect to remote docker containers?

For example, I don't have ruby installed on the remote dev box, but it is installed inside docker on the remote host. I also don't have ruby or docker running locally.

I think all the linting plugins either expect ruby to be available on the remote host, or inside docker, but not this combo... Is there something I'm missing? (disclaimer: only played a bit with VScode, I use vim on the remote box usually).

Re: VSCode, Dev Containers and Docker

#100

Post by hctaw »

moistbar wrote: post #97
hctaw wrote: post #50

Earlier quoted context omitted.

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…

Both apt and yum support installing to whatever directory you like as long as you have write permissions there.

"support" and "default" are very different things. Especially with package managers like homebrew, which comes with a loud warning that non-default (root) paths may not be supported by dependencies.

It also doesn't really, since this is a system level issue. Applications need to package their dependencies, not the other way around. Dependencies form graphs, not flat lists. The existence of a global cache of libraries shared by all programs is a total inversion of requirements.

Post reply on HN