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

171–180 of 234 posts

Re: VSCode, Dev Containers and Docker

#171

Post by Shicholas »

shadowgovt wrote: post #6
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…

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.

Re: VSCode, Dev Containers and Docker

#172

Post by Shicholas »

mhoad wrote: post #7

I've been doing some playing around with dev containers for a while now and am loving the experience so far. The one thing I am not super clear on however is doing end to end browser based testing in Web Apps. I didn't find a lot of good documentation on this currently. I can't tell if the "correct" solution is to also load something like headless chrome into the Dockerfile and install it manually or go down the path…

We found website testing inside a Docker container to be tough, so we still run Cypress on a native machine, but our web process is still ran within the Docker container. In CI, we use the default Cypress GitHub action which runs on the CI native system, and all of our servers are spun up with docker-compose. Source: https://github.com/NeonLaw/codebase/blob/development/.github...

Re: VSCode, Dev Containers and Docker

#173

Post by Shicholas »

ItalyPaleAle wrote: post #71
IggleSniggle wrote: post #61

Earlier quoted context omitted.

What would be the advantage of this setup over a traditional VM where you presumably have more portability of the stateful image?

Speaking for myself, containers are started and destroyed faster. When using VMs, the tendency is to keep updating the software within the VM, making changes to their state, etc: this eventually leads to drifts. When using containers, if you need to make a change, you destroy the container and re-build it, and the state is always consistent with what you (and possibly your teammates) use

as an addition to do this, we've found it easier to spin up the same exact environment for CI/CD.

Re: VSCode, Dev Containers and Docker

#174

Post by topspin »

Silhouette wrote: post #115
gameswithgo wrote: post #70

Earlier quoted context omitted.

agreed. that docker is needed represents a failure of our industry

I'm not sure I quite agree with that. Having a controlled environment in a sandbox of its own clearly has benefits, both for consistency of what you're running and for safety if it doesn't work as you expected. It doesn't need to be Docker specifically that we use to create such an environment, but if not Docker then we'd surely have looked for some other way to achieve the same result.

Docker is literally the specification of all the missing parts of the operating system. It's not a very good specification, but it is fairly comprehensive.

Re: VSCode, Dev Containers and Docker

#175

Post by pbalau »

gingerlime wrote: post #99
cpuguy83 wrote: post #44

Earlier quoted context omitted.

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

Yes, if you can connect the docker cli to the remote host, then vscode can connect too.

Re: VSCode, Dev Containers and Docker

#177

Post by rusticpenn »

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?

Re: VSCode, Dev Containers and Docker

#179

Post by 40four »

alanwreath wrote: post #168
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…

I wonder what the stats are of the VSCode remote plugin users but I would wager a cup of water that the majority of users who go this route are dealing with Windows in some fashion. I’d never heard of such witchcraft until I moved to an organization that, for whatever reason, has deemed that Windows laptops are the mandatory choice for web development. WSL does have significant problems (and even when it works you de…

“I’d wager a cup of water”

I like this phrase. I would like to borrow it if you don’t mind :)

Re: VSCode, Dev Containers and Docker

#180

Post by alanwreath »

40four wrote: post #179
alanwreath wrote: post #168

Earlier quoted context omitted.

I wonder what the stats are of the VSCode remote plugin users but I would wager a cup of water that the majority of users who go this route are dealing with Windows in some fashion. I’d never heard of such witchcraft until I moved to an organization that, for whatever reason, has deemed that Windows laptops are the mandatory choice for web development. WSL does have significant problems (and even when it works you de…

“I’d wager a cup of water” I like this phrase. I would like to borrow it if you don’t mind :)

Me recently getting into Dune has altered my perception...
Post reply on HN